From ecrit-bounces@ietf.org Thu May 1 06:42:20 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81863A6B8B; Thu, 1 May 2008 06:42:20 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394C93A6E83 for ; Thu, 1 May 2008 06:42:19 -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 hHxstmpZPSNE for ; Thu, 1 May 2008 06:42:10 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 344663A6922 for ; Thu, 1 May 2008 06:42:10 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JrZ31-0006Xd-1d; Thu, 01 May 2008 08:42:07 -0500 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'Perry Prozeniuk'" , References: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> <5D1A7985295922448D5550C94DE2918001ED6E43@DEEXC1U01.de.lucent.com> Date: Thu, 1 May 2008 09:42:08 -0400 Message-ID: <008601c8ab91$282e7500$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aciq+An/HeuMv5JNSLOHHzLJ4yVarQAcNEhQAAn55FA= In-Reply-To: <5D1A7985295922448D5550C94DE2918001ED6E43@DEEXC1U01.de.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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] Callbacks and phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1888465946==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1888465946== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C8AB6F.A11CD500" This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C8AB6F.A11CD500 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I'm always ready and willing to supply an answer to questions like this. We all know there is no really right answer, but any answer is a good answer. So, 15 minutes. That's enough. An hour would be better, but 15 minutes is enough. After that time, the AoR can be used. Might not get back to the same device. That's okay. -phonebcp applies to end devices as well as proxies, so I think we're covered there. Brian _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Thursday, May 01, 2008 4:56 AM To: Perry Prozeniuk; ecrit@ietf.org Subject: Re: [Ecrit] Callbacks and phonebcp There is no point in writing a MUST unless you tell us what the period of time is. How can I assess the conformance without knowing that value. We have certainly been round that loop in 3GPP and noone has been able to specify how long after the initial call a callback must be possible. Further this is a set of CPE requirements, and the CPE does not have complete control over whether the Contact header remains valid. regards Keith _____ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Perry Prozeniuk Sent: Wednesday, April 30, 2008 8:26 PM To: ecrit@ietf.org Subject: [Ecrit] Callbacks and phonebcp As part of the NENA CPE IP Capable PSAP working group we have been looking into the SIP callback information and how the PSAP will use this. In phonebcp, following references are found: ============== 3. The From header MUST be present and SHOULD be the AoR of the caller. . 6. A Contact header MUST be present which MUST be globally routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an immediate call-back to the specific device which placed the emergency call. And a little later: 5. Either a P-Asserted-Identity [RFC3325] or an Identity header [RFC4474], or both, MUST be included to identify the sender. ============= Specifically in reference to (6) above, I believe that there is a potential issue. The statement that the contact header MUST be globally routable is not sufficient. It MUST also be usable for a period of time after the call completes. If one looks at a situation where there is a Session Border Controller (SBC) between the SIP phone and the PSAP, the SBC may replace the contact header with a temporary address that although is globally routable is ONLY valid for the duration of the call. A GRUU would satisfy both of these conditions, however so would any other globally routable SIP URI for the originating phone that remained valid after the call completion. A GRUU would be preferred. I am suggesting the the wording be strengthened somewhat to ensure that the Contact URI MUST be usable for callback for a short period of time after the call completes (e.g. a few minutes) and the a GRUU SHOULD be specified. Of course if the phone is disconnected, etc then the contact may not be usable at all after the call and the other address fields (e.g. the AOR) will need to be used for callback which may or may not reach the caller directly. In most cases the phone will remain operational following the call completion and the contact information should allow the originating phone to be reached directly. Perry ------=_NextPart_000_0087_01C8AB6F.A11CD500 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I’m always ready and willing = to supply an answer to questions like this.  We all know there is no = really right answer, but any answer is a good = answer.

 

So, 15 minutes.  That’s enough.  An hour would be better, but 15 minutes is enough.  = After that time, the AoR can be used.  Might not get back to the same device.  That’s okay.

 

-phonebcp applies to end devices as = well as proxies, so I think we’re covered = there.

 

Brian

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith = (Keith)
Sent: Thursday, May 01, = 2008 4:56 AM
To: Perry Prozeniuk; ecrit@ietf.org
Subject: Re: [Ecrit] = Callbacks and phonebcp

 

There is no point in writing a MUST = unless you tell us what the period of time is. How can I assess the conformance without knowing that value. We have certainly been round that loop in = 3GPP and noone has been able to specify how long after the initial call a = callback must be possible.

 

Further this is a set of CPE = requirements, and the CPE does not have complete control over whether the Contact = header remains valid.

 

regards

=

 

Keith

=

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Perry Prozeniuk
Sent: Wednesday, April = 30, 2008 8:26 PM
To: ecrit@ietf.org
Subject: [Ecrit] = Callbacks and phonebcp

As part of the NENA CPE IP Capable PSAP working group we have been looking into the SIP callback information and = how the PSAP will use this.

 

In phonebcp, following references are = found:

 

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

 

   3.   The From header MUST be = present and SHOULD be the AoR of the

        = caller.

…

   6.   A Contact header MUST be = present which MUST be globally

        routable, = for example a GRUU [I-D.ietf-sip-gruu], to permit = an

        immediate call-back to the specific device which placed = the

        emergency = call.

 

And a little later:

   5.  Either a P-Asserted-Identity = [RFC3325] or an Identity header

       [RFC4474], or = both, MUST be included to identify the sender.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= o:p>

 

Specifically in reference to (6) above, I believe = that there is a potential issue.  The statement that the contact header MUST = be globally routable is not sufficient.  It MUST also be usable for a = period of time after the call completes. 

 

If one looks at a situation where there is a Session = Border Controller (SBC) between the SIP phone and the PSAP, the SBC may replace = the contact header with a temporary address that although is globally = routable is ONLY valid for the duration of the call.  A GRUU would satisfy both = of these conditions, however so would any other globally routable SIP URI for the originating phone that remained valid after the call completion.  A = GRUU would be preferred.

 

 I am suggesting the the wording be strengthened somewhat to ensure that the Contact URI MUST be usable for callback for = a short period of time after the call completes (e.g. a few minutes) and the a GRUU SHOULD be specified.

 

Of course if the phone is disconnected, etc then the = contact may not be usable at all after the call and the other address fields = (e.g. the AOR) will need to be used for callback which may or may not reach the = caller directly.  In most cases the phone will remain operational = following the call completion and the contact information should allow the originating = phone to be reached directly.

 

Perry

 

------=_NextPart_000_0087_01C8AB6F.A11CD500-- --===============1888465946== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1888465946==-- From ecrit-bounces@ietf.org Thu May 1 10:02:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2362528C404; Thu, 1 May 2008 10:02:04 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E4C3A69EE for ; Thu, 1 May 2008 10:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 4vzA-1xHZ4Dk for ; Thu, 1 May 2008 10:01:56 -0700 (PDT) Received: from zrtps0kp.us.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C998D3A6EFE for ; Thu, 1 May 2008 10:01:55 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.us.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m41H1sr28331; Thu, 1 May 2008 17:01:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 May 2008 13:01:50 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646515CA09DB@zcarhxm1.corp.nortel.com> In-Reply-To: <008601c8ab91$282e7500$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Callbacks and phonebcp Thread-Index: Aciq+An/HeuMv5JNSLOHHzLJ4yVarQAcNEhQAAn55FAABqjvwA== References: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> <5D1A7985295922448D5550C94DE2918001ED6E43@DEEXC1U01.de.lucent.com> <008601c8ab91$282e7500$640fa8c0@cis.neustar.com> From: "Perry Prozeniuk" To: "Brian Rosen" , "DRAGE, Keith (Keith)" , Subject: Re: [Ecrit] Callbacks and phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1791738526==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1791738526== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8ABAD.0C93BC0A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8ABAD.0C93BC0A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Brian. =20 =20 The objective is to make sure that the network equipment is designed such that the CONTACT information provided with an emergency call remains valid after the call. There are many factors that impact the exact amount of time that it could/should remain valid. The existing wording does not require the network equipment to provide a mechanism that extends the CONTACT beyond the end of the current call. =20 The objective for the amount of time is really an issue for PSAP operations. These are the people that are going to be making the callbacks. I will send a question to the NENA operations group to obtain their opinion on a objective the the amount of time the CONTACT remains valid. This should provide the minimum duration that would be considered a best current practice. As technology people we could debate this forever since there isn't really a technical answer other than it needs to remain valid for a while. =20 Perry =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, May 01, 2008 9:42 AM To: 'DRAGE, Keith (Keith)'; Prozeniuk, Perry (CAR:9T51); ecrit@ietf.org Subject: RE: [Ecrit] Callbacks and phonebcp I'm always ready and willing to supply an answer to questions like this. We all know there is no really right answer, but any answer is a good answer. =20 So, 15 minutes. That's enough. An hour would be better, but 15 minutes is enough. After that time, the AoR can be used. Might not get back to the same device. That's okay.=20 =20 -phonebcp applies to end devices as well as proxies, so I think we're covered there. =20 Brian =20 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Thursday, May 01, 2008 4:56 AM To: Perry Prozeniuk; ecrit@ietf.org Subject: Re: [Ecrit] Callbacks and phonebcp =20 There is no point in writing a MUST unless you tell us what the period of time is. How can I assess the conformance without knowing that value. We have certainly been round that loop in 3GPP and noone has been able to specify how long after the initial call a callback must be possible. =20 Further this is a set of CPE requirements, and the CPE does not have complete control over whether the Contact header remains valid. =20 regards =20 Keith =20 =09 ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Perry Prozeniuk Sent: Wednesday, April 30, 2008 8:26 PM To: ecrit@ietf.org Subject: [Ecrit] Callbacks and phonebcp As part of the NENA CPE IP Capable PSAP working group we have been looking into the SIP callback information and how the PSAP will use this. =20 In phonebcp, following references are found: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 3. The From header MUST be present and SHOULD be the AoR of the caller. ... 6. A Contact header MUST be present which MUST be globally routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an immediate call-back to the specific device which placed the emergency call. =20 And a little later: 5. Either a P-Asserted-Identity [RFC3325] or an Identity header [RFC4474], or both, MUST be included to identify the sender. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Specifically in reference to (6) above, I believe that there is a potential issue. The statement that the contact header MUST be globally routable is not sufficient. It MUST also be usable for a period of time after the call completes. =20 =20 If one looks at a situation where there is a Session Border Controller (SBC) between the SIP phone and the PSAP, the SBC may replace the contact header with a temporary address that although is globally routable is ONLY valid for the duration of the call. A GRUU would satisfy both of these conditions, however so would any other globally routable SIP URI for the originating phone that remained valid after the call completion. A GRUU would be preferred. =20 I am suggesting the the wording be strengthened somewhat to ensure that the Contact URI MUST be usable for callback for a short period of time after the call completes (e.g. a few minutes) and the a GRUU SHOULD be specified. =20 Of course if the phone is disconnected, etc then the contact may not be usable at all after the call and the other address fields (e.g. the AOR) will need to be used for callback which may or may not reach the caller directly. In most cases the phone will remain operational following the call completion and the contact information should allow the originating phone to be reached directly. =20 Perry =20 ------_=_NextPart_001_01C8ABAD.0C93BC0A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 agree with Brian. 
 
The=20 objective is to make sure that the network equipment is designed such = that the=20 CONTACT information provided with an emergency call remains valid after = the=20 call.  There are many factors that impact the exact amount of time = that it=20 could/should remain valid.  The existing wording does not require = the=20 network equipment to provide a mechanism that extends the CONTACT beyond = the end=20 of the current call.
 
The=20 objective for the amount of time is really an issue for PSAP = operations. =20 These are the people that are going to be making the callbacks. I = will send=20 a question to the NENA operations group to obtain their opinion on a = objective=20 the the amount of time the CONTACT remains valid.  This = should provide=20 the minimum duration that would be considered a best current = practice.  As=20 technology people we could debate this forever since there isn't really = a=20 technical answer other than it needs to remain valid for a=20 while.
 
Perry
 

From: Brian Rosen = [mailto:br@brianrosen.net]=20
Sent: Thursday, May 01, 2008 9:42 AM
To: 'DRAGE, = Keith=20 (Keith)'; Prozeniuk, Perry (CAR:9T51); ecrit@ietf.org
Subject: = RE:=20 [Ecrit] Callbacks and phonebcp

I’m = always ready and=20 willing to supply an answer to questions like this.  We all know = there is=20 no really right answer, but any answer is a good=20 answer.

 

So, 15 = minutes. =20 That’s enough.  An hour would be better, but 15 minutes is = enough. =20 After that time, the AoR can be used.  Might not get back to the = same=20 device.  That’s okay.

 

-phonebcp = applies to=20 end devices as well as proxies, so I think we’re covered=20 there.

 

Brian

 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith=20 (Keith)
Sent: = Thursday, May 01,=20 2008 4:56 AM
To: = Perry=20 Prozeniuk; ecrit@ietf.org
Subject: Re: [Ecrit] Callbacks = and=20 phonebcp

 

There is no = point in=20 writing a MUST unless you tell us what the period of time is. How can I = assess=20 the conformance without knowing that value. We have certainly been round = that=20 loop in 3GPP and noone has been able to specify how long after the = initial call=20 a callback must be possible.

 

Further this = is a set=20 of CPE requirements, and the CPE does not have complete control over = whether the=20 Contact header remains valid.

 

regards

 

Keith

 

From:=20 ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Perry = Prozeniuk
Sent: Wednesday, April 30, 2008 = 8:26=20 PM
To:=20 ecrit@ietf.org
Subject:=20 [Ecrit] Callbacks and phonebcp

As part of the NENA CPE = IP Capable=20 PSAP working group we have been looking into the SIP callback = information=20 and how the PSAP will use this.

 

In phonebcp, following = references=20 are found:

 

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

 

   = 3.   The=20 From header MUST be present and SHOULD be the AoR of=20 the

       =20 caller.

…

   = 6.   A=20 Contact header MUST be present which MUST be=20 globally

       =20 routable, for example a GRUU [I-D.ietf-sip-gruu], to permit=20 an

       =20 immediate call-back to the specific device which placed=20 the

       =20 emergency call.

 

And a little=20 later:

   5.  = Either a=20 P-Asserted-Identity [RFC3325] or an Identity=20 header

      =20 [RFC4474], or both, MUST be included to identify the=20 sender.

 

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

 

Specifically in = reference to (6)=20 above, I believe that there is a potential issue.  The statement = that the=20 contact header MUST be globally routable is not sufficient.  It = MUST also=20 be usable for a period of time after the call completes. =20

 

If one looks at a = situation where=20 there is a Session Border Controller (SBC) between the SIP phone and = the PSAP,=20 the SBC may replace the contact header with a temporary address that = although=20 is globally routable is ONLY valid for the duration of the call.  = A GRUU=20 would satisfy both of these conditions, however so would any other = globally=20 routable SIP URI for the originating phone that remained valid after = the call=20 completion.  A GRUU would be=20 preferred.

 

 I am suggesting = the the=20 wording be strengthened somewhat to ensure that the Contact URI MUST = be usable=20 for callback for a short period of time after the call completes (e.g. = a few=20 minutes) and the a GRUU SHOULD=20 be specified.

 

Of course if the phone = is=20 disconnected, etc then the contact may not be usable at all after the = call and=20 the other address fields (e.g. the AOR) will need to be used for = callback=20 which may or may not reach the caller directly.  In most cases = the phone=20 will remain operational following the call completion and the contact=20 information should allow the originating phone to be reached=20 directly.

 

Perry

 

= ------_=_NextPart_001_01C8ABAD.0C93BC0A-- --===============1791738526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1791738526==-- From ecrit-bounces@ietf.org Thu May 1 11:42:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598C73A6ED7; Thu, 1 May 2008 11:42:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28AD3A6D35 for ; Thu, 1 May 2008 11:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 UPKkRvwYCU2F for ; Thu, 1 May 2008 11:42:22 -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 8CFBE3A6C59 for ; Thu, 1 May 2008 11:42:22 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 May 2008 11:42:23 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m41IgNTT007567; Thu, 1 May 2008 11:42:23 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m41IgJhj013799; Thu, 1 May 2008 18:42:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 11:42:23 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.94.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 May 2008 11:42:22 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 01 May 2008 13:42:22 -0500 To: ken carlberg , hannes.tschofenig@nsn.com From: "James M. Polk" In-Reply-To: <7F76FF71-3527-4890-9AE8-3B01DB685045@g11.org.uk> References: <7F76FF71-3527-4890-9AE8-3B01DB685045@g11.org.uk> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 01 May 2008 18:42:22.0985 (UTC) FILETIME=[17FE8790:01C8ABBB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1210; t=1209667343; x=1210531343; 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]=20terminology=20question |Sender:=20; bh=mOV80wbGZ/cQl51uxUVDssuNqcBfJpT+cMT1mrqYOZw=; b=U+0GyNzm5gKWVs8Nbz5r2g0ywXSZBtRHdTvWWjQccy//AbYj3GIo4g3S1H VLFWdlTziKnrcBQIwzUFvdqv0S8qpFqOw0H9PZrb4cuWD0IbywitVzUo3Xl4 JYpuEDxwTT; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] terminology question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 06:59 AM 4/29/2008, ken carlberg wrote: >Hannes, > >my apologies for the mundane question (and if I missed it in some >document), but I just wanted to chase down a question of terminology >for the sake of preciseness. > >within the scope of ECRIT, how are you defining civilian and authority >when using the terms civilian-to-authority and authority-to-authority? > >for me, I gravitate to civilian = general public, and authority are >people working on behalf of the government (Federal, state, local, >tribal) for the common good. Examples of "authority" in the ECRIT >perspective would be fireman, police, dispatchers, even militia (e.g., >National Guard that gets mobilized during disasters). On the other >hand, I wouldn't characterize those that work for vendors, ISPs, the >PSTN as "authority". Would you agree with this perspective? I know I would. Further complicating things is the opinion of several that consider GETS to be A2A, which is not necessarily true (it's A2any, with only a few individual exceptions) >-ken > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 1 15:37:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720D03A69BB; Thu, 1 May 2008 15:37:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCCD3A68E7 for ; Thu, 1 May 2008 15:37:49 -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.001, 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 7fGNQqv7WZbo for ; Thu, 1 May 2008 15:37:40 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9CDDD3A68AF for ; Thu, 1 May 2008 15:37:40 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_01_17_51_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); Thu, 01 May 2008 17:51:26 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 May 2008 17:37:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 May 2008 17:37:37 -0500 Message-ID: In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646515CA09DB@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Callbacks and phonebcp Thread-Index: Aciq+An/HeuMv5JNSLOHHzLJ4yVarQAcNEhQAAn55FAABqjvwAAMF5Kw References: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com><5D1A7985295922448D5550C94DE2918001ED6E43@DEEXC1U01.de.lucent.com><008601c8ab91$282e7500$640fa8c0@cis.neustar.com> <9671A92C3C8B5744BC97F855F7CB646515CA09DB@zcarhxm1.corp.nortel.com> From: "Winterbottom, James" To: "Perry Prozeniuk" , "Brian Rosen" , "DRAGE, Keith (Keith)" , X-OriginalArrivalTime: 01 May 2008 22:37:40.0558 (UTC) FILETIME=[F6B936E0:01C8ABDB] Subject: Re: [Ecrit] Callbacks and phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0612280168==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0612280168== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8ABDB.F65590A1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8ABDB.F65590A1 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Actually if you made it 30 minutes you would be inline with how long=0D=0Am= any of the deployed GMLCs cache ESRK to call-back number mappings=0D=0Abefo= re throwing them away.=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________________________________=0D=0A=0D= =0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D= =0AOf Perry Prozeniuk=0D=0ASent: Friday, 2 May 2008 3:02 AM=0D=0ATo: Brian = Rosen; DRAGE, Keith (Keith); ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] Callb= acks and phonebcp=0D=0A=0D=0A=20=0D=0A=0D=0AI agree with Brian. =20=0D=0A=0D= =0A=20=0D=0A=0D=0AThe objective is to make sure that the network equipment = is designed=0D=0Asuch that the CONTACT information provided with an emergen= cy call=0D=0Aremains valid after the call. There are many factors that imp= act the=0D=0Aexact amount of time that it could/should remain valid. The e= xisting=0D=0Awording does not require the network equipment to provide a me= chanism=0D=0Athat extends the CONTACT beyond the end of the current call.=0D= =0A=0D=0A=20=0D=0A=0D=0AThe objective for the amount of time is really an i= ssue for PSAP=0D=0Aoperations. These are the people that are going to be m= aking the=0D=0Acallbacks. I will send a question to the NENA operations gro= up to obtain=0D=0Atheir opinion on a objective the the amount of time the C= ONTACT remains=0D=0Avalid. This should provide the minimum duration that w= ould be=0D=0Aconsidered a best current practice. As technology people we c= ould=0D=0Adebate this forever since there isn't really a technical answer o= ther=0D=0Athan it needs to remain valid for a while.=0D=0A=0D=0A=20=0D=0A=0D= =0APerry=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A_________________________= _______=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASen= t: Thursday, May 01, 2008 9:42 AM=0D=0ATo: 'DRAGE, Keith (Keith)'; Prozeniu= k, Perry (CAR:9T51); ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Callbacks and= phonebcp=0D=0A=0D=0AI'm always ready and willing to supply an answer to qu= estions like this.=0D=0AWe all know there is no really right answer, but an= y answer is a good=0D=0Aanswer.=0D=0A=0D=0A=20=0D=0A=0D=0ASo, 15 minutes. = That's enough. An hour would be better, but 15 minutes=0D=0Ais enough. Af= ter that time, the AoR can be used. Might not get back to=0D=0Athe same de= vice. That's okay.=20=0D=0A=0D=0A=20=0D=0A=0D=0A-phonebcp applies to end d= evices as well as proxies, so I think we're=0D=0Acovered there.=0D=0A=0D=0A= =20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A____________________________= ____=0D=0A=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf=0D=0AOf DRAGE, Keith (Keith)=0D=0ASent: Thursday, May 01, 2008 = 4:56 AM=0D=0ATo: Perry Prozeniuk; ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] = Callbacks and phonebcp=0D=0A=0D=0A=20=0D=0A=0D=0AThere is no point in writi= ng a MUST unless you tell us what the period=0D=0Aof time is. How can I ass= ess the conformance without knowing that value.=0D=0AWe have certainly been= round that loop in 3GPP and noone has been able=0D=0Ato specify how long a= fter the initial call a callback must be possible.=0D=0A=0D=0A=20=0D=0A=0D=0A= Further this is a set of CPE requirements, and the CPE does not have=0D=0Ac= omplete control over whether the Contact header remains valid.=0D=0A=0D=0A =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: ecri= t-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0ABehalf Of Perry = Prozeniuk=0D=0A=09Sent: Wednesday, April 30, 2008 8:26 PM=0D=0A=09To: ecrit= @ietf.org=0D=0A=09Subject: [Ecrit] Callbacks and phonebcp=0D=0A=0D=0A=09As = part of the NENA CPE IP Capable PSAP working group we have=0D=0Abeen lookin= g into the SIP callback information and how the PSAP will use=0D=0Athis.=0D= =0A=0D=0A=09=20=0D=0A=0D=0A=09In phonebcp, following references are found:=0D= =0A=0D=0A=09=20=0D=0A=0D=0A=09=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D= =0A=0D=0A=09=20=0D=0A=0D=0A=09 3. The From header MUST be present and S= HOULD be the AoR of=0D=0Athe=0D=0A=0D=0A=09 caller.=0D=0A=0D=0A=09..= =2E=0D=0A=0D=0A=09 6. A Contact header MUST be present which MUST be gl= obally=0D=0A=0D=0A=09 routable, for example a GRUU [I-D.ietf-sip-gru= u], to=0D=0Apermit an=0D=0A=0D=0A=09 immediate call-back to the spec= ific device which placed=0D=0Athe=0D=0A=0D=0A=09 emergency call.=0D=0A=0D= =0A=09=20=0D=0A=0D=0A=09And a little later:=0D=0A=0D=0A=09 5. Either a P= -Asserted-Identity [RFC3325] or an Identity=0D=0Aheader=0D=0A=0D=0A=09 = [RFC4474], or both, MUST be included to identify the=0D=0Asender.=0D=0A=0D= =0A=09=20=0D=0A=0D=0A=09=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A=0D=0A= =09=20=0D=0A=0D=0A=09Specifically in reference to (6) above, I believe that= there is=0D=0Aa potential issue. The statement that the contact header MU= ST be=0D=0Aglobally routable is not sufficient. It MUST also be usable for= a=0D=0Aperiod of time after the call completes. =20=0D=0A=0D=0A=09=20=0D=0A=0D= =0A=09If one looks at a situation where there is a Session Border=0D=0ACont= roller (SBC) between the SIP phone and the PSAP, the SBC may replace=0D=0At= he contact header with a temporary address that although is globally=0D=0Ar= outable is ONLY valid for the duration of the call. A GRUU would=0D=0Asati= sfy both of these conditions, however so would any other globally=0D=0Arout= able SIP URI for the originating phone that remained valid after the=0D=0Ac= all completion. A GRUU would be preferred.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09= I am suggesting the the wording be strengthened somewhat to=0D=0Aensure th= at the Contact URI MUST be usable for callback for a short=0D=0Aperiod of t= ime after the call completes (e.g. a few minutes) and the a=0D=0AGRUU SHOUL= D be specified.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Of course if the phone is d= isconnected, etc then the contact may=0D=0Anot be usable at all after the c= all and the other address fields (e.g.=0D=0Athe AOR) will need to be used f= or callback which may or may not reach=0D=0Athe caller directly. In most c= ases the phone will remain operational=0D=0Afollowing the call completion a= nd the contact information should allow=0D=0Athe originating phone to be re= ached directly.=0D=0A=0D=0A=09=20=0D=0A=0D=0A=09Perry=0D=0A=0D=0A=09=20=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C8ABDB.F65590A1 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

Actually if you made it 30 minutes you=0D=0Awould be inline with= how long many of the deployed GMLCs cache ESRK to=0D=0Acall-back number ma= ppings before throwing them away.

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

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

Cheers

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

<= font size=3D2 color=3Dnavy face=3DArial>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

From:= =0D=0Aecrit-bounces@ietf.org [mailto:ecrit-bounces@= ietf.org] On Behalf Of = Perry Prozeniuk
=0D=0ASent: Friday, 2 May 2008 3:02 AM
=0D=0A= To: Brian Rosen; DRAGE, Keith=0D=0A(Keith); ecrit@ietf.org
=0D= =0ASubject: Re: [Ecrit] Call= backs and=0D=0Aphonebcp<= /p>=0D=0A=0D=0A

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

 <= /span>

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

I agree with Brian. =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

The objective is to= make=0D=0Asure that the network equipment is designed such that the CONTAC= T information=0D=0Aprovided with an emergency call remains valid after the = call.  There are=0D=0Amany factors that impact the exact amount of tim= e that it could/should remain=0D=0Avalid.  The existing wording does n= ot require the network equipment to=0D=0Aprovide a mechanism that extends t= he CONTACT beyond the end of the current=0D=0Acall.

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

 

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

The objective for the=0D=0Aamount of ti= me is really an issue for PSAP operations.  These are the=0D=0Apeople = that are going to be making the callbacks. I will send a question=0D=0A= to the NENA operations group to obtain their opinion on a objective the the=0D= =0Aamount of time the CONTACT remains valid.  This should provide= the=0D=0Aminimum duration that would be considered a best current practice= =2E  As=0D=0Atechnology people we could debate this forever since ther= e isn't really a=0D=0Atechnical answer other than it needs to remain valid = for a while.

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

 

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

Perry

=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

From:=0D=0ABrian Rosen [mailto:br@brianros= en.net]
=0D=0ASent: Thur= sday, May 01, 2008 9:42=0D=0AAM
=0D=0ATo: 'DRAGE, Keith (Keith)';=0D=0AProzeniuk, Perry (CAR:9T51); = ecrit@ietf.org
=0D=0ASubject:= RE: [Ecrit] Callbacks and=0D=0Aphonebcp

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

I’m always ready=0D=0Aand willing to supp= ly an answer to questions like this.  We all know there=0D=0Ais no rea= lly right answer, but any answer is a good answer.=

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

 

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

So, 15 minutes. =0D=0AT= hat’s enough.  An hour would be better, but 15 minutes is=0D=0Ae= nough.  After that time, the AoR can be used.  Might not get back= to=0D=0Athe same device.  That’s okay.

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

 

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

-phonebcp applies to end=0D= =0Adevices as well as proxies, so I think we’re covered there.

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

 

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

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

 

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

From:= =0D=0Aecrit-bounces@ietf.org [mailto:ecrit-bounces@= ietf.org] On Behalf Of = DRAGE, Keith (Keith)
=0D=0ASent: Thursday, May 01, 2008 4:56=0D=0AAM
=0D=0ATo: Perry Prozeniuk;=0D=0Aecrit@ietf.org
=0D=0A= Subject: Re: [Ecrit] Callbac= ks and=0D=0Aphonebcp

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

 =

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

There is no point in=0D=0Awriting a MUST unless= you tell us what the period of time is. How can I assess=0D=0Athe conforma= nce without knowing that value. We have certainly been round that=0D=0Aloop= in 3GPP and noone has been able to specify how long after the initial call=0D= =0Aa callback must be possible.=

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

 

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

Further this is a set of=0D=0ACPE requirements, and = the CPE does not have complete control over whether the=0D=0AContact header= remains valid.

=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

&= 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 Perry Prozeniuk
=0D=0ASent: Wednesday, April 30, 200= 8=0D=0A8:26 PM
=0D=0ATo: = ecrit@ietf.org
=0D=0ASubject:= [Ecrit] Callbacks and=0D=0Aphonebcp

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

As part of the NENA CPE IP Capable PSAP working=0D=0Agrou= p we have been looking into the SIP callback information and how the=0D= =0APSAP will use this.=0D=0A=0D=0A

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

 

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

In phonebcp, f= ollowing references are found:

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

 

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

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

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

 

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

   3.   The From header MUST be=0D=0Apresent and SH= OULD be the AoR of the

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

  = ;      caller.

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

…

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

   6.&nb= sp;  A Contact header MUST be=0D=0Apresent which MUST be globally=

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

      = ;  routable,=0D=0Afor example a GRUU [I-D.ietf-sip-gruu], to permit an=

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

     &n= bsp;  immediate=0D=0Acall-back to the specific device which placed the=

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

     &n= bsp;  emergency=0D=0Acall.

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

 

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

And a littl= e later:

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

   5.  = Either a P-Asserted-Identity=0D=0A[RFC3325] or an Identity header

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

       [RFC4= 474], or=0D=0Aboth, MUST be included to identify the sender.

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

 

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

=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /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

Specifically in reference to (6) above, I believe=0D=0Athat there is a pot= ential issue.  The statement that the contact header=0D=0AMUST be glob= ally routable is not sufficient.  It MUST also be usable for a=0D=0Ape= riod of time after the call completes. 

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

 

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

If one looks at a situation where there is a Session=0D=0ABorder Con= troller (SBC) between the SIP phone and the PSAP, the SBC may replace=0D=0A= the contact header with a temporary address that although is globally routa= ble=0D=0Ais ONLY valid for the duration of the call.  A GRUU would sat= isfy both of=0D=0Athese conditions, however so would any other globally rou= table SIP URI for the=0D=0Aoriginating phone that remained valid after the = call completion.  A GRUU=0D=0Awould be preferred.

=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 am suggesting the the wording be strengthened=0D=0Asom= ewhat to ensure that the Contact URI MUST be usable for callback for a shor= t=0D=0Aperiod of time after the call completes (e.g. a few minutes) an= d=0D=0Athe a GRUU SHOULD be specified.

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

 

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

Of course if the phone is disconnected, etc then the=0D=0Acont= act may not be usable at all after the call and the other address fields=0D= =0A(e.g. the AOR) will need to be used for callback which may or may not re= ach the=0D=0Acaller directly.  In most cases the phone will remain ope= rational following=0D=0Athe call completion and the contact information sho= uld allow the originating=0D=0Aphone to be reached directly.<= span lang=3DEN-US>

=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=3DArial>Perry

=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=0AThis message is for the designated = recipient only and may
=0D=0Acontain privileged,&nbs= p;proprietary, or otherwise private information. &= nbsp;
=0D=0AIf you have received it in err= or, please notify the sender
=0D=0Aimmediately = and delete the original.  Any unauthorized&nb= sp;use of
=0D=0Athis email is prohibited.
=0D=0A-= ---------------------------------------------------------------------------= --------------------
=0D=0A[mf2]=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C8ABDB.F65590A1-- --===============0612280168== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0612280168==-- From ecrit-bounces@ietf.org Sat May 3 10:32:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B753A6D68; Sat, 3 May 2008 10:32:51 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A458A3A6D68 for ; Sat, 3 May 2008 10:32:50 -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 hBO8cIK+xPoz for ; Sat, 3 May 2008 10:32:49 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5907E3A685D for ; Sat, 3 May 2008 10:32:48 -0700 (PDT) Received: (qmail invoked by alias); 03 May 2008 17:32:50 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp046) with SMTP; 03 May 2008 19:32:50 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/GtWY4Cf7GpeMYFbf0DLC7YeXAKNWK/S/b8/+Fmf 9H/rjaeDGcuui/ Message-ID: <481CA1BF.5090702@gmx.net> Date: Sat, 03 May 2008 20:32:47 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ken carlberg References: <7F76FF71-3527-4890-9AE8-3B01DB685045@g11.org.uk> In-Reply-To: <7F76FF71-3527-4890-9AE8-3B01DB685045@g11.org.uk> X-Y-GMX-Trusted: 0 Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] terminology question X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Ken, ken carlberg wrote: > Hannes, > > my apologies for the mundane question (and if I missed it in some > document), but I just wanted to chase down a question of terminology > for the sake of preciseness. > > within the scope of ECRIT, how are you defining civilian and authority > when using the terms civilian-to-authority and authority-to-authority? > > We don't have explicit terms in our documents since there are already well established terms. > for me, I gravitate to civilian = general public, and authority are > people working on behalf of the government (Federal, state, local, > tribal) for the common good. Sounds good. > Examples of "authority" in the ECRIT > perspective would be fireman, police, dispatchers, even militia (e.g., > National Guard that gets mobilized during disasters). On the other > hand, I wouldn't characterize those that work for vendors, ISPs, the > PSTN as "authority". Would you agree with this perspective? > Yep. Ciao Hannes > -ken > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 3 10:50:24 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA4B3A6DFD; Sat, 3 May 2008 10:50:24 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFCE028C16E for ; Sat, 3 May 2008 10:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 c8ETKXlPBa3o for ; Sat, 3 May 2008 10:50:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1F1E428C294 for ; Sat, 3 May 2008 10:48:55 -0700 (PDT) Received: (qmail invoked by alias); 03 May 2008 17:48:56 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp056) with SMTP; 03 May 2008 19:48:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX189/CxdBxE9gENoUNMccc96yelv8pWYnEIMWwe/rO AykMFiU7XaWEid Message-ID: <481CA585.9080201@gmx.net> Date: Sat, 03 May 2008 20:48:53 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Perry Prozeniuk References: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Callbacks and phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Perry, interesting that you mention call-backs. I asked a question about = call-backs at the last emergency services workshop to better = differentiate the * "nice-to-have" features, and the * requirement from a regulatory point of view. Here is what I understood: It is required from a regulator point of view = to supply the PSAP with some mechanism to call you back. This would = already be covered by the AoR. There is, however, no regulatory requirement to * have the call-back being marked as "emergency call" * have the call-back being treated differently than any other normal = call (including the ability to bypass authorization policies, etc.) I am particularly pointing to this differentiation since we (including = the 3GPP) add a lot of features along the way that are, strictly = speaking, nice but not fundamentally necessary. As such, a number of the = features we are discussing (like making callbacks from the PSAP to the = end host) are more or less "nice-to-have" rather than anything else. I understand your suggestion and I think it is useful to make sure that = some "state" remains present for some amount of time, particularly with = the desire to reach exactly the device where the call came from originally. As such, I wonder whether the requirement for GRUU (as a "MUST") isn't = even a bit strong in that case. It is nice to use GRUU, if available, = but if it isn't then that is not a disaster either. Feedback appreciated! Ciao Hannes PS: The SIP Identity you mention loosely relates to callbacks as such. = Providing the PSAP with identity information about the caller is = important for several reasons. Perry Prozeniuk wrote: > As part of the NENA CPE IP Capable PSAP working group we have been = > looking into the SIP callback information and how the PSAP will use this. > In phonebcp, following references are found: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 3. The From header MUST be present and SHOULD be the AoR of the > caller. > =85 > 6. A Contact header MUST be present which MUST be globally > routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an > immediate call-back to the specific device which placed the > emergency call. > And a little later: > 5. Either a P-Asserted-Identity [RFC3325] or an Identity header > [RFC4474], or both, MUST be included to identify the sender. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Specifically in reference to (6) above, I believe that there is a = > potential issue. The statement that the contact header MUST be = > globally routable is not sufficient. It MUST also be usable for a = > period of time after the call completes. > If one looks at a situation where there is a Session Border Controller = > (SBC) between the SIP phone and the PSAP, the SBC may replace the = > contact header with a temporary address that although is globally = > routable is ONLY valid for the duration of the call. A GRUU would = > satisfy both of these conditions, however so would any other globally = > routable SIP URI for the originating phone that remained valid after = > the call completion. A GRUU would be preferred. > I am suggesting the the wording be strengthened somewhat to ensure = > that the Contact URI MUST be usable for callback for a short period of = > time after the call completes (e.g. a few minutes) and the a GRUU = > SHOULD be specified. > Of course if the phone is disconnected, etc then the contact may not = > be usable at all after the call and the other address fields (e.g. the = > AOR) will need to be used for callback which may or may not reach the = > caller directly. In most cases the phone will remain operational = > following the call completion and the contact information should allow = > the originating phone to be reached directly. > > Perry > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 3 10:54:00 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D433A6BB7; Sat, 3 May 2008 10:54:00 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22EF03A6DD5 for ; Sat, 3 May 2008 10:53:59 -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 t0YzhC0fw0p9 for ; Sat, 3 May 2008 10:53:57 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 847E83A68BF for ; Sat, 3 May 2008 10:53:27 -0700 (PDT) Received: (qmail invoked by alias); 03 May 2008 17:53:27 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp058) with SMTP; 03 May 2008 19:53:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19XhfVrotRXhVH9vtk0k3ED4z06yK7YOE3Ryfw9va HxTgYb/Oqq51yl Message-ID: <481CA694.5000302@gmx.net> Date: Sat, 03 May 2008 20:53:24 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Richard Barnes References: <47FBBA34.1050704@gmx.net> <481775CA.1040101@bbn.com> In-Reply-To: <481775CA.1040101@bbn.com> X-Y-GMX-Trusted: 0 Cc: Roger Hixson , ecrit@ietf.org Subject: Re: [Ecrit] NENA NG9-1-1 related Standard for review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Roger, a question from a procedural point of view: How are Richards comments = handled? Ciao Hannes Richard Barnes wrote: > Document: Functional and Interface Standards for Next Generation 9-1-1 = > Version 1.0 (i3) > Reviewer: Richard L. Barnes > Date: 29 April, 2008 > > I have reviewed Sections 1, 2, 3, 4, 5.1, 5.2, 6, 7, 8, and 9 of this = > document. It is basically technically sound, in that the architecture = > it describes seems to meet the functional requirements of the NG9-1-1 = > system. My major reservation is that the security requirements and = > properties of this system are largely undefined and highly reliant on = > perimeter defenses. Specific comments follow. > > Major technical comments: > > General: > It is unclear in what manner ESInets are connected to each other, = > i.e., at what layer they are peered. Is it intended that they be = > physically connected (physical/link layer)? That they be connected at = > the IP layer (e.g., over a tunnel or VPN)? Or that they exchange = > messages over public IP networks? These choices have very different = > security implications, so even if a single scheme is not chosen, there = > should be a discussion of trade-offs. Section 4.2.5.3 says that they = > are connected at the =93IP (router) level=94, but even then, it=92s not = > clear whether the routers have to be physically connected or whether = > they can have an IP network in between them. > > General: > It=92s not clear what value the SOA sections (Section 4.6 and Section 6) = > add to this document, since it seems like they are simply a recitation = > of the Web Services canon. If the point is simply to say that web = > service and corresponding discovery systems will be offered over the = > ESInet, then that=92s what should be said. Note also that several of = > the services described in Section 7 are not web services, e.g., the = > agency registry (Section 7.6) is an LDAP service. > > General: > Section 9 needs to be substantially reduced or eliminated. Without a = > model for what security guarantees the system is to provide and how it = > is to provide them (presumably the eventual contents of Section 4.7), = > the list of technologies in Section 9 is useless. Moreover, by = > presenting them without context, there is a risk that entities will = > claim compliance with the =93i3 security model=94 without actually = > providing the necessary security properties. > > Lines 768-733 (Section 4.2.1, paragraph starting =93While other standard = > bodies=85=94) > This distinction between the IETF and the 3GPP[2] is unnecessary. The = > suite of protocols defined by the IETF is equally well suited to = > proxy-based routing as to endpoint-based routing. Indeed, the IMS = > architecture is based on these protocols. What should be here is a = > discussion of the separation between AIP and CSP, which leads to a = > requirement for the endpoint to be delivered location in certain = > circumstances. > > Line 1147 (Section 4.3.3, paragraph starting =93The user initiates=85=94) > This paragraph says that the UE =93evaluates the SIP URI=94 to recognize = > an emergency call. What does this examination entail? Suggest = > changing =93SIP URI=94 or =93Service URN=94. > > Line 1504 (Section 4.7) > This section should at least define what it means by =93Security Domain= =94 = > in figure 4-19, e.g., by choosing one of the eight definitions in RFC = > 4949. Any commentary on what security services are available within = > and between domains would be helpful, as well as on the implications = > of these choices. > > Line 1576 (Section 5.1.1) > This section essentially specifies that BCFs will act as = > application-layer gateways (ALGs) for SIP traffic. Experience in the = > SIP community has shown that ALGs tend to reduce the reliability of = > call establishment through them, so there is a risk that the use of = > BCFs in this way could add brittleness to the ESInet. Note also that = > if the BCF does not act as a back-to-back user agent (B2BUA), then BCF = > manipulation of firewall rules is pointless, since media traffic will = > likely not pass back through this BCF. > > Line 2423 (Section 7.4) > Why is this service associated with the ECRF, instead of a location = > function (LIS/LRF/LDF), or possibly a third party service (via UDDI)? = > The point of delivery for this service should be left unspecified, as = > it is for most other services here. > > > Minor technical comments: > > Line 515 (Paragraph starting =93Calls will be multimedia=85=94) > It should be clarified that the list of media types here is not = > exhaustive; i.e., other media types might be added in the future. > > Line 522 (Section 4.1.2 Functional architecture) > Location functions (LRF/LDF/LAF) are missing from this diagram. = > Should they be illustrated in the access network? > > Line 577 (Location Validation Function) > This bullet should make it clear that the MSAG is not present in this = > architecture, and that the reference to it here is only for purposes = > of analogy. (This is essentially what=92s in the footnote, but this is = > an important point.) > > Line 670 (Section 4.1.4, paragraph starting =93This example physical = > architecture=85=94) > It would be helpful here to have a brief statement of how an ESNet = > differs from an ESInet > > Line 808 (Section 4.2.1.1) > The reference to the Revised Civic document should be to RFC 5139. > > Lines 1094-1097 (Section 4.3.2) > E-CSCF: I was under the impression that the E-CSCF was intended to be = > part of the access network (as opposed to part of the ESInet. > S-CSCF: This term has not been defined in this section. > I would have thought that the ESRP would behave like an I-CSCF, in = > that it is a public-facing CSCF. > > Line 1144 (Figure 5-3) > The IP-CAN line in this figure should be deleted. It=92s confusing that = > only some of the lines where location is sent are so labeled; it = > should be added where not present. > > Lines 1352, 1356 (Section 4.5.2, paragraph starting =93The LIS is = > responsible=85=94) > The term =93Phase II=94 has not been defined in this document. > > Lines 2435, 2449 (Section 7.6, 7.7) > These sections use the all-caps words =93MUST=94. Is this word intended = > to be used as in RFC 2119? If not, please change to lower/mixed caps; = > if so, please include a reference to RFC 2119. > > Line 2654 (Section 9, first paragraph) > Capitalization of =93IPSEC=94 should be =93IPsec=94. > > > Editorial comments: > > Line 333 (Table of acronyms): > In the definitions for 3GPP and 3GPP2, there=92s a discrepancy between = > 3rd and 3RD. > IETF working group names (e.g., ECRIT, GEOPRIV) should be capitalized. > =93IPSec=94 should be capitalized as =93IPsec=94. > > Line 731 (Incident Identifier) > The phrase =93URI GUID=94 is incorrect. It seems to me that it should = > simply be a =93GUID=94, but if it=92s a URI encoding a GUID, then the = > correct phrase is =93GUID URI=94. > > Line 808 (Section 4.2.1.1) > The hyphen in =93RFC-4119=94 should be deleted. > > Line 815 (Section 4.2.1.2, paragraph starting =93The construction=85=94) > The phrase =93user part=94 should be deleted, since this term is not = > defined for many URI types. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 3 11:20:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11B43A6A29; Sat, 3 May 2008 11:20:13 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21D83A69D2 for ; Sat, 3 May 2008 11:20:12 -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 nK1VHUHjHNNE for ; Sat, 3 May 2008 11:20:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 850EE3A6DDF for ; Sat, 3 May 2008 11:19:47 -0700 (PDT) Received: (qmail invoked by alias); 03 May 2008 18:19:48 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp007) with SMTP; 03 May 2008 20:19:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/eUR5Hcz7eDUxrzNq/bMjKSCTIP2S9AoEAh3gW0I fipWr3dbuwsjmi Message-ID: <481CACC0.3050403@gmx.net> Date: Sat, 03 May 2008 21:19:44 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" References: <5F8EDB43-8F83-49A0-A1BA-F841BD1C9395@g11.org.uk> <5D1A7985295922448D5550C94DE2918001E99973@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001E99973@DEEXC1U01.de.lucent.com> X-Y-GMX-Trusted: 0 Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org, tsvwg@ietf.org Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Keith, there are 4 types of emergency services: - citizen to authority - authority to authority - authority to citizen - citizen to citizen Nowadays people tend to use "individuals" as a replacement for "citizen". These terms are defined in ETSI EMTEL documents (and typically used in the same fashion everywhere). I have to check whether the ECRIT framework draft says that our work is about "citizen to authority" emergency services. The context should make it clear, however. It does not hurt to be explicit. I don't have fears that someone could get a wrong impression about the purpose of our work. I am obviously not so sure about the current TSVWG document. We have organized a couple of workshops and talked to the different stakeholders in the space of "citizen to authority" emergency services and we had to realize that balancing the different interests is very challenging to accomplish some deployment. Now, I claim that authority-to-authority and authority-to-citizen is not any easier to deploy. We see a document that specifies a fairly small extension to RSVP (considering that some other work has been done in the context of IEPREP/SIP) on resource priority headers and I do have the impression that there is a big deployment problem. The IESG had no interest to let IEPREP to proceed but ironically the real world happened elsewhere anyway, namely SIP and TSVWG. To some extend this is a more generic discussion for the IETF. Do we want to develop architectures or just some building blocks and let other folks figure out how to use it in a reasonable way? If we were to cover authority-to-authority emergency services as part of the emergency services workshops and invite the respective players then I could imagine that we will not find too many folks that plan to use path-coupled signaling (particularly not when used with the end host). Instead, I believe that they will only want to make use of it as part of an IMS architecture and hence they would want to use the PCC framework. Obviously this is quite challenging: Start with the building blocks and then later develop the architecture (maybe let other SDOs do the architecture instead of the IETF) vs. have an architecture in mind and then develop the building blocks. (Sometimes a few building blocks are useful in various architectures.) I don't want to be the roadblock here (and I do get the impression that nearly everyone does not have a lot of opinion regarding the work) but I would like to understand what you were thinking when you did the work. Maybe you just wrote something that sounded nice but maybe you had a useful architecture in mind but you just did not write it down anywhere. Even with the "new" resource priority header work in SIP one can observe the conflict between the architectural preference some folks in the IETF have and the communication architecture preferred by other SDOs. Security is a classical example where these "tussels" become visible. Ciao Hannes DRAGE, Keith (Keith) wrote: > Slightly tongue in cheek, but the point is real. > > Hannes, > > Perhaps you should also be clarifying in all the drafts produced by > ECRIT that the communication is citizen to authority, as exactly the > same confusion of terminology appears there. > > I understand the taxonomy of emergency calls is generally subdivided as > follows: > > - citizen to authority > - authority to authority > - authority to citizen > > All of these can be referred to emergency calls. > > Regards > > Keith > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of James M. Polk >> Sent: Tuesday, April 29, 2008 4:03 PM >> To: hannes.tschofenig@nsn.com; carlberg@g11.org.uk >> Cc: ecrit@ietf.org; tsvwg@ietf.org >> Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG >> >> At 03:49 AM 4/29/2008, hannes.tschofenig@nsn.com wrote: >> >>> Hi Ken, >>> >>> I would be very happy if you could state explicitly that you want to >>> use the mechanisms in that document for >>> >> authority-to-authority type of >> >>> emergency services rather than for other types of emergency services. >>> >> The abstract starts with >> >> "An Emergency Telecommunications Service (ETS)..." >> which means a GETS type of service, which clearly isn't C2A >> based, as evidenced by the references within the opening >> sentence of the Intro >> >> "[RFC3689] and >> [RFC3690] detail >> requirements for >> an Emergency Telecommunications Service (ETS)..." >> >> >> >>> For citizien-to-authority I definitely see a lot of problems and >>> regarding early warning (authority-to-citizen) we haven't >>> >> even worked on >> >>> the architecture and therefore it is very hard to tell how >>> >> it would be >> >>> used -- we will see in the future. >>> >>> Ciao >>> Hannes >>> >>> >>>> -----Original Message----- >>>> From: ext ken carlberg [mailto:carlberg@g11.org.uk] >>>> Sent: 28 April, 2008 15:20 >>>> To: Tschofenig Hannes (NSN - FI/Espoo) >>>> Cc: ecrit@ietf.org; tsvwg@ietf.org >>>> Subject: Re: [Tsvwg] Emergency Services work in TSVWG >>>> >>>> whoa, slow down a bit! >>>> >>>> On Apr 28, 2008, at 6:47 AM, wrote: >>>> >>>>> Hi all, >>>>> >>>>> In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the >>>>> impression that the document is not only used for authority-to- >>>>> authority communication but also for citizen-to-authority >>>>> communication. >>>>> >>>>> Here is my review comment: >>>>> " >>>>> * I think the document needs to indicate clearly that >>>>> >>>> this mechanism >>>> >>>>> is supposed to be used for authority-to-authority >>>>> >> emergency services >> >>>>> and not for citizen-to-authority/authority-to-citizen >>>>> emergency >>>>> services. >>>>> " >>>>> >>>>> As a response I received: >>>>> >>>>> " >>>>> I would disagree. What you are asking for would be best >>>>> >> placed in a >> >>>>> separate applicability draft. For instance, while I >>>>> >> mostly agree >> >>>>> with >>>>> your above assertion, I can also envision an exception in >>>>> >>>> the case of >>>> >>>>> Japan's 911-like service, where preferential treatment is >>>>> >>>> supported in >>>> >>>>> their PSTN for these types of many-to-1 call flows. Hence, more >>>>> elaborate discussions on use cases and applicability is >>>>> >> really best >> >>>>> served in a different document. >>>>> " >>>>> >>>>> Now, I wonder whether the ECRIT WG is aware of the desire of some >>>>> folks in TSVWG to have these types of QoS mechanisms to go into >>>>> citizen-to-authority emergency services architecture? We are >>>>> >>>> currently >>>> >>>>> finishing our architecture document and this document >>>>> >> seems to touch >> >>>>> that space without being explicit. >>>>> >>>> Please *carefully* note that in my response on the tsvwg list >>>> I said "...I can also envision..." >>>> >>>> ^ ^^ in no >>>> way did I state any desire or advocacy, one way or the other, >>>> to see the proposed extension used for citizen-to-authority >>>> emergency services. I'm agnostic in that regard, and I want >>>> the cited tsvwg >>>> draft to remain that way. And as I also stated above, its up to >>>> another document outside of the cited tsvwg draft to discuss >>>> its applicability -- in the context of this note, that would >>>> be the ECRIT architecture draft. >>>> >>>> if pressed on the matter, I would initially advocate a >>>> position that the draft-ietf-tsvwg-emergency-rsvp-07.txt MAY >>>> be used for citizen- to-authority emergency services. But I >>>> haven't followed ECRIT very closely of late, so I'll certainly >>>> defer to the consensus of others actively participating in the >>>> ECRIT architecture document. >>>> >>>> cheers, >>>> >>>> -ken >>>> >>>> >>>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 3 12:32:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1863A6A17; Sat, 3 May 2008 12:32:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB4F3A6A17 for ; Sat, 3 May 2008 12:32:10 -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 HQhXb395jRaX for ; Sat, 3 May 2008 12:32:09 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 065D83A69FF for ; Sat, 3 May 2008 12:32:08 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JsNSl-00073U-JO; Sat, 03 May 2008 14:32:03 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Perry Prozeniuk'" References: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> <481CA585.9080201@gmx.net> Date: Sat, 3 May 2008 15:32:06 -0400 Message-ID: <037e01c8ad54$60ecaa00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcitRirzU4AksRD2SlOfsjPEhhmsewADW2Tg In-Reply-To: <481CA585.9080201@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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@ietf.org Subject: Re: [Ecrit] Callbacks and phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The call back requirement is not a legal requirement, but it is a hard requirement. I believe, and I'll get NENA to express an opinion if you need one, that given how IP devices work, an address that can be used to get back to the device that placed the call, which may be different from the AoR, is a requirement, not a nice to have. In all other services, there really is only one device per TN (ignoring the multiple devices on one number in a wireline environment). The TN is a sufficient address to get back to the device that placed the call if the call is inadvertently dropped for some reason. With IP services, we have a very real possibility that we would NOT get back to the same device. You can, if you want, make -phonebcp more complex by saying you don't have to have Contact with a GRUU if AoR will reliably get you back to the same device if called within the (15/30) minute window we have been discussing. I'd rather leave it as it is. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Saturday, May 03, 2008 1:49 PM To: Perry Prozeniuk Cc: ecrit@ietf.org Subject: Re: [Ecrit] Callbacks and phonebcp Hi Perry, interesting that you mention call-backs. I asked a question about call-backs at the last emergency services workshop to better differentiate the * "nice-to-have" features, and the * requirement from a regulatory point of view. Here is what I understood: It is required from a regulator point of view to supply the PSAP with some mechanism to call you back. This would already be covered by the AoR. There is, however, no regulatory requirement to * have the call-back being marked as "emergency call" * have the call-back being treated differently than any other normal call (including the ability to bypass authorization policies, etc.) I am particularly pointing to this differentiation since we (including the 3GPP) add a lot of features along the way that are, strictly speaking, nice but not fundamentally necessary. As such, a number of the features we are discussing (like making callbacks from the PSAP to the end host) are more or less "nice-to-have" rather than anything else. I understand your suggestion and I think it is useful to make sure that some "state" remains present for some amount of time, particularly with the desire to reach exactly the device where the call came from originally. As such, I wonder whether the requirement for GRUU (as a "MUST") isn't even a bit strong in that case. It is nice to use GRUU, if available, but if it isn't then that is not a disaster either. Feedback appreciated! Ciao Hannes PS: The SIP Identity you mention loosely relates to callbacks as such. Providing the PSAP with identity information about the caller is important for several reasons. Perry Prozeniuk wrote: > As part of the NENA CPE IP Capable PSAP working group we have been > looking into the SIP callback information and how the PSAP will use this. > In phonebcp, following references are found: > ============== > 3. The From header MUST be present and SHOULD be the AoR of the > caller. > . > 6. A Contact header MUST be present which MUST be globally > routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an > immediate call-back to the specific device which placed the > emergency call. > And a little later: > 5. Either a P-Asserted-Identity [RFC3325] or an Identity header > [RFC4474], or both, MUST be included to identify the sender. > ============= > Specifically in reference to (6) above, I believe that there is a > potential issue. The statement that the contact header MUST be > globally routable is not sufficient. It MUST also be usable for a > period of time after the call completes. > If one looks at a situation where there is a Session Border Controller > (SBC) between the SIP phone and the PSAP, the SBC may replace the > contact header with a temporary address that although is globally > routable is ONLY valid for the duration of the call. A GRUU would > satisfy both of these conditions, however so would any other globally > routable SIP URI for the originating phone that remained valid after > the call completion. A GRUU would be preferred. > I am suggesting the the wording be strengthened somewhat to ensure > that the Contact URI MUST be usable for callback for a short period of > time after the call completes (e.g. a few minutes) and the a GRUU > SHOULD be specified. > Of course if the phone is disconnected, etc then the contact may not > be usable at all after the call and the other address fields (e.g. the > AOR) will need to be used for callback which may or may not reach the > caller directly. In most cases the phone will remain operational > following the call completion and the contact information should allow > the originating phone to be reached directly. > > Perry > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 3 12:45:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0923A6A56; Sat, 3 May 2008 12:45:57 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C2B3A6982 for ; Sat, 3 May 2008 12:45:55 -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 foBd1GXgc2te for ; Sat, 3 May 2008 12:45:54 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7936F3A68D5 for ; Sat, 3 May 2008 12:45:53 -0700 (PDT) Received: (qmail invoked by alias); 03 May 2008 19:45:53 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp006) with SMTP; 03 May 2008 21:45:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+26tgmRI62dh467HmS74f5or9FFL1YxilFFjBk5E M+vyjGXWC0QG/0 Message-ID: <481CC0ED.3050507@gmx.net> Date: Sat, 03 May 2008 22:45:49 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Brian Rosen References: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> <481CA585.9080201@gmx.net> <037e01c8ad54$60ecaa00$640fa8c0@cis.neustar.com> In-Reply-To: <037e01c8ad54$60ecaa00$640fa8c0@cis.neustar.com> X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Callbacks and phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am not saying it is not useful but there is clearly a slippery slope. The 3GPP emergency registration (unless I misunderstood it), the discussion dealing with authorization policies and other supplementary services, using emergency call marking for callbacks, etc. quickly turn a simple thing into something complex. Do we (NENA, for example) actually have some statistical data about callbacks? Ciao Hannes Brian Rosen wrote: > The call back requirement is not a legal requirement, but it is a hard > requirement. I believe, and I'll get NENA to express an opinion if you need > one, that given how IP devices work, an address that can be used to get back > to the device that placed the call, which may be different from the AoR, is > a requirement, not a nice to have. > > In all other services, there really is only one device per TN (ignoring the > multiple devices on one number in a wireline environment). The TN is a > sufficient address to get back to the device that placed the call if the > call is inadvertently dropped for some reason. With IP services, we have a > very real possibility that we would NOT get back to the same device. > > You can, if you want, make -phonebcp more complex by saying you don't have > to have Contact with a GRUU if AoR will reliably get you back to the same > device if called within the (15/30) minute window we have been discussing. > I'd rather leave it as it is. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Saturday, May 03, 2008 1:49 PM > To: Perry Prozeniuk > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Callbacks and phonebcp > > Hi Perry, > > interesting that you mention call-backs. I asked a question about > call-backs at the last emergency services workshop to better > differentiate the > * "nice-to-have" features, and the > * requirement from a regulatory point of view. > > Here is what I understood: It is required from a regulator point of view > to supply the PSAP with some mechanism to call you back. This would > already be covered by the AoR. > > There is, however, no regulatory requirement to > * have the call-back being marked as "emergency call" > * have the call-back being treated differently than any other normal > call (including the ability to bypass authorization policies, etc.) > > I am particularly pointing to this differentiation since we (including > the 3GPP) add a lot of features along the way that are, strictly > speaking, nice but not fundamentally necessary. As such, a number of the > features we are discussing (like making callbacks from the PSAP to the > end host) are more or less "nice-to-have" rather than anything else. > > I understand your suggestion and I think it is useful to make sure that > some "state" remains present for some amount of time, particularly with > the desire to reach exactly the device where the call came from originally. > > As such, I wonder whether the requirement for GRUU (as a "MUST") isn't > even a bit strong in that case. It is nice to use GRUU, if available, > but if it isn't then that is not a disaster either. > > Feedback appreciated! > > Ciao > Hannes > > PS: The SIP Identity you mention loosely relates to callbacks as such. > Providing the PSAP with identity information about the caller is > important for several reasons. > > > > Perry Prozeniuk wrote: > >> As part of the NENA CPE IP Capable PSAP working group we have been >> looking into the SIP callback information and how the PSAP will use this. >> In phonebcp, following references are found: >> ============== >> 3. The From header MUST be present and SHOULD be the AoR of the >> caller. >> . >> 6. A Contact header MUST be present which MUST be globally >> routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an >> immediate call-back to the specific device which placed the >> emergency call. >> And a little later: >> 5. Either a P-Asserted-Identity [RFC3325] or an Identity header >> [RFC4474], or both, MUST be included to identify the sender. >> ============= >> Specifically in reference to (6) above, I believe that there is a >> potential issue. The statement that the contact header MUST be >> globally routable is not sufficient. It MUST also be usable for a >> period of time after the call completes. >> If one looks at a situation where there is a Session Border Controller >> (SBC) between the SIP phone and the PSAP, the SBC may replace the >> contact header with a temporary address that although is globally >> routable is ONLY valid for the duration of the call. A GRUU would >> satisfy both of these conditions, however so would any other globally >> routable SIP URI for the originating phone that remained valid after >> the call completion. A GRUU would be preferred. >> I am suggesting the the wording be strengthened somewhat to ensure >> that the Contact URI MUST be usable for callback for a short period of >> time after the call completes (e.g. a few minutes) and the a GRUU >> SHOULD be specified. >> Of course if the phone is disconnected, etc then the contact may not >> be usable at all after the call and the other address fields (e.g. the >> AOR) will need to be used for callback which may or may not reach the >> caller directly. In most cases the phone will remain operational >> following the call completion and the contact information should allow >> the originating phone to be reached directly. >> >> Perry >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat May 3 12:56:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272853A6B5F; Sat, 3 May 2008 12:56:41 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090EE3A694C for ; Sat, 3 May 2008 12:56: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=[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 jdHveuZ1NamD for ; Sat, 3 May 2008 12:56:37 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id D5B183A68D5 for ; Sat, 3 May 2008 12:56:37 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JsNqS-0000Fi-GK; Sat, 03 May 2008 14:56:32 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" References: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> <481CA585.9080201@gmx.net> <037e01c8ad54$60ecaa00$640fa8c0@cis.neustar.com> <481CC0ED.3050507@gmx.net> Date: Sat, 3 May 2008 15:56:35 -0400 Message-ID: <038201c8ad57$cc9b29e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcitVkqTI1ZOooY4SSysMO1+mlH3pAAAKTeQ In-Reply-To: <481CC0ED.3050507@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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@ietf.org Subject: Re: [Ecrit] Callbacks and phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yah, I hear you, but I think it's inevitable. The emergency registration is a result of unauthenticated device support. Supplementary service disabling, if that is what you are talking about, has been implemented in wireline and wireless for a very long time Call back marking is a new one. I believe the issue comes from a variety of new services which restrict who can call in to a device. We're facing this very problem now with new wireless services (parental control of who can call their children for example). Brian -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Saturday, May 03, 2008 3:46 PM To: Brian Rosen Cc: 'Perry Prozeniuk'; ecrit@ietf.org Subject: Re: [Ecrit] Callbacks and phonebcp I am not saying it is not useful but there is clearly a slippery slope. The 3GPP emergency registration (unless I misunderstood it), the discussion dealing with authorization policies and other supplementary services, using emergency call marking for callbacks, etc. quickly turn a simple thing into something complex. Do we (NENA, for example) actually have some statistical data about callbacks? Ciao Hannes Brian Rosen wrote: > The call back requirement is not a legal requirement, but it is a hard > requirement. I believe, and I'll get NENA to express an opinion if you need > one, that given how IP devices work, an address that can be used to get back > to the device that placed the call, which may be different from the AoR, is > a requirement, not a nice to have. > > In all other services, there really is only one device per TN (ignoring the > multiple devices on one number in a wireline environment). The TN is a > sufficient address to get back to the device that placed the call if the > call is inadvertently dropped for some reason. With IP services, we have a > very real possibility that we would NOT get back to the same device. > > You can, if you want, make -phonebcp more complex by saying you don't have > to have Contact with a GRUU if AoR will reliably get you back to the same > device if called within the (15/30) minute window we have been discussing. > I'd rather leave it as it is. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Saturday, May 03, 2008 1:49 PM > To: Perry Prozeniuk > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Callbacks and phonebcp > > Hi Perry, > > interesting that you mention call-backs. I asked a question about > call-backs at the last emergency services workshop to better > differentiate the > * "nice-to-have" features, and the > * requirement from a regulatory point of view. > > Here is what I understood: It is required from a regulator point of view > to supply the PSAP with some mechanism to call you back. This would > already be covered by the AoR. > > There is, however, no regulatory requirement to > * have the call-back being marked as "emergency call" > * have the call-back being treated differently than any other normal > call (including the ability to bypass authorization policies, etc.) > > I am particularly pointing to this differentiation since we (including > the 3GPP) add a lot of features along the way that are, strictly > speaking, nice but not fundamentally necessary. As such, a number of the > features we are discussing (like making callbacks from the PSAP to the > end host) are more or less "nice-to-have" rather than anything else. > > I understand your suggestion and I think it is useful to make sure that > some "state" remains present for some amount of time, particularly with > the desire to reach exactly the device where the call came from originally. > > As such, I wonder whether the requirement for GRUU (as a "MUST") isn't > even a bit strong in that case. It is nice to use GRUU, if available, > but if it isn't then that is not a disaster either. > > Feedback appreciated! > > Ciao > Hannes > > PS: The SIP Identity you mention loosely relates to callbacks as such. > Providing the PSAP with identity information about the caller is > important for several reasons. > > > > Perry Prozeniuk wrote: > >> As part of the NENA CPE IP Capable PSAP working group we have been >> looking into the SIP callback information and how the PSAP will use this. >> In phonebcp, following references are found: >> ============== >> 3. The From header MUST be present and SHOULD be the AoR of the >> caller. >> . >> 6. A Contact header MUST be present which MUST be globally >> routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an >> immediate call-back to the specific device which placed the >> emergency call. >> And a little later: >> 5. Either a P-Asserted-Identity [RFC3325] or an Identity header >> [RFC4474], or both, MUST be included to identify the sender. >> ============= >> Specifically in reference to (6) above, I believe that there is a >> potential issue. The statement that the contact header MUST be >> globally routable is not sufficient. It MUST also be usable for a >> period of time after the call completes. >> If one looks at a situation where there is a Session Border Controller >> (SBC) between the SIP phone and the PSAP, the SBC may replace the >> contact header with a temporary address that although is globally >> routable is ONLY valid for the duration of the call. A GRUU would >> satisfy both of these conditions, however so would any other globally >> routable SIP URI for the originating phone that remained valid after >> the call completion. A GRUU would be preferred. >> I am suggesting the the wording be strengthened somewhat to ensure >> that the Contact URI MUST be usable for callback for a short period of >> time after the call completes (e.g. a few minutes) and the a GRUU >> SHOULD be specified. >> Of course if the phone is disconnected, etc then the contact may not >> be usable at all after the call and the other address fields (e.g. the >> AOR) will need to be used for callback which may or may not reach the >> caller directly. In most cases the phone will remain operational >> following the call completion and the contact information should allow >> the originating phone to be reached directly. >> >> Perry >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun May 4 17:05:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D27B3A6B3D; Sun, 4 May 2008 17:05:30 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 545B73A69A5 for ; Sun, 4 May 2008 17:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.67 X-Spam-Level: ** X-Spam-Status: No, score=2.67 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, 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 yq-FGTgdiC0y for ; Sun, 4 May 2008 17:05:28 -0700 (PDT) Received: from [66.104.31.195] (unknown [66.104.31.195]) by core3.amsl.com (Postfix) with ESMTP id B49493A6969 for ; Sun, 4 May 2008 17:05:25 -0700 (PDT) Received: from mail.nena.org by [66.104.31.195] via smtpd (for mail.ietf.org [64.170.98.32]) with ESMTP; Sun, 4 May 2008 20:05:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 May 2008 20:05:19 -0400 Message-ID: <13B558E5E34DDA4C8B5D06A0D7DB31B601FC4F9C@nena-mail.nena-net.local> In-Reply-To: <481CA694.5000302@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] NENA NG9-1-1 related Standard for review Thread-Index: AcitRpkIaMUHHgoTRWiukRLpvHkRAAA/HZSQ References: <47FBBA34.1050704@gmx.net> <481775CA.1040101@bbn.com> <481CA694.5000302@gmx.net> From: "Roger Hixson" To: "Hannes Tschofenig" , "Richard Barnes" Cc: ecrit@ietf.org Subject: Re: [Ecrit] NENA NG9-1-1 related Standard for review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I had passed them on to the Committee leadership responsible for this area, for action as needed. They will advise on what actions they took. I am so used to liaisons never generating responses back to me (usually the other SDOs respond back to the Committee leader directly and I hear about it later) that it didn't occur to me to send you guys a `receipt' for your responses. Sorry - we do appreciate that you took action on the liaison and provided commnents back. Roger Hixson, ENP NENA Technical Issues Director NENA - The Voice of 9-1-1 614-442-9110 USA rhixson@nena.org Always make new mistakes ! -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Saturday, May 03, 2008 1:53 PM To: Richard Barnes Cc: ecrit@ietf.org; Roger Hixson Subject: Re: [Ecrit] NENA NG9-1-1 related Standard for review Hi Roger, a question from a procedural point of view: How are Richards comments handled? Ciao Hannes Richard Barnes wrote: > Document: Functional and Interface Standards for Next Generation 9-1-1 > Version 1.0 (i3) > Reviewer: Richard L. Barnes > Date: 29 April, 2008 > > I have reviewed Sections 1, 2, 3, 4, 5.1, 5.2, 6, 7, 8, and 9 of this > document. It is basically technically sound, in that the architecture > it describes seems to meet the functional requirements of the NG9-1-1 > system. My major reservation is that the security requirements and > properties of this system are largely undefined and highly reliant on > perimeter defenses. Specific comments follow. > > Major technical comments: > > General: > It is unclear in what manner ESInets are connected to each other, > i.e., at what layer they are peered. Is it intended that they be > physically connected (physical/link layer)? That they be connected at > the IP layer (e.g., over a tunnel or VPN)? Or that they exchange > messages over public IP networks? These choices have very different > security implications, so even if a single scheme is not chosen, there > should be a discussion of trade-offs. Section 4.2.5.3 says that they > are connected at the "IP (router) level", but even then, it's not > clear whether the routers have to be physically connected or whether > they can have an IP network in between them. > > General: > It's not clear what value the SOA sections (Section 4.6 and Section 6) > add to this document, since it seems like they are simply a recitation > of the Web Services canon. If the point is simply to say that web > service and corresponding discovery systems will be offered over the > ESInet, then that's what should be said. Note also that several of > the services described in Section 7 are not web services, e.g., the > agency registry (Section 7.6) is an LDAP service. > > General: > Section 9 needs to be substantially reduced or eliminated. Without a > model for what security guarantees the system is to provide and how it > is to provide them (presumably the eventual contents of Section 4.7), > the list of technologies in Section 9 is useless. Moreover, by > presenting them without context, there is a risk that entities will > claim compliance with the "i3 security model" without actually > providing the necessary security properties. > > Lines 768-733 (Section 4.2.1, paragraph starting "While other standard > bodies...") > This distinction between the IETF and the 3GPP[2] is unnecessary. The > suite of protocols defined by the IETF is equally well suited to > proxy-based routing as to endpoint-based routing. Indeed, the IMS > architecture is based on these protocols. What should be here is a > discussion of the separation between AIP and CSP, which leads to a > requirement for the endpoint to be delivered location in certain > circumstances. > > Line 1147 (Section 4.3.3, paragraph starting "The user initiates...") > This paragraph says that the UE "evaluates the SIP URI" to recognize > an emergency call. What does this examination entail? Suggest > changing "SIP URI" or "Service URN". > > Line 1504 (Section 4.7) > This section should at least define what it means by "Security Domain" > in figure 4-19, e.g., by choosing one of the eight definitions in RFC > 4949. Any commentary on what security services are available within > and between domains would be helpful, as well as on the implications > of these choices. > > Line 1576 (Section 5.1.1) > This section essentially specifies that BCFs will act as > application-layer gateways (ALGs) for SIP traffic. Experience in the > SIP community has shown that ALGs tend to reduce the reliability of > call establishment through them, so there is a risk that the use of > BCFs in this way could add brittleness to the ESInet. Note also that > if the BCF does not act as a back-to-back user agent (B2BUA), then BCF > manipulation of firewall rules is pointless, since media traffic will > likely not pass back through this BCF. > > Line 2423 (Section 7.4) > Why is this service associated with the ECRF, instead of a location > function (LIS/LRF/LDF), or possibly a third party service (via UDDI)? > The point of delivery for this service should be left unspecified, as > it is for most other services here. > > > Minor technical comments: > > Line 515 (Paragraph starting "Calls will be multimedia...") > It should be clarified that the list of media types here is not > exhaustive; i.e., other media types might be added in the future. > > Line 522 (Section 4.1.2 Functional architecture) > Location functions (LRF/LDF/LAF) are missing from this diagram. > Should they be illustrated in the access network? > > Line 577 (Location Validation Function) > This bullet should make it clear that the MSAG is not present in this > architecture, and that the reference to it here is only for purposes > of analogy. (This is essentially what's in the footnote, but this is > an important point.) > > Line 670 (Section 4.1.4, paragraph starting "This example physical > architecture...") > It would be helpful here to have a brief statement of how an ESNet > differs from an ESInet > > Line 808 (Section 4.2.1.1) > The reference to the Revised Civic document should be to RFC 5139. > > Lines 1094-1097 (Section 4.3.2) > E-CSCF: I was under the impression that the E-CSCF was intended to be > part of the access network (as opposed to part of the ESInet. > S-CSCF: This term has not been defined in this section. > I would have thought that the ESRP would behave like an I-CSCF, in > that it is a public-facing CSCF. > > Line 1144 (Figure 5-3) > The IP-CAN line in this figure should be deleted. It's confusing that > only some of the lines where location is sent are so labeled; it > should be added where not present. > > Lines 1352, 1356 (Section 4.5.2, paragraph starting "The LIS is > responsible...") > The term "Phase II" has not been defined in this document. > > Lines 2435, 2449 (Section 7.6, 7.7) > These sections use the all-caps words "MUST". Is this word intended > to be used as in RFC 2119? If not, please change to lower/mixed caps; > if so, please include a reference to RFC 2119. > > Line 2654 (Section 9, first paragraph) > Capitalization of "IPSEC" should be "IPsec". > > > Editorial comments: > > Line 333 (Table of acronyms): > In the definitions for 3GPP and 3GPP2, there's a discrepancy between > 3rd and 3RD. > IETF working group names (e.g., ECRIT, GEOPRIV) should be capitalized. > "IPSec" should be capitalized as "IPsec". > > Line 731 (Incident Identifier) > The phrase "URI GUID" is incorrect. It seems to me that it should > simply be a "GUID", but if it's a URI encoding a GUID, then the > correct phrase is "GUID URI". > > Line 808 (Section 4.2.1.1) > The hyphen in "RFC-4119" should be deleted. > > Line 815 (Section 4.2.1.2, paragraph starting "The construction...") > The phrase "user part" should be deleted, since this term is not > defined for many URI types. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 6 08:29:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17E3728C3D1; Tue, 6 May 2008 08:29:51 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D63928C3D1 for ; Tue, 6 May 2008 08:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiQuQZJpPzBb for ; Tue, 6 May 2008 08:29:48 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id A0D3D28C22F for ; Tue, 6 May 2008 08:29:48 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m46FThY16842; Tue, 6 May 2008 15:29:43 GMT x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 6 May 2008 11:29:41 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646515DB9EF1@zcarhxm1.corp.nortel.com> In-reply-to: <481CC0ED.3050507@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Callbacks and phonebcp Thread-Index: AcitVk9C9/5ddNPHQr2XyU5Z5b1qWACNQ2Eg References: <9671A92C3C8B5744BC97F855F7CB646515C588CE@zcarhxm1.corp.nortel.com> <481CA585.9080201@gmx.net> <037e01c8ad54$60ecaa00$640fa8c0@cis.neustar.com> <481CC0ED.3050507@gmx.net> From: "Perry Prozeniuk" To: "Hannes Tschofenig" , "Brian Rosen" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Callbacks and phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There are a number of issues, as you mention, around callbacks. - If the caller's "address" can be used to reach the original caller/device - If when it gets there, there are supplementary services that interfere with the call - if there is a need for mark callbacks as "emergency" such that they receive priority / different treatment. My suggestions were focused on the first point and I think it would be a "best practice" to ensure that the contact header contained an address (e.g. a GRUU) that allowed the originating device to be reachable following the call for a period of time (duration discussed earlier). The interference of supplementary services is another issue. The network would need to be expecting a callback or be able to detect one to bypass these services. Currently some systems simply disable these services for a period of time following an emergency call to allow for possible callback (similar duration discussion as the address validity). Another "best practice" would be to do just this in the absence of callbacks being marked as "emergency". Marking callbacks from PSAPS as "emergency" would enable priority treatment of these calls in the network and specific behaviors on the terminating user agents (call servers, phones, etc) that may impose supplementary services to re-route the call. It would be a "best practice" to disable/bypass these supplementary services when the call is marked as "emergency". Marking the calls as emergency and other priority handling in the network is a separate issue. This is a much more complex issue since I'm sure we could discuss at length the desire to allow the callback to be rerouted by these services in order to be able to reach the caller (perhaps on a different device). Callback's to "unauthorized" phones is another topic. Perry -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Saturday, May 03, 2008 3:46 PM To: Brian Rosen Cc: Prozeniuk, Perry (CAR:9T51); ecrit@ietf.org Subject: Re: [Ecrit] Callbacks and phonebcp I am not saying it is not useful but there is clearly a slippery slope. The 3GPP emergency registration (unless I misunderstood it), the discussion dealing with authorization policies and other supplementary services, using emergency call marking for callbacks, etc. quickly turn a simple thing into something complex. Do we (NENA, for example) actually have some statistical data about callbacks? Ciao Hannes Brian Rosen wrote: > The call back requirement is not a legal requirement, but it is a hard > requirement. I believe, and I'll get NENA to express an opinion if > you need one, that given how IP devices work, an address that can be > used to get back to the device that placed the call, which may be > different from the AoR, is a requirement, not a nice to have. > > In all other services, there really is only one device per TN > (ignoring the multiple devices on one number in a wireline > environment). The TN is a sufficient address to get back to the > device that placed the call if the call is inadvertently dropped for > some reason. With IP services, we have a very real possibility that we would NOT get back to the same device. > > You can, if you want, make -phonebcp more complex by saying you don't > have to have Contact with a GRUU if AoR will reliably get you back to > the same device if called within the (15/30) minute window we have been discussing. > I'd rather leave it as it is. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Hannes Tschofenig > Sent: Saturday, May 03, 2008 1:49 PM > To: Perry Prozeniuk > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Callbacks and phonebcp > > Hi Perry, > > interesting that you mention call-backs. I asked a question about > call-backs at the last emergency services workshop to better > differentiate the > * "nice-to-have" features, and the > * requirement from a regulatory point of view. > > Here is what I understood: It is required from a regulator point of > view to supply the PSAP with some mechanism to call you back. This > would already be covered by the AoR. > > There is, however, no regulatory requirement to > * have the call-back being marked as "emergency call" > * have the call-back being treated differently than any other normal > call (including the ability to bypass authorization policies, etc.) > > I am particularly pointing to this differentiation since we (including > the 3GPP) add a lot of features along the way that are, strictly > speaking, nice but not fundamentally necessary. As such, a number of > the features we are discussing (like making callbacks from the PSAP to > the end host) are more or less "nice-to-have" rather than anything else. > > I understand your suggestion and I think it is useful to make sure > that some "state" remains present for some amount of time, > particularly with the desire to reach exactly the device where the call came from originally. > > As such, I wonder whether the requirement for GRUU (as a "MUST") isn't > even a bit strong in that case. It is nice to use GRUU, if available, > but if it isn't then that is not a disaster either. > > Feedback appreciated! > > Ciao > Hannes > > PS: The SIP Identity you mention loosely relates to callbacks as such. > Providing the PSAP with identity information about the caller is > important for several reasons. > > > > Perry Prozeniuk wrote: > >> As part of the NENA CPE IP Capable PSAP working group we have been >> looking into the SIP callback information and how the PSAP will use this. >> In phonebcp, following references are found: >> ============== >> 3. The From header MUST be present and SHOULD be the AoR of the >> caller. >> . >> 6. A Contact header MUST be present which MUST be globally routable, >> for example a GRUU [I-D.ietf-sip-gruu], to permit an immediate >> call-back to the specific device which placed the emergency call. >> And a little later: >> 5. Either a P-Asserted-Identity [RFC3325] or an Identity header >> [RFC4474], or both, MUST be included to identify the sender. >> ============= >> Specifically in reference to (6) above, I believe that there is a >> potential issue. The statement that the contact header MUST be >> globally routable is not sufficient. It MUST also be usable for a >> period of time after the call completes. >> If one looks at a situation where there is a Session Border >> Controller >> (SBC) between the SIP phone and the PSAP, the SBC may replace the >> contact header with a temporary address that although is globally >> routable is ONLY valid for the duration of the call. A GRUU would >> satisfy both of these conditions, however so would any other globally >> routable SIP URI for the originating phone that remained valid after >> the call completion. A GRUU would be preferred. >> I am suggesting the the wording be strengthened somewhat to ensure >> that the Contact URI MUST be usable for callback for a short period >> of time after the call completes (e.g. a few minutes) and the a GRUU >> SHOULD be specified. >> Of course if the phone is disconnected, etc then the contact may not >> be usable at all after the call and the other address fields (e.g. >> the >> AOR) will need to be used for callback which may or may not reach the >> caller directly. In most cases the phone will remain operational >> following the call completion and the contact information should >> allow the originating phone to be reached directly. >> >> Perry >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 8 16:15:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 480B63A6EE6; Thu, 8 May 2008 16:15:53 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 65534) id 9A40A28C3F5; Thu, 8 May 2008 16:15:51 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Old-Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEC7C3A6824 for ; Thu, 8 May 2008 15:52:32 -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 FVZ4eDITTBsT for ; Thu, 8 May 2008 15:52:31 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id ABB123A680E for ; Thu, 8 May 2008 15:52:31 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Thu, 8 May 2008 15:52:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 May 2008 15:52:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sourceId in LoST response mappings Thread-Index: AcixXjBpNzfhuYG3SiO7mPoyDWCzeA== From: "Jeff Martin" To: X-TMDA-Confirmed: Thu, 08 May 2008 16:15:51 -0700 Subject: [Ecrit] sourceId in LoST response mappings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The current draft-lost-09 doesn't have much to say about how LoST clients will use the 'sourceId' in the 'mapping' element of responses. Section 5.1 is clear that a specific LoST server must use unique 'sourceId's for all the possible mappings it can return. For example, if an authoritative LoST server currently holds 10 mappings, there must be 10 distinct 'sourceId' values -- one for each mapping. The only other thing draft-09 has to say about 'sourceId' is also in section 5.1: A receiver can replace a mapping with another one having the same 'source' and 'sourceId' and a more recent time in 'lastUpdated'. Since there is nothing else about 'sourceId', my interpretation is that clients only look at 'sourceId' as part of the client's caching strategy. This would mean a 'mapping' returned for the same input location would have the same 'sourceId' even if the mapping changed somehow. Changes would be reflected in 'mapping' responses in the 'lastUpdated' field and the actual values like uri, serviceBoundary, displayName, etc. In other words, from the perspective of LoST server code, if a user changes the uri for a specific mapping, the LoST server code would still return the existing sourceId when responding with that mapping (which now has a different uri and more recent 'lastUpdated'). I searched through the list archives to see if there was any other discussion on sourceId, and I found the following in a Feb 1, 2007 thread (more than a year ago) where Shida Schubert asked similar questions, and Hannes Tschofenig responded: > > If user A and B queries for "sos"/"regionA" would > > they get the same mapping data with same sourceId/version? > > Yes. They would receive they same mapping if it did not change in > between the two requests if their location falls within the same region. > > > If above are the same when does sourceId/version ever change? > > If the mapping Location+Service -> PSAP (+service boundary+location > profile) association changes. > > > Assuming server that caches the data can't change sourceId/version, > > they need to be the same for both A and B? > > > > I think the text needs to be elaborated to clarify what > > I have raised as a question. > > I will look at it in order to determine what has to be done. This thread implies that a sourceId *must* change if anything about the mapping changed. If the sourceId must change for every mapping change, then why does the draft-09 talk about clients looking for the same 'sourceId' with a different 'lastUpdated'? There would be no way for a server to ever return a different sourceId/lastUpdated combination if any change meant a new sourceId. So which way is it: - 'sourceId' *must* change for any change to the mapping as discussed on the mailing list. In which case the draft-09 describes a situation that is not possible. - 'sourceId' does not have to change. In which case the mailing list discussion reached incorrect conclusions. Thanks, -- Jeff CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 12 09:41:09 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76CEA3A68E8; Mon, 12 May 2008 09:41:09 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1522C3A68E8 for ; Mon, 12 May 2008 09:41: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 EyVYp-gaxuFy for ; Mon, 12 May 2008 09:41:07 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 24EE43A68DC for ; Mon, 12 May 2008 09:41:05 -0700 (PDT) Received: (qmail invoked by alias); 12 May 2008 16:40:48 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp053) with SMTP; 12 May 2008 18:40:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/tKocqL0LtjmgUUKkXOjPWj2458c1diW/ZdQMoKj TX8P5TeW4f2h2J Message-ID: <48287315.5080100@gmx.net> Date: Mon, 12 May 2008 19:40:53 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' Content-Type: multipart/mixed; boundary="------------010406000408050109050106" X-Y-GMX-Trusted: 0 Subject: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --------------010406000408050109050106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Comments from 3GPP2 regarding the ECRIT framework and Phone BCP documents. Would be interesting to hear your feedback. -------- Original Message -------- Subject: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC Date: Mon, 12 May 2008 03:30:19 -0400 From: Andrew Dryden To: Hannes Tschofenig CC: TSG-X Chairman's reflector , Victoria Bosserman , Dear Hannes: Please see attached correspondence from 3GPP2 TSG-X to IETF. Many thanks, Andy Dryden (for Betsy Covell, 3GPP2 TSG-X Chair) Andy Dryden 3GPP2 2500 Wilson Blvd., Suite 300 Arlington, VA 22201 Phone: +1 703-907-7702 Fax: +1 703-907-7728 http://www.3gpp2.org --------------010406000408050109050106 Content-Type: application/pdf; name="X02 TSG-X Corr to IETF re ecrit wglc.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="X02 TSG-X Corr to IETF re ecrit wglc.pdf" JVBERi0xLjQNJeLjz9MNCjgyIDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDM2MTM4L08gODQv RSAyNDYyMC9OIDIvVCAzNDQ1MS9IIFsgMTA1NiAyODBdPj4NZW5kb2JqDSAgICAgICAgICAg ICAgICAgDQp4cmVmDQo4MiAzOA0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAxNTA3IDAw MDAwIG4NCjAwMDAwMDE3NjUgMDAwMDAgbg0KMDAwMDAwMjEyOSAwMDAwMCBuDQowMDAwMDAy MTc1IDAwMDAwIG4NCjAwMDAwMDIzMzAgMDAwMDAgbg0KMDAwMDAwMjQ4NSAwMDAwMCBuDQow MDAwMDAyNjQwIDAwMDAwIG4NCjAwMDAwMDI3OTUgMDAwMDAgbg0KMDAwMDAwMzAxNSAwMDAw MCBuDQowMDAwMDAzMDYxIDAwMDAwIG4NCjAwMDAwMDMxMzggMDAwMDAgbg0KMDAwMDAwNTMz OCAwMDAwMCBuDQowMDAwMDA1NjY2IDAwMDAwIG4NCjAwMDAwMDU4MzEgMDAwMDAgbg0KMDAw MDAwNTk5MiAwMDAwMCBuDQowMDAwMDA2NDU4IDAwMDAwIG4NCjAwMDAwMDY0OTQgMDAwMDAg bg0KMDAwMDAwNjczNyAwMDAwMCBuDQowMDAwMDA2OTg3IDAwMDAwIG4NCjAwMDAwMDcxNDYg MDAwMDAgbg0KMDAwMDAwNzMwNyAwMDAwMCBuDQowMDAwMDEwMDAxIDAwMDAwIG4NCjAwMDAw MTAwOTAgMDAwMDAgbg0KMDAwMDAxMDE4MCAwMDAwMCBuDQowMDAwMDEwMjQ2IDAwMDAwIG4N CjAwMDAwMTAzMTAgMDAwMDAgbg0KMDAwMDAxMDQ0MyAwMDAwMCBuDQowMDAwMDE0MDQ0IDAw MDAwIG4NCjAwMDAwMTQyNjcgMDAwMDAgbg0KMDAwMDAxNDQ5NiAwMDAwMCBuDQowMDAwMDE4 NjI0IDAwMDAwIG4NCjAwMDAwMTg4ODQgMDAwMDAgbg0KMDAwMDAyMDEzMSAwMDAwMCBuDQow MDAwMDIwMzY1IDAwMDAwIG4NCjAwMDAwMjQzNTUgMDAwMDAgbg0KMDAwMDAwMTMzNiAwMDAw MCBuDQowMDAwMDAxMDU2IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMTIwL1ByZXYgMzQ0 NDAvWFJlZlN0bSAxMzM2L1Jvb3QgODMgMCBSL0luZm8gMTQgMCBSL0lEWzxENEY5NzgwQjYx N0JCOUU0NjRERTg1NTFBRjQyQjUzRT48RDhGMEY4NzAyMzk4OTY0QUFDRjAzRDRGQjA5QjFC RDU+XT4+DQpzdGFydHhyZWYNCjANCiUlRU9GDQoKMTE5IDAgb2JqDTw8L0xlbmd0aCAxODYv QyAxODkvRmlsdGVyL0ZsYXRlRGVjb2RlL0kgMjE5L0wgMTczL1MgODg+PnN0cmVhbQ0KeNpi YGBgBaKzIJJzLwM/AwLwA8XYGFgYOF4wzBdhYFjVwIAGPnv0qXBbWoKYjIKCgkodHUAlLhEN INVAwMbAkHERSCsBsSpYRIWBR6SBi72gHIi4G7iYZpQIOTSyX1zHwHCeN6Ga/VYSc4AZ4wMZ Ntm33BsO/j/wwHvDse8KT9kD2BknwOzkYmAoEAfSTEBsC8ScDAyZl0AOANrnCpZn63IMEQy4 xlkA5PExMDTPg8gyXgIIMACxDSiBDQplbmRzdHJlYW0NZW5kb2JqDTExOCAwIG9iag08PC9M ZW5ndGggMjIvRmlsdGVyL0ZsYXRlRGVjb2RlL1dbMSAxIDFdL0luZGV4WzE1IDY3XS9EZWNv ZGVQYXJtczw8L0NvbHVtbnMgMy9QcmVkaWN0b3IgMTI+Pi9TaXplIDgyL1R5cGUvWFJlZj4+ c3RyZWFtDQp42mJi4mRgYmBgHMUMjAABBgB1cgDUDQplbmRzdHJlYW0NZW5kb2JqDTgzIDAg b2JqDTw8L01hcmtJbmZvPDwvTGV0dGVyc3BhY2VGbGFncyAwL01hcmtlZCB0cnVlPj4vTWV0 YWRhdGEgMTMgMCBSL1BpZWNlSW5mbzw8L01hcmtlZFBERjw8L0xhc3RNb2RpZmllZChEOjIw MDgwNTEyMDMwMjM2KT4+Pj4vUGFnZXMgMTIgMCBSL1BhZ2VMYXlvdXQvT25lQ29sdW1uL1N0 cnVjdFRyZWVSb290IDE1IDAgUi9UeXBlL0NhdGFsb2cvTGFzdE1vZGlmaWVkKEQ6MjAwODA1 MTIwMzAyMzYpL1BhZ2VMYWJlbHMgMTAgMCBSPj4NZW5kb2JqDTg0IDAgb2JqDTw8L0Nyb3BC b3hbMCAwIDYxMiA3OTJdL0Fubm90cyA4NSAwIFIvUGFyZW50IDEyIDAgUi9TdHJ1Y3RQYXJl bnRzIDAvQ29udGVudHMgOTMgMCBSL1JvdGF0ZSAwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9S ZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW0wIDEwOSAwIFI+Pi9Db2xvclNwYWNlPDwvQ1MwIDkx IDAgUi9DUzEgOTggMCBSPj4vRm9udDw8L1RUMCA5MCAwIFIvVFQxIDk0IDAgUi9UVDIgOTUg MCBSL1RUMyA5NiAwIFIvVFQ0IDk3IDAgUi9UVDUgMTAxIDAgUi9UVDYgMTAyIDAgUj4+L1By b2NTZXRbL1BERi9UZXh0L0ltYWdlQy9JbWFnZUldL0V4dEdTdGF0ZTw8L0dTMCA5MiAwIFI+ Pj4+L1R5cGUvUGFnZT4+DWVuZG9iag04NSAwIG9iag1bODYgMCBSIDg3IDAgUiA4OCAwIFIg ODkgMCBSXQ1lbmRvYmoNODYgMCBvYmoNPDwvUmVjdFszOTYuMCA2MTYuMTc2IDUwOS4xNjcg NjMxLjk0NF0vU3VidHlwZS9MaW5rL0JTPDwvUy9TL1cgMC9UeXBlL0JvcmRlcj4+L0EgMTA3 IDAgUi9GIDQvSC9JL1N0cnVjdFBhcmVudCAxL0JvcmRlclswIDAgMF0vVHlwZS9Bbm5vdD4+ DWVuZG9iag04NyAwIG9iag08PC9SZWN0WzEwOC4wIDU0My42MzYgMjUwLjk2NSA1NTkuNDA0 XS9TdWJ0eXBlL0xpbmsvQlM8PC9TL1MvVyAwL1R5cGUvQm9yZGVyPj4vQSAxMDYgMCBSL0Yg NC9IL0kvU3RydWN0UGFyZW50IDIvQm9yZGVyWzAgMCAwXS9UeXBlL0Fubm90Pj4NZW5kb2Jq DTg4IDAgb2JqDTw8L1JlY3RbMTA4LjAgNDIyLjc0OSAzNDguMjg1IDQzNy4xNzddL1N1YnR5 cGUvTGluay9CUzw8L1MvUy9XIDAvVHlwZS9Cb3JkZXI+Pi9BIDEwNSAwIFIvRiA0L0gvSS9T dHJ1Y3RQYXJlbnQgMy9Cb3JkZXJbMCAwIDBdL1R5cGUvQW5ub3Q+Pg1lbmRvYmoNODkgMCBv YmoNPDwvUmVjdFsxMDguMCA0MTAuNTA5IDM0My4wMDUgNDI0LjkzN10vU3VidHlwZS9MaW5r L0JTPDwvUy9TL1cgMC9UeXBlL0JvcmRlcj4+L0EgMTA0IDAgUi9GIDQvSC9JL1N0cnVjdFBh cmVudCA0L0JvcmRlclswIDAgMF0vVHlwZS9Bbm5vdD4+DWVuZG9iag05MCAwIG9iag08PC9T dWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDExMCAwIFIvTGFzdENoYXIgNTcvV2lk dGhzWzI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgNTU2IDU1NiA1NTYg NTU2IDU1NiA1NTYgNTU2IDU1NiA1NTZdL0Jhc2VGb250L0FyaWFsTVQvRmlyc3RDaGFyIDMy L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNOTEgMCBvYmoN Wy9JbmRleGVkIDk4IDAgUiAyNTUgMTA4IDAgUl0NZW5kb2JqDTkyIDAgb2JqDTw8L09QTSAx L09QIGZhbHNlL29wIGZhbHNlL1R5cGUvRXh0R1N0YXRlL1NBIGZhbHNlL1NNIDAuMDI+Pg1l bmRvYmoNOTMgMCBvYmoNPDwvTGVuZ3RoIDIxMjkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJl YW0NCkiJlFdtb9s4Ev5u4P4DPzoHSxYp6sXFYrGpk+1m0RdfImAPaA8HWaJtXRVRK0rx9t/f 8EWk7NgttgVMxqLmmXnmmRl6+XTIW4Z++mn5Yf1whwhGP//89m6NZn/Olu+eArQXM7wifrqC f+EKBfA/Dvwggj+TGIXwKDSPkiD0sfqDouJ5tnx4DtAdn/1rdv8BzL3NZsvbrq92edEDmgEZ IZZZFiCMst0s1hCIUj+mKKGJj9MAnjzP5ugm+98s8hNCCMoKOOVhPw1RdgeP1LNAfh2PX5fm jeyfZgNuB2Eqz3iBH03PYXuQ2F1od9TuIruL7S6xu9TuVmr3CiWwB7BDxA4SO0zsQLFDxQ4W O1zsgPHKReLQyCQ+h0YcGnFoxKERh0YcGnFoxKGFDi10aOGETocWOrTQoYUOLXRooUMLHRp1 aNShUYdGJ9lzaNShUYdGHRp1aNShRQ4tcmiRQ4scWjQRi0OLHFrk0CIHEQdOwNgHSVzTsN2o olpubOEGY91CKWFdSp4UfBCrWoEd6Cg7Ihz4q1TVmN7hIEUxVDEUrayx8N1mQ9D60+Pj/dPm 08e7+4/rewkHVom2Gujak6aItkMQiSIfIp/YuegjnvgYamsY+0kQyXCjVeTiPX+TTN6kxg8b nI3zqHsCOCR7wgfho7esF9/Qmr+wuh5rEs7SkRO5s29F6rX1Ia+6BdJEZE/vvH/b5gFVO8Yu 83BbF3nPau/9ULCmn/j91OaNdT20rq+fMCqE5gwhUTQ6hkgalfZ6sf/rv4WE/yXcty3xebe/ yAYdTULv1DaI44GYiIgPGlc85N8gRwtEgiC9aC4azXnQB8x7kIjf8qZhAmWiOPAda6r9tQjj H0XoaJsy/dkg+A7hl/3zTTr/y29Yf/Of7PdXniYucFkoiZ8gY+5UOJNBs8y+wXhbbrqq6atm P2UOtBQZFfqB0bLckEhVRgSzBxrYqZrvs0tRyiKKaOSDNClR9eXHqGOznRp7zv/0DD428LaQ lKEw9L9TRKtrhR7aQleixqEt9HAsdJqu/CRVth/ZG3S/fnzI0B/v3q9PAsRB7EdwlvrQfSm0 6MCHxqjCGR9FPjTx00enkeLgSsUqLVxqQjQmQJp07Y7lHdLaWFzuI7aRqHBt4NK40T4Bi0pj 2SFvvqJvN14y5wPa8Q5tQQp7KQU+dCjve6jdijeo56g/MMFQ2eW7XrxBEwWeyB2TH+k9PdM7 Nno/9H37ZrnsOa+FX7F+Jyt8eeil6OulwvXk1x4ruqr3dl0un7AbMj/y7qsXRM4llSYgjagk kTCR/TeQHzYZp06HZ9Kjk25+no6QqnZOSax66akST83SH3Ch0u0R7McgmJGL8u9z0R54w7ZF 6wX0NQmY+OAICSHt8XdJiP4WCYE0R6F60vQ7My123RPCg6uAi/LKG8mJei+NolEwegjJ5AtU cN6yLu8rmGVKzuhY9Qf0cJ/9ivKmRDXncAoEflQEXaoMcHCFZYzSt7wrpeYLLvviIOuhP+Q9 MFfnsh7EoWp9ZMbgOACDxBpMpEHPWJyEfMgF2jLWgCd1zY/SrnJRpRFBT65eqr6CuSJ9zkve 9rBt2463XQXTFMGu5wWvv/xDH2k7+U4BLxwPrGEvrHPeRNablZnJn+ctF6La1gx9mYuhOCBw B8oaMVVJ3Z41BZCXzpFg3QuYRUPXGPosbedRksAPg1jT9nleKHokby9M5SGH+mzA0uOva/Hl Bjj7jR+lnwvUcIhYXjykZc+YmRaB8kwRw3aQOaCiALluGdoNtUmyooiVPro4EHF6MhHt1eSy 8FZT4UnOTJSRZe8PBuh1Be5rNUjWVHzaGb5DqK4E+AM6+XOoOk2rE5xTc6hmUOynZCSu6aGd tzmM5mKo887EVzVFPZRafsyJ5g3SAbuwPG3svLouwUoG7u+8aIHgM1Gf8gIkF/0djvWin1kz Z+WCYVhiUy04VUcJ1Ys2Q7SZUJuhzpqnX534SvX7dKWWKNAL1ov2LQoX6GnjvIncnU65M6fq eaw+caCXRC+pWkKiFzj48DGzls4zPe0xc6zPmldivSR6SfWyOjX3KsmpH8CvO8MT0Ycl0Wo1 NrAxIgm8/eiF6jNZoGs+esbqhEJ4IVWvydjlgvVC9KKfkckPqVcTeH61kUnF5B3TFTvpRtAg c9MDj6D2mgmBWPNSdbx5trbUuCfBqHO4TyxM29ESL7my2+dfme5Fos+3UEYHKCO46cr2blvE SXvIu+JQ9azoB3BNNqkKOoSrIGgWbb6tatdP60rWY9XrDg61Jf0vCj40PfSlB+h0ZVnJZwsk KtmzXOUSSwix3QCqe+WaJkRSyG4GF6qylgVbCRXXvubbfGxXw7aCvtDzQV7drrUF6IQpNX1h XnOwCu1kP+jBA5SwUkjmoQ+KoW2hLwJRcthVjUugNYlDPYm0zSl9Om9C9XvoWc83yVzIxBzl j8FcqGgUUM32uRkLRdUV4P/E99P5DIVNw8S4vs0FeLZ5ut0IOyqBlLwWXGZbcTRJwfUxaqye jwbJhPSv40N/PsJMNoQiBp6jkl31OfFXNBrl2bKmtCaA7vf8KVPTkHXCqALihzCG5mvDj42a u+jqcPSM9anvrzw1w1aMcpdeQw4gwSVra64OSbYcytloB4JCbCcJKEE48avE+SiTd5mug2oZ 7/HVbsc68IFNtXiJe2n6pO6U/02pF6i5Ix/qUrrbMLAm8k6HpfMvfzscOABKASyMDGQ1fvpw i0TLimpXFaYi1VBVvqgCK9muaqzK5Xh92Birl7PtwlBNB7gn1N5M1K8bDQ+3E/hDNQOg1bau kX4fXb5OkOD1dcIzIBevtXAD/78AAwBLAoUhDQplbmRzdHJlYW0NZW5kb2JqDTk0IDAgb2Jq DTw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTExIDAgUi9MYXN0Q2hhciAx MDEvV2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDU1 NiAwIDAgMCAwIDAgMCAzMzMgMCAwIDAgMCAwIDAgMCAwIDcyMiA3MjIgNjY3IDAgNzc4IDAg Mjc4IDAgMCA2MTEgMCA3MjIgNzc4IDY2NyAwIDcyMiA2NjcgNjExIDAgMCA5NDQgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCA1NTZdL0Jhc2VGb250L0FyaWFsLUJvbGRNVC9GaXJzdENo YXIgMzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag05NSAw IG9iag08PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDEwMCAwIFIvTGFzdENo YXIgMzIvV2lkdGhzWzI1MF0vQmFzZUZvbnQvVGltZXNOZXdSb21hblBTLUJvbGRNVC9GaXJz dENoYXIgMzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag05 NiAwIG9iag08PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDExMyAwIFIvTGFz dENoYXIgMzIvV2lkdGhzWzI1MF0vQmFzZUZvbnQvT0NOSk9FK1RpbWVzLVJvbWFuL0ZpcnN0 Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTk3 IDAgb2JqDTw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgOTkgMCBSL0xhc3RD aGFyIDEyMS9XaWR0aHNbMjUwIDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjUwIDMzMyAy NTAgMjc4IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMCAw IDAgMCAwIDkyMSA3MjIgNjY3IDY2NyA3MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAwIDAgNjEx IDg4OSA3MjIgNzIyIDU1NiAwIDY2NyA1NTYgNjExIDAgNzIyIDk0NCA3MjIgNzIyIDAgMCAw IDAgMCA1MDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAwIDUwMCAy NzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAw XS9CYXNlRm9udC9UaW1lc05ld1JvbWFuUFNNVC9GaXJzdENoYXIgMzIvRW5jb2RpbmcvV2lu QW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag05OCAwIG9iag1bL0lDQ0Jhc2VkIDEw MyAwIFJdDWVuZG9iag05OSAwIG9iag08PC9TdGVtViA4Mi9Gb250TmFtZS9UaW1lc05ld1Jv bWFuUFNNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzQvRGVz Y2VudCAtMjE2L0ZvbnRCQm94Wy01NjggLTMwNyAyMDAwIDEwMDddL0FzY2VudCA4OTEvRm9u dEZhbWlseShUaW1lcyBOZXcgUm9tYW4pL0NhcEhlaWdodCA2NTYvWEhlaWdodCAtNTQ2L1R5 cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0xMDAgMCBvYmoNPDwv U3RlbVYgMTM2L0ZvbnROYW1lL1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvRm9udFN0cmV0Y2gv Tm9ybWFsL0ZvbnRXZWlnaHQgNzAwL0ZsYWdzIDM0L0Rlc2NlbnQgLTIxNi9Gb250QkJveFst NTU4IC0zMDcgMjAwMCAxMDI2XS9Bc2NlbnQgODkxL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJv bWFuKS9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgLTU0Ni9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0 YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMTAxIDAgb2JqDTw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9u dERlc2NyaXB0b3IgMTE1IDAgUi9MYXN0Q2hhciAzMi9XaWR0aHNbNDU3XS9CYXNlRm9udC9P Q05KUEkrWldBZG9iZUYvRmlyc3RDaGFyIDMyL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9U eXBlL0ZvbnQ+Pg1lbmRvYmoNMTAyIDAgb2JqDTw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERl c2NyaXB0b3IgMTE3IDAgUi9MYXN0Q2hhciAzMi9XaWR0aHNbMjUwXS9CYXNlRm9udC9PQ05K UEsrVGltZXMtQm9sZC9GaXJzdENoYXIgMzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5 cGUvRm9udD4+DWVuZG9iag0xMDMgMCBvYmoNPDwvTGVuZ3RoIDI1OTgvRmlsdGVyL0ZsYXRl RGVjb2RlL04gMy9BbHRlcm5hdGUvRGV2aWNlUkdCPj5zdHJlYW0NCmjenJZ3VFTXFofPvXd6 oc0w0hl6ky4wgPQuIB0EURhmBhjKAMMMTWyIqEBEEREBRZCggAGjoUisiGIhKKhgD0gQUGIw iqioZEbWSnx5ee/l5ffHvd/aZ+9z99l7n7UuACRPHy4vBZYCIJkn4Ad6ONNXhUfQsf0ABniA AaYAMFnpqb5B7sFAJC83F3q6yAn8i94MAUj8vmXo6U+ng/9P0qxUvgAAyF/E5mxOOkvE+SJO yhSkiu0zIqbGJIoZRomZL0pQxHJijlvkpZ99FtlRzOxkHlvE4pxT2clsMfeIeHuGkCNixEfE BRlcTqaIb4tYM0mYzBXxW3FsMoeZDgCKJLYLOKx4EZuImMQPDnQR8XIAcKS4LzjmCxZwsgTi Q7mkpGbzuXHxArouS49uam3NoHtyMpM4AoGhP5OVyOSz6S4pyalMXjYAi2f+LBlxbemiIlua WltaGpoZmX5RqP+6+Dcl7u0ivQr43DOI1veH7a/8UuoAYMyKarPrD1vMfgA6tgIgd/8Pm+Yh ACRFfWu/8cV5aOJ5iRcIUm2MjTMzM424HJaRuKC/6386/A198T0j8Xa/l4fuyollCpMEdHHd WClJKUI+PT2VyeLQDf88xP848K/zWBrIieXwOTxRRKhoyri8OFG7eWyugJvCo3N5/6mJ/zDs T1qca5Eo9Z8ANcoISN2gAuTnPoCiEAESeVDc9d/75oMPBeKbF6Y6sTj3nwX9+65wifiRzo37 HOcSGExnCfkZi2viawnQgAAkARXIAxWgAXSBITADVsAWOAI3sAL4gWAQDtYCFogHyYAPMkEu 2AwKQBHYBfaCSlAD6kEjaAEnQAc4DS6Ay+A6uAnugAdgBIyD52AGvAHzEARhITJEgeQhVUgL MoDMIAZkD7lBPlAgFA5FQ3EQDxJCudAWqAgqhSqhWqgR+hY6BV2ArkID0D1oFJqCfoXewwhM gqmwMqwNG8MM2An2hoPhNXAcnAbnwPnwTrgCroOPwe3wBfg6fAcegZ/DswhAiAgNUUMMEQbi gvghEUgswkc2IIVIOVKHtCBdSC9yCxlBppF3KAyKgqKjDFG2KE9UCIqFSkNtQBWjKlFHUe2o HtQt1ChqBvUJTUYroQ3QNmgv9Cp0HDoTXYAuRzeg29CX0HfQ4+g3GAyGhtHBWGE8MeGYBMw6 TDHmAKYVcx4zgBnDzGKxWHmsAdYO64dlYgXYAux+7DHsOewgdhz7FkfEqeLMcO64CBwPl4cr xzXhzuIGcRO4ebwUXgtvg/fDs/HZ+BJ8Pb4LfwM/jp8nSBN0CHaEYEICYTOhgtBCuER4SHhF JBLVidbEACKXuIlYQTxOvEIcJb4jyZD0SS6kSJKQtJN0hHSedI/0ikwma5MdyRFkAXknuZF8 kfyY/FaCImEk4SXBltgoUSXRLjEo8UISL6kl6SS5VjJHslzypOQNyWkpvJS2lIsUU2qDVJXU KalhqVlpirSptJ90snSxdJP0VelJGayMtoybDFsmX+awzEWZMQpC0aC4UFiULZR6yiXKOBVD 1aF6UROoRdRvqP3UGVkZ2WWyobJZslWyZ2RHaAhNm+ZFS6KV0E7QhmjvlygvcVrCWbJjScuS wSVzcopyjnIcuUK5Vrk7cu/l6fJu8onyu+U75B8poBT0FQIUMhUOKlxSmFakKtoqshQLFU8o 3leClfSVApXWKR1W6lOaVVZR9lBOVd6vfFF5WoWm4qiSoFKmclZlSpWiaq/KVS1TPaf6jC5L d6In0SvoPfQZNSU1TzWhWq1av9q8uo56iHqeeqv6Iw2CBkMjVqNMo1tjRlNV01czV7NZ874W XouhFa+1T6tXa05bRztMe5t2h/akjpyOl06OTrPOQ12yroNumm6d7m09jB5DL1HvgN5NfVjf Qj9ev0r/hgFsYGnANThgMLAUvdR6KW9p3dJhQ5Khk2GGYbPhqBHNyMcoz6jD6IWxpnGE8W7j XuNPJhYmSSb1Jg9MZUxXmOaZdpn+aqZvxjKrMrttTjZ3N99o3mn+cpnBMs6yg8vuWlAsfC22 WXRbfLS0suRbtlhOWWlaRVtVWw0zqAx/RjHjijXa2tl6o/Vp63c2ljYCmxM2v9ga2ibaNtlO LtdZzllev3zMTt2OaVdrN2JPt4+2P2Q/4qDmwHSoc3jiqOHIdmxwnHDSc0pwOub0wtnEme/c 5jznYuOy3uW8K+Lq4Vro2u8m4xbiVun22F3dPc692X3Gw8Jjncd5T7Snt+duz2EvZS+WV6PX zAqrFetX9HiTvIO8K72f+Oj78H26fGHfFb57fB+u1FrJW9nhB/y8/Pb4PfLX8U/z/z4AE+Af UBXwNNA0MDewN4gSFBXUFPQm2Dm4JPhBiG6IMKQ7VDI0MrQxdC7MNaw0bGSV8ar1q66HK4Rz wzsjsBGhEQ0Rs6vdVu9dPR5pEVkQObRGZ03WmqtrFdYmrT0TJRnFjDoZjY4Oi26K/sD0Y9Yx Z2O8YqpjZlgurH2s52xHdhl7imPHKeVMxNrFlsZOxtnF7YmbineIL4+f5rpwK7kvEzwTahLm Ev0SjyQuJIUltSbjkqOTT/FkeIm8nhSVlKyUgVSD1ILUkTSbtL1pM3xvfkM6lL4mvVNAFf1M 9Ql1hVuFoxn2GVUZbzNDM09mSWfxsvqy9bN3ZE/kuOd8vQ61jrWuO1ctd3Pu6Hqn9bUboA0x G7o3amzM3zi+yWPT0c2EzYmbf8gzySvNe70lbEtXvnL+pvyxrR5bmwskCvgFw9tst9VsR23n bu/fYb5j/45PhezCa0UmReVFH4pZxde+Mv2q4quFnbE7+0ssSw7uwuzi7Rra7bD7aKl0aU7p 2B7fPe1l9LLCstd7o/ZeLV9WXrOPsE+4b6TCp6Jzv+b+Xfs/VMZX3qlyrmqtVqreUT13gH1g 8KDjwZYa5ZqimveHuIfu1nrUttdp15UfxhzOOPy0PrS+92vG140NCg1FDR+P8I6MHA082tNo 1djYpNRU0gw3C5unjkUeu/mN6zedLYYtta201qLj4Ljw+LNvo78dOuF9ovsk42TLd1rfVbdR 2grbofbs9pmO+I6RzvDOgVMrTnV32Xa1fW/0/ZHTaqerzsieKTlLOJt/duFczrnZ86nnpy/E XRjrjup+cHHVxds9AT39l7wvXbnsfvlir1PvuSt2V05ftbl66hrjWsd1y+vtfRZ9bT9Y/NDW b9nffsPqRudN65tdA8sHzg46DF645Xrr8m2v29fvrLwzMBQydHc4cnjkLvvu5L2key/vZ9yf f7DpIfph4SOpR+WPlR7X/aj3Y+uI5ciZUdfRvidBTx6Mscae/5T+04fx/Kfkp+UTqhONk2aT p6fcp24+W/1s/Hnq8/npgp+lf65+ofviu18cf+mbWTUz/pL/cuHX4lfyr468Xva6e9Z/9vGb 5Dfzc4Vv5d8efcd41/s+7P3EfOYH7IeKj3ofuz55f3q4kLyw8JsAAwD3hPP7Cg0KZW5kc3Ry ZWFtDWVuZG9iag0xMDQgMCBvYmoNPDwvVVJJKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtZWNyaXQtcGhvbmViY3AtMDQpL1MvVVJJPj4NZW5kb2JqDTEwNSAwIG9i ag08PC9VUkkoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1lY3JpdC1m cmFtZXdvcmstMDUpL1MvVVJJPj4NZW5kb2JqDTEwNiAwIG9iag08PC9VUkkobWFpbHRvOkhh bm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQpL1MvVVJJPj4NZW5kb2JqDTEwNyAwIG9iag08PC9V UkkobWFpbHRvOiUyMHRzZ3hfY2hhaXJAM2dwcDIub3JnKS9TL1VSST4+DWVuZG9iag0xMDgg MCBvYmoNPDwvTGVuZ3RoIDYzL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpo3uyKgQkA MAzC/Mmf/Mmf+lMX9sVgQbBVJS3MpV2UDLJHKq+UxHaxVlzkM8tg12QMaO3o83mMI8AA+9Mj 3QoNCmVuZHN0cmVhbQ1lbmRvYmoNMTA5IDAgb2JqDTw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3Ro IDM0NDQvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNl IDkxIDAgUi9XaWR0aCAzMzQvSGVpZ2h0IDEwNC9UeXBlL1hPYmplY3Q+PnN0cmVhbQ0KaN7s W4liqyoQNeJCEPDmpjXx/3/0sTMMuKRt2t5nJl2M4HY8szADp9NLXvKSl5SlPtU1UX9eSHxO mrbr6ZmejagN2jXtg6dg7AWjImTdOxSx0O4RRF9oKiyXoLR40n43oC802/68KXQnnkdHs82h G9B/K80ev3RsNDMVHwpbXtptPBk/MC/pInZDaZP2W2fkh+VmvcNeYpjpHm4yUXkRD98ViQer w8m/AmZDzx+QDXckR/UHwFE9zFUI5kfexs9Iv0TDYYOl/Zr1HKVB04HAPJoiCLf8899YRj79 BggjRP2qwyt0uDBHc3+UEKzUHoRFxgsetpJ24nrB/eb0zB+hm9Z1pKYAomEBuQVcab3BTSYc mqSquIfIC7f7g5AcTRKewoUIoLs7mvjOrNyOVUOEbYI0h9iGZHflqOBAJPldpkIztIZdtnPY gJPJxAb6R9A3ZkQY2mqUzVeew1kA+ORfyini4c8ri+327OHyepdwPDcNzHcxTTI5SN+UvgMe 3vUGmi19wPGUYF40nsGnW8XxbzfovkWTJY9ZRJNHzQWHA3YJ2zAW2xl6CxoqCHnsojfHdA+z d8ACudkqmvWH/A8EdtEXhXjTPXJ4GmUi9afy3JRRBYtoCqBzp9Ql6YdzvAncRO1CjurDPUJS n4cDTMANsMhNz4jATWLDilVutoWAcsEBLat/u8VNp1ACGz4W+bCGJmOS8TKa5uGsjUjtpjhl ltFq6h+NFFQDcAMk8M/furSHmVcgjI1aQXMvM4fV4eYCOy03CUFYGbZc1OuXDClatYCmlr8R TaTJxCoid4TK2oV5Ez5i0N2UXohEvcEmT/eMgZtOR/gKmvRcYOWmP8+60UWfThJXGuGIvjgq Gk8dCPLpa2g6CrIlu5m45MRZR/UGwAJNl8FunoL5JPvjzD1hUQ7qtV6INzU3XDiZwkE8O5hh D+NcZNTUaIa4r4LUth8CXKxul4lZNmyMbLP99FXVoepyATGg6dFuCncKAbnpXsYCmv2wMypa 62R39QvcrP+g8DKQh+TxZjbY4Ungl4WrBLhYHcuMxXb/zpLu5m1i5QA+PY83o4aRFQ+0Zhd3 5OZWPJGJN4mignIiTL1n5s1p3NARs2OB/FvgNzEt6mjFJxKO4pZexhIahtoGe4HQalvk2Ngz mf4sZmKIui/fEsyJ35TxLG/23CE+YZI84oF2kTQ/hiz79CNIv5pwW9q/OGaiy/HmAaTdHxsN W7iXdf1A3NyMNIddQMOosz4uN/uHjeRmV+zX5XhAag5QoTPHPTyANCLnKA9GzQ9rebFrd1Ru 0g8HQ3AQio5HltPEm/9mZecxab/CZubBUkpO49PFv1jZ+RA196I47B27p+Q0Pl2YPDZzuXXf Aqo0aZmIi7Suw0NHVxJhaaEn9rejGMLT79wXUvwWycpHn4482rWocljAco/UJW7G1LpDk8AE RzoQF2iELAKhR5jGCSkjgYjP0XcBB9juLlh+2a/0QcMu/zPsaOlL3HSuPVQd1SNHkFCZyG1V rlBj0LLmVtqjUX7RdyUOLOHPxv33HE2ZX/ZT8gUB5lAmd419uohJtYCmogcDpcakTJRC4LhH Em4iNMO7st99no2cltAcFy77QWlSIMykVzqYn7OfAIvdddILdlweXo7Yp7snNfcPoE3KRBma nNkDIzdhylYbEnN44KZ9edzZTWw5gKZnl/2gdBGva1s7IX6jbq8Ioi50Sjqa2YnD8njIc/Nd Mp2U87WEkA7P6uOshKYwBlf4hC3L0EzsJMntZoamXLjspz16t8euLlfM24zIMAlv4s337G4r m/7+4xAxJKlCmSjn5ikUZJz5hJquS5FSE5L5d0U27eYYLmtTmJ8Ds94EipynaSXVBmCfztNi mtPc5y1mtqMzguxBZaICN21i3XFrLNjNN+GNiI7FAszgX9ELfU2w2eL4sD7Vb/bX3+h9mjye w9rUrSb2c2dsc5+eDDBdzUWxwtUEUJmoyE33Dhw3ua/7hK61h5PYiiSX422Zm+xL0WwCkQya Nb0ruamP/rF5//s8B5jsnl72MhHzImrTbyobTv+4CTfj47n4E5WJityMvTU3IbU9RsIFUtWO eJN/KZp9qsT1NM+X+DFdbrMSp8UGNqI6mfbwx4BcX3S/CRjPK+Imi1UXZ0z/BpoavwTrRX4r zvEGm9bANbFiYyYS+MlO7mjCQrsr6Mj0TL7046tCn5ZrdBt919REgaNkvlg4LZrqi0PJ6i6Z Ll5m+yuJerCb3k7ISZFP/78LSm3ez7PFx5DPcVNcDJzRU5Gbg3K+eH6af5cIe+bYDpHfrFE0 GXTYyBSxmwCa9ezATMW+hgU0j8FNBOak4bzdJZW0p9LodQ85ZzXd0dA4HS+Wn57D2WiIHYGb OOQ2sDQQ7sZZUmg33Z6J6MHQm/nV46IZOH97xojmIWqWDR5ba5oBNBs5WRV23IyarvbcUbw/ 4QgJcvMINcu8kK5CoSREb+4X4IUSbqIpHcSqfHmkfghu1oXUz9Q1rfpoMV3yCGm2fgkXza2i T8VS2+G4OeT+yLgOAgKfOqCp2UqVqzKDp8bunlGABDTd55B+pMoGVn099aW2FJYdEzS1j75H lM5Y061STzqoCmOhC/RD6pzRAuf5zW+sslUrC2e+UkiaKu76aD01hrfaq7oFyWq68kJVsKSm H7NoWk8PqF5n3EyrbLguxjha6eTu0lXDUCtZrcklaLod8rloArvZNfC7izzNs9xiHJlqukFd 97MchO4KR+++np5W2VB+N515Gp/b53pE0kjWa3IlNPmT0aRxIpb+3lhiulBpkjVyQzXWdNPP oknW0EQ5JBbQhHWxfKVTQFM6NKFegcVUhZpcooI2ycHz+d9fjib0vzVVbsU4F/3be8UOcNod 8qY+977vO/fr7CYwAHhtm89vplU2VBfLVzoF3MYimn4xlSjk73Jf9HxjvVnIcAN1h9Jqtjjj Jsgh5XM9HLywLpavdAo4SKjpkZv4HpbRNHX7Z8cR3XaRoolmsrhAIDiaCzAA+JSem2mVLbeb aKUT4SW7ibm5A0327OjoFAxlXrCFcoNmcvlMNteUcBPQ3fj0rMom0roYWK1jSz48rADijrCp prvekrytoxnS8ey57ISrAds6L7SR5j5De3huysW4prnNGZrg/Zh4M6uycVQXi3UjCRehsMjN FE3Xu1h9Bx3N+jWnDM+1nEnMfr/f5puYxXwLn9llhqMGT7fbLC6wT9qvOK/Lx5tjQTFhXcyv phKem7qMxiOarqbGCViEOm6gye06Wev8nosmRePJUKKYbZ3Cp9kjSioiulxwLaPQb6C4no6r bLgulsSbf2q4A5tZeSpOKngvoZk4v+dmX7p8POngmS8B0fkCKOc6JWhfcCFjQFECt2WwtMoW FzL5qhpe6UT0l7DaioW1VHZH+AoKcYWsdDiMsSfbzROhMOnhkuihMDT7qgbMZthOoR40z/F/ kpGDFvYoazJokj+yRQkDKfiDEm2+z+Q7uP9pejNJ2B1lvVCX5+JyyVPK02a/ZDhwFG4WEsZT +DutzNWcDKqh8wSPzeY1HWZNRlee4jqdPyVDOrY6zHqh+vwUSYdWh+Fm3T/EuZ2drulFDlFP N9J+MSuHOJsuyIHWANNHeLdPcEbqQGuAm/LawGGHnqMFMcNSQupA3DzRIVlwNey1mUNp/1BK lrr8Jjk9t5aA5fuveCq7dYiUW8g27XZIWdrO5ZAOgeajjmgoEhJMrM0u4Orpx0Bz99LVXc7q mp//UNyExcsicsMDHp8W0vPsUNws6fqwk5h4mWWpwORqluHZeGkODU+n1vgwoCrsTXu68Gu8 5AsPfwZNC+fwKA8LqBbrmsinsypfcommesSZBKW9osrnhaTHsx9Fcyn78cBoMk/EpdzUczCY XxLtZiQxAWcJhboP4xVYGWwWaemPAEUNt9JUV40sdLqsZM8Z1m/pK5KfCXX7x6HMG7tyTRON hRQsYFaHQ3OEE1tYnJQIqjkEonmK3A1FumAvq58efOWeCI10YPC5gPN1YbVmlkMKc4V4wk3Q 4YTRchaCYLgCN0N9lz29nLZH6F69HmAwP0RLS5fWCBfzm0Yt48S5cWHSVZVMT8q4SapYCiUO 1epnjCW2nfRBa7kZaC5xM7oXAWbLpC6KFL0QKXghSET2zXNtV6TdxHJYNpvd8nmL+U2Emucm X0VTnApoAr6Lb54GvgPOYbcnAk1rE+iWc0hxObrnpi6ij2WfLkeXN32P00JGCc4tDVN/C5iZ Lxr2qj5dAzPLb4IZqwE2BknWJGhm7+JWVGYSyEt+TQawo5sxUe7cu3r1nDybHMczNJOpvyRB szRRM0PTzN5yVlg+f7Lmbm2nqygWibkOJuamKATkdvKvALOPV7gpygirvfa0778HzUDPYVPD h7WQHQjy6bzgptdGlnIPN0u+/5dYz24rRzdsDX8SwfFmcSFWOnoPuys8UXEPmuJ3lU7q5rrH kdM9WB6onr6MZ0u3CHpt6n3nOk49fR3Q62K+eCctraE8UM1yFVBlQilWc0q7tn7kLAeqp+9A tG17BWpHr53CsbTc4MXNb5QXN79SXj79JS95yT8t/wkwAPzlxSMKDQplbmRzdHJlYW0NZW5k b2JqDTExMCAwIG9iag08PC9TdGVtViA4OC9Gb250TmFtZS9BcmlhbE1UL0ZvbnRTdHJldGNo L05vcm1hbC9Gb250V2VpZ2h0IDQwMC9GbGFncyAzMi9EZXNjZW50IC0yMTEvRm9udEJCb3hb LTY2NSAtMzI1IDIwMDAgMTAwNl0vQXNjZW50IDkwNS9Gb250RmFtaWx5KEFyaWFsKS9DYXBI ZWlnaHQgNzE4L1hIZWlnaHQgNTE1L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUg MD4+DWVuZG9iag0xMTEgMCBvYmoNPDwvU3RlbVYgMTM4L0ZvbnROYW1lL0FyaWFsLUJvbGRN VC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA3MDAvRmxhZ3MgMzIvRGVzY2VudCAt MjExL0ZvbnRCQm94Wy02MjggLTM3NiAyMDAwIDEwMTBdL0FzY2VudCA5MDUvRm9udEZhbWls eShBcmlhbCkvQ2FwSGVpZ2h0IDcxOC9YSGVpZ2h0IDUxNS9UeXBlL0ZvbnREZXNjcmlwdG9y L0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMTEyIDAgb2JqDTw8L0xlbmd0aCA0MDQzL0ZpbHRl ci9GbGF0ZURlY29kZS9MZW5ndGgxIDgwODA+PnN0cmVhbQ0KaN7sWX1UVdeV3/e+L0RBQBD0 itznDSA8ngSJygsYH+/diwgGCRrXfSYd34P3BBIQAqi1M2lxOu2sXnQ1K37QxhXENNVoM+l9 GBMwM5loE9Pp1DadZIVp16yszMTOrJmVTtI/umKaCvM7516UENM6a82aP2Z6D/u39zln7/O1 z+eDBCJKo0FyUPOWreWrN1a1/StS/gm0va071kuNziCRdJVIqGnbOyDv+uDhNMh3EYn6rt72 bnH+s0kix0GiBY+3d+3f9Td95XGivKdhX9ORiMUv/7T+A6ICHfG1HUhIz3F3EmXIiN/R0T3w xWGX7wnEVSK3s6unLbZ4cPEI7N9Fmc7u2Bd73feklMO+Cvry7lh3onh3z3aifLRJ+Ki3p38A 7caXz8qTe/sSvdtf2/0josX1aF+EBMda4TFyUbrrCVclLAot7hilXWKW4BJFt8PtdIkOJ835 6ptlmYIkfyK6Dk7VCZWecuFlJB+m/6UvgzzlnnLXJdc+VzsPm4kYORe62h2m4znRLf5QuOr4 NkLYsVIsQcizLKffn/7l9NUpbSo0FRIuCw+4NouFroKZcoVlwjKx2FlC2+hn9AhoGzUhXCGd dlCInqUzVE/HaQzptXSAvk6P09foFO2mP0fuf0/7P2gcOWOwGkP6JbpAj9HTs1JZuEQ/p58g dRMF6M/oHtpMx1BWHLNxN1Xy1HuQ/unU4luG5eicF7QcQUFYbocKhCKkbwNdtsOjqNeK9dCP aRTyt0AngF+h79MDQJUOIa8HvcSQ8YG7E1RBbBaW81AIqqZVVq6QwlaMsAD4AwSi89wmwXOv Ck+hp+9xvPm5EGZ/vJxgY8Om+o11mhoO1QY33LO+pvruQNW6tWvuqlxdcWf5Kn+Zr7RkZXFR 4R3KCq9csDx/mbR0SV7u4pzsRVmZGQvT0xbMT52X4nG7nA5RoDIzx+cvk+sMY5M52Br1l5nL w7pgCj7DAMRkk5p1U4hGOkyHT/JaXwQGJt2vm2JhZhWkFn2N5I2skWbyjFA4I0nZRm/2eUEQ Scj+cFGNXg6VRdlyMm3auF8J75DNdCWka4oWNR1aVNETkaTTUagUboorsmHEY/FxutisKxl3 s1IjVs2Rc6Ig0OIMQ66JJZSMGl0eF+h+Mz384A60cXGG/IrklcdQ5SZlcVVE4VVKyLCa1bhV PydgCefU52xCb+2uDbZ2JJ2Uo1SZQs6YQM7MRetgEZnpS1gJy4YVFFg1gMWSTleRUoR+jk9P b9O9XpMk5NcZdVFjo7ExGjPlNj5CQlTROlV/mabUKaitKGY6i5T6ep4QRTw6E0fLNsnmYIue HAwa6Fnro515inZQ8moR1KcqXhXN0VRNRbFmHrRND3OPx6fEOhPQqKqSbjhGS5Zk+5SQ1182 JqcJIUV9CbtEBmWTUy1NrvAaqoIWNd6nNLbsQGHZmqKOZQvZWhSpQmaWHJDLSdngL5ugVyiu 3acrZnSrLmtmdEiVuBtQBfrPHKXEMHiyocP/EoYyorOWJHhTWPfDbAAMJQT9TaU+X94ECcL0 1w69IDgwi0VSVdSoi5IjkpKZFSC0RYhh4vjLrJ6kojmb4m3QIYuxmGEgYrQdRDS5wFkY+ksz L6ybMgZkQVyJD40HqVXRZDParHsl2RwFMwfbpE4zGItGIpIWSeaXG6rEEEPpm3GfZOb7WIMz WGneZDmF87/0yzyz1CdhJjZMiIMUNKXw0MG2u6HlZQ2KKTp6PBRBfpW/TJFlOBI+jZl0sIp3 RGG+R47p9YElC5GrpSaLV4LN95ctSBYVMj+kJVcWW/7Qv85GtgHVtCkZfEENSUriIOrDOnKF WStraiQ2wFevSldfjSCjJEOXXymXVkWAN9RqvDVSyVVmZiqajsj7bMZEtHw+x8ygZA5GlqJB 5ICynOFJr/FKGV4FNVoDIWzTBYkivIIMS8vLpj4UayRba5Ya13uZUrDpliAEwX3aXq0zbygU VrTW0Ni8lJJxTCMD3QorMTgXO4aO8dJk3UwJt5nzwtGIqhmaobdiCbGZH7GmL5tETOLTrWKV z3cuUV5SESo1KyCtZpK/rHYDts4vYT9sFwSObG9sp2mOUxyvc/wdx084/pbjxxyvcXyL45sc /4Hjzzi+wfGnHH/C8QrHH3P8e6LaD8F/xGN/x/GHHF/neJnjaxxf5fgDjpc4XuT4Cse/5fgy PwjaONJn8DmOf8XxWY7f43iW4xmOz3yO7QTHcY4vcnyB43mOz3M8N0v/EY67sUgT9DCXH+LY yVPaubwLGBfyOC7mKHFcwpCX82n8Fsdhjsc4HuV4hONhjo9/ju13OD7F8STHUY4nOI5wfJLj frTw07Z7OA5w7OfYx7GXYw/Hbm7VxeUOLie4jDKs+aqbd0lmZcQ3e04qYwQJRwNWhKZKOKxK tTbsPZ2K0cY2b7ZoouNUEDWM2DjJMUPWjCHjIMQhBbO/MxY3S7RmtrHKQ6pXUlS2krzesRKh JBxl66SmsQVr1qT7dK/CDhiDbWzUYhgtOOoISzASgZqssWWr8HOh1qf7dLPahz/r8Jo5rW+e DJQTZgXI5mK+Lefkho3GrTtYOWjuAQYx09GCY51vYHIGS2nRZaFGphq2q41P/2pZJOLFHpgM pBQqPp2wwRnJeUwWzBVMxMnok5Ke5aURc3F4lt6Km3rMJPXz9HjmzfJSf195qTfLm1svBnaw FfvaFVXBHWEHzjHZPKQqEdn8FZfv5fJjXE7jstzMZILM+scHmu+BTratYvd7Fbudvwx79QXK pGXUpMVbQhcoC7fGZktchMveFia+hMO2HqEBu30M8XOlgZKAFmKTIxYKVi6qyl4n1ldnN9BG qnPU12duyAyKm9SsZro3s2nRFmd9Y9Za3GdrcTcO0xp3fcClYbNje6asy2ZJuNUsDbdFzeVs Q3cV7pU70Hb4S44aB4fyIhHTVeSVO+FI7KIqq5OdJhNUQLI0QTIVRLiXy5RQ1PQrIbOulA+W Lxw15PAOPYkbjzGkhA9G0NNxuhP7NDuW+S1kfPrXy6wLwDgdu5kRmpVRK7KlNSaKuaVsksik XqBUrKmFPr02G+dD0L7GzuU3v1RK90kXaAGE2zdaYBmlQbi1UfAWRmmW0UIIt2+00DLKgDBj NDhH+bM8wzLKZGa3bZRpGWVDsIxqb8Mo2zLKhXBro8/2kaDNjfIgWEaDCJZi8EaYOzB5MIrM fH7rZeJpmFpLBSk0dWYqmTLzIrr5dDkgPmlJIqOzQqpDpRHcx1NBO9xn6VF3gLYLj1CreJZT NdIPOb9K66Hfj3gz+DfFwPQHSK8AvQdaD9JBS0AhUB2oBNTP8sQAnQI9jTICrBzGHYdoyPMn 9J+u16nAtZ0UUACy1/keyuinJZBDoGLUV+jIp2zIdSzPk8/zlvB4P3kZZ/aQtyNfQTyfleM5 RKngzM6P9CyU8zxrM3id4yJvN/pOxWjHZshu8ErwdYwjnbU9AMpCu72w64OcDrkYY+OFzKja HrMK6KeijR3Il5gNqBj1+sAVUD7KXOeYpCvCE/QNx6SQ6txGLdbY0+vI77bGbfot0BGm42Tj i34TXVeJpv7CnU1N4hpKQfp27gf4wM47zvJYXxyVtIfn7SIRVACdl5He4Bidfku0ynsI6XvE P6UFzM/C9qkzPL6L0t1Em21ZhLyB21vpBWj7etTzPvMT0XSHxacu2fw5m79h569kHD5iv2ys Yz7l/pxFrF825TLOfDXjz7mE/jTZcv4c8jPfs3FjbWM+ZG2z+NQlmz9n8zfs/LsYR5uaWNuY n+eS7etf2/xde45Xz/L3p+mrfN5X2z6fTfn23MBITF20x+ii3Z537fi7druO2WN3zG4fWxuV fIwh2/2pZOMEn/NdxPkO+fhawXxlY2rpTx9nMuN8LtvpM5ytJzan+Y8ZkKF3hMW5LwLT71gc /bZ8wtZvOvcX5vxs7vBYdSK+nPmNjc0tOLOvRtv/mcmMszjmxXrE17P1ytbMXM7WMFtHc3gz 8xdb24zzNQbZsdyaC2y8fw/na5+tv89wtp6tOThD60D/DvoG6DJIBDVhrHvZ+kqx1uv7oKcY oQydrQ3Qg8jfD9onXqEW6L2XYpV9gO2f9jpLZ/VhHHBZvj7lmcS8eYcSjt/Rfa5mKvR8RK95 PhJGMZ8K2Vp1XaQqxCXPR+KH4COgYdBJRs7D9GW7nevsdjfZ7X3Ibnuu3faZNVbM94J+2gAK zfDadP4bXAGOkAhOJx+8VIqRLsHZ6KZwaXJ5XuPWUNLh2Bmc3xA4G/hF4B/VawHXQNAlqboq 7tk5FlADmuJTX1zdUl2vBtwppVzZMRwX+oOL5sWLuuq6zsTPtv+i/TfxjxMft88bCM4vbb+7 XY//PH4t7tqzc4KW4kWK+1o3XjS72dtTG6cO7QJeM12CxOMvkQe3/zKoqaHknWtwr5a8kQny swRe2xc8XZ5ez4jnsOeE54hn1HPUfdJ9zP2Ue7i4t2ik6HDRiaIjRaNFRzf2tvee3nU68d32 0yOnD586eerY6WdOn5vsmuydHJk8/PaJt4+8Pfr20TdPvnls8pnJc5PPTr547clrj68aCPpy u3JHcg/nnsg9kjuae3Rf73Dv8Mjw4eETw0eGR4ePDp8Zfn747PD54e8Nv5CzZ+c4dWmdSqts tBlG24SQJ0iGuXFvp6p0qnkTeNJk+SbQVYbdHHcDk3kyxvmFZUFJWrpkCXuj48Uebg2xV3oy V5hgb3mtE2+DcYqNOXas9THufIDxojHXg2tRzB20Wk2mETTyGvFmaPBFzs9XKFWhxq2K9kDI QvYzxLkV2EJUVTq/YoXq9ap7tU5OeZGx/KAnrHVuC/HftGrz6NuYCU+AjoOeBn0XdAr0fZAJ SoIugF4C/TU1q7O+yMzFgsSA87fkgAudJvlWCPbH0rEGXmfPOtwxCDr0CQ4a57FP8Lh3rrZ/ E/5j+GP4/xvYCrJu7dnEfqUlYSnI/Yf/DyXS//HPSTJHJx8feXrawul/ufHKcfzBMlLpyze0 q2/8x8hBWYgJdi1ZdK8tuyHvZF5wzkNsLz1iywKeXv9myyLO9mlbdtAdQpotOyFX2LIb8v3h nt79fZ3tHQPyyrYSuSIQWO0PrJPrE/u6EgMD/uZY28OxvvgqubarS+Zq/XJfoj/RtzcRX7Ul 3NSwRfNt6+xO9Ptberpju28nhcLUQ720n/pw9LTjEBrAAK6kNhz0MlXgOhig1ThQA7QO8XpK 0D7qAg4g+LG5x6D5MLAP2/UqaNQitwv8Zmn9PJYAT4DvBTLNLai3iRrANVwttkG7m+u08F8u 96AMVubnafmh1wM5hiPyf0qHr6ID9Bj80AG/iBTHjayRuRovJ4e93orJaRy//oWdC2t+Q/NT uPuTyleiM/y6OoV7oGcVvw7aM+i/BBgAQhkFSAoNCmVuZHN0cmVhbQ1lbmRvYmoNMTEzIDAg b2JqDTw8L1N0ZW1WIDg0L0ZvbnROYW1lL09DTkpPRStUaW1lcy1Sb21hbi9Gb250U3RyZXRj aC9Ob3JtYWwvRm9udEZpbGUyIDExMiAwIFIvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzQvRGVz Y2VudCAtMjIzL0ZvbnRCQm94Wy0xNjggLTIxOCAxMDAwIDg5OF0vQXNjZW50IDkxMS9Gb250 RmFtaWx5KFRpbWVzKS9DYXBIZWlnaHQgNjYyL1hIZWlnaHQgNDUwL1R5cGUvRm9udERlc2Ny aXB0b3IvSXRhbGljQW5nbGUgMC9TdGVtSCA4ND4+DWVuZG9iag0xMTQgMCBvYmoNPDwvTGVu Z3RoIDExNjIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMjgyMD4+c3RyZWFtDQpo3tRW XUxbZRh+vtMWKAwYE1agg5ymwlhbAZl/MTMrUlDAjI4y1nIhHugZhVBa20rgQsPNkqVRw5XZ xWK42MUuvKhRYzezBJeYaNQb7kxMNuPNvJk382IXpD7n61lTHLJGFxO/L9/53uf9O+95zjnv ORAA6rEBC4ITob6Bs79mE9T8zDU9H9eS2K6/DlT7AfHG/GpGVTy2VsrP0d55IbkQ/3Hpi8vE U4DVsbC8fmH64zs9QNUV2sdiuhb9qfqSHaj9gfiFGBXOrG0XsC0TPx2LZ9Y621s/IN4kvrac mNcUu3jA+LvG+ePaWlIZsx5j/CfE6ooW10/7puaAGmKxm0ykM6ybo+Z9w55M6cnbL169yPiX iDUIfCk2YYNVuafco+bb4i58GMBv2DtEORgMvDoMP1TMKJcLp/CRwvx+iEKhIM1r2MQVfIZv xG3U0XaIurrCNNrRzIk84BvPwx4MfyrEh5G8KFzMI9BxHXZYZt98Js8CVHV4MZATbxEoPio8 LkoWnzqSs3SNTIbdETWrZkejWXVEjWnRnLVL7jTo2UifmkMovMjjVNiV80ecJVGPRF5mHquR xyrzZCPMsGRmWJIZmGCXTjbfuJqzdAfDZ8O5jYAz5w9EnC6XOpzbDoZz2wGnKxKhV1WpUu7v LraaNVez5ioPhZpilhBzMEUkmzWR0u3KbWezziyvRGrcrryAqeCVGj6WruG88Aelye92OQ2F 2+V2sY5IgLntvvFQeJiVuIxKag1KbY9QajMprSun9BDLq5OU1j8hShsqobSxIkoP709pE2s+ bFB6ZH9K3QcQWlL492F4o8jwxj4MP7WH4eaDGW4pZ/goq22RDDueEMOtlTDcVhHD7fsz7GTN 7QbDx/47hjvKGJY9xugk7Cffo62gKt2Wu0eP7+lCHnGfbt8VF8fWw6X0YMfYRQE7SrMpP48d 8RrxZFHHrFIuxTRL3FaeR7a6+3tz/5PFx8XLl9L7FYENCuD13mQvNjpgA/tcDZEVDhzht6VG IqAbnWgxMJFgb22jtU4iBR30bUIt0Q2jX6Pa+9fuvAUP7mCWvna/wvP19fU/e1oc3/K/4mnt eKwdssxHZ8vfzq6KpjEU89vRzOunJNq5qvDYIVDZqC0HDvx/hhX9xqeZUzG+zngd5+T305QK vxRuFW7tocFSARnvlSICJRItaCQS5lkbETLlKspzxl2x8h8El/C2KQs+iQ9MWUGDcJiyBZ2i y5StlIdMuYqyNpRIrqcWF2IZtWf+hDoYTczpamg9ndHjaXV0ZT6RSiZSWkaP+tSB/v6Tverg 8rIq/dNqSk/rqVU92jsxdGYsOOqdOS/DRw6GGEICSawjhUUsIIYMqevBPE5wH0SU1jnolEP0 SdOqI85dxShW6JVgXFIeNWmLwkfbAG9KP06iV+ZY5lTL8qcl0rnr3FdlVC8mWMkZjCHIzF7M 4HzZ2UcwyeMC3mEmjTEH+/4bq3m3PcW3TL53xug0BKuj9EpxOb7WPp9tPPUH2izGfyRuXP29 zthvNp3blIHdsgvbHj5JfwowAIN1JEYKDQplbmRzdHJlYW0NZW5kb2JqDTExNSAwIG9iag08 PC9TdGVtViA1Ny4yMTIvRm9udE5hbWUvT0NOSlBJK1pXQWRvYmVGL0ZvbnRTdHJldGNoL05v cm1hbC9Gb250RmlsZTIgMTE0IDAgUi9Gb250V2VpZ2h0IDQwMC9GbGFncyAzMi9EZXNjZW50 IDAvRm9udEJCb3hbMCAwIDU1MCA2NTJdL0FzY2VudCA2NTIvRm9udEZhbWlseShaV0Fkb2Jl RikvQ2FwSGVpZ2h0IC05NTMvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4N ZW5kb2JqDTExNiAwIG9iag08PC9MZW5ndGggMzkwNS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoMSA3OTg0Pj5zdHJlYW0NCmje7Fl9cFzVdT/vY7WysOSVLMuyn2W/1bMkS6u1kIVtra3g 1e570koitpA/uk8QvKvdtSSQsJBkg2FK5I4Tkie5yeCPNGRiG0oY47TpWxmDZNMAxQQokKZp OqUzgcm07phpm5ROJ0MCWNvfvW9lyyoGOtPpH23e1fmdc+89536d+7kigYjyaYwk6ty2vW5d m76nBSk/B+1KDMaHqEMOEikTREJTYv+oOvru/dsg30IkRvcM9Q5u6f71EJGE/IWP9g4c2PPn w3VJotLbYN/Ul4onf3Qx8h7Ryt8gvqEPCQVLcgaJPCriq/sGRx/46WXvIcR1ohx5YG8iXjJW cgL2X0OZ8mD8gaGcW3PrYP829NV744OpJ2ZW/oxoBcoUfjW0d2QU7ca34jWWPzScGlp19qvH iUoiaJ9AgnS3+Dy5qMD1mKsBFhUOl07RHrFIcIliruR2uURJpnlfpFNVCeEj0XXPTIvQ4H5I +CGSj9D/0uch90Puh1x/6+pzPeI6iNBHxEje5BqTbOk10S2+IjwPyZYMyS82IKx2LDOXMpcz fz/TPROaCYnPCIddfWK968JsucIB4YDYJ1eTLnTQ10E6QjP4TjKpQygTyqhN8AgaUrvpV/QM vUdP0nlqpu8j97+nfbfg56FZWAaLt5D7c3rxk1Nhv4WGEDbRv0BuJAtlrL5BasMnhnp0zqHr QzVCFdLXgp7JhgF6O/M2+Bso+58RoywN0DD9AWr6GrXQ43Q/QivSR/nANYPWUYDN4qvBhyDw Ub0D9HvCHmC90ISEd7jNoyxX6BaPC7c6+CkOz2MQ7Ghvi7S2GHo41BzccusXmjZvCjRu3LD+ loZ19TfXrfXX+mqq11RVVqzWyr3qqpVlK5Tly0qXliwpXlxU6FlUkL/wprwFue4clyxh7tfa S3z+WrXFstrssZ6Yv9ZeGY4KtuCzLEBctakzagsxs8+WfIrX+UwY2LQzaosVhY2QuqLrFa+5 XpnNs0JhT5qKraHic4IgklD8/uKmaB1UFher6fyMtVMLd6t2gRaKGpoRw9yMadGUmZalCq2i LamplpWMJ6fopc6o5tnESjWdms2zoiBQicdSm+IpzdMUVacE2mkXhO/sRhtLPOqLiledRJVt WkmjqfEqFWQ4zerYHj0rYAkviSxpQ2+zXRvr6UvLtERrtIUlkwLJhYs3wsKc7UtYC6uWEzRY tYPF07KrUqtEP6cymR1Rr9cmBfktVkvMarVaY3FbTfAREmKa0a/7aw2tRUNtlXFbrtQiEZ4Q Qzw2G0fL2lR7rCuaHgta6FnP7/eXasaE4jVM1KdrXh3NMXRDR7F2KbRtN3OP26fF+1PQaGxU rjrGSFcX+7SQ1187qeYLIU2/gF3CQ8Uk6zXpcq+la2hRx+1aR1c3Cis2NH2yWCg2YkgVCovU gFpH2hZ/7TSWW9K4ParZse1R1bBj47rC3YAq0H/mKC2OwVOtKPyvYCjNKGtJijeFdT/MBsDS QtBvq/H5SqdJEDJfOfysIGG+i6TrqDEqKpKZW1gUILRFiGPi+GudnuShOW3JBHTIYSxmWYhY iQlE0wvlitAjdmk4aqsYkIVJLTk+FaQezVDtWGfUq6j2KTB7LKH028F4zDQVw0yX1Vm6whBD 6Zt1n2KX+ViDPaw0b7qOwmUP/lOpXeNTMBPbp8UxCtpKeHwisQlaXtaguBZFj8dN5Df6azVV hSPh07hNE428IxrzPXJsrw8sXYFcIy9dtQbsJn/twnRlBfNDfnpNleOP6FfZyLajmoTm4Qtq XNFSE6gP68gVZq1salLYAF+6pFy6aCKj2hNVX6xT1prAq2pN3ial+hIzszUjisi/shljGmV8 jtlBxR4zl6NBJEFZ9bgLmryKx6uhRmcghB1RQSGTV+BxtLxs6kOxSclqzVHjej+kXEryDTQI 7jP2G/2l46GwZvSEJhfkVk9hGlnoVliLw7nYMaIYL0ON2rnhhL0gHDN1wzKsaA+WEJv5pjN9 2SRiEp9u9Wt9vrOpuur6UI1dD2kdk/y1zVsoRQ9iP+wVBI5sb+ylDMcZjlc4fszxI44fcvwt x99w/BnHv+H4U45/zfEnHP+K4485vsXxTY5vYK9/H/wveex1jq9xfJXjjzi+wvEix5c5/gXH lzi+yPEFjuzakKIER/ov+AOOf8rxTzh+n+MZjk9zPH0D22mOUxyf4/gsx3Mcn+F4do7+fRzv xSJN0T1cvptjP0/p5TKOMEoKpRxLOCoclzHk5VyPf8TxWxyPczzG8SjHIxwfvYHtH3N8guPj HE9xPMnxBMfvcjyAFl5vu4/jKMcRjsMchzju5TjIrQa43MflFJdRhjNfo/Ytit1g+ubOSW2S IOFowIowdAWHVY2RwN7Tr1kJtnmzRRObolUxy4pPkRq3VMMatyYgjmuY/f3xpF1tdLKNVR3X vYqms5Xk9U5WC9XhGFsnTR1dWLM23R71auyAsdjGRl2W1YWjjrAETRNqqsGWrcbPhWZf1Be1 N/vw5xxes6f1tZOBloRZAapdwrflJUvDVsf2blYOmnuQQdyWunCs8w1M9bCUrqgqNKnUxHa1 qcwvV5imF3tgOpBbofmihA3OSi9gsmCXMxEno09Ju1fWmHZJeI5e+TU9ZpJ3Iz2eea28vE8r L+9aefPrxcCO9WBfe0vXcEfoxjmm2od1zVTtX3L5i1z+Jpfzuax2Mpkgs/7xgeZ7oMy2Vex+ F7Hb+WuxV5+nQqqkrUayK3Seimg9dTriYiqnbUy8gMM2gtCO3T6O+NmaQHXACLHJEQ8FGxY3 Fm8UI5uL23FtbJEikcIthUGxTS/qpC8Wbl28TY50FG2gW3GTDFGY1udEAi4Dmx3bM9WoaleH e+yacCJmr2Qbuqtiv9qHtsNfasyaGC81TdtV6VX74Ujsojqrk50m07SKVGUaT5VVJvdyrRaK 2X4tZLfU8MHyhWOWGu6OpnHjsca18ISJnk7Rzdin2bHMbyFTmX9f4VwApuj4tYzQnIxmkS2t SVFcWsMmiUr6eVxZBVrkizYX43wIZq+x8/ncC26BTzlPCyF8fqOFjlE+hE82Cn6CUb5jtAjC 5zda5Bh5IMwajd3A6Br3OEaFzOxzGxU6RsUQrjcKfopRsWO0FIJjNPY5alrqGJVCuGYUnBfm F1IKI3P287PHDZG7fWYDrcqlmadnzuWS8+a59gkHxe86ksjoDD0l30dncB/PBW2G/kzOGfqy GKDHkHcXaCPSR+RvkA79TsS7wXeIgcxPkF4P+gpIA3lBVSA/KJBNY3w9bE4zQhlbWDmcE+1z 30fvuF6lItcu8oInQWVMlv+RvDkBug3kk8qoGro5kL+AvCr3Yei8yvMjWb0I4uvlEfBdtIXl MUI/qrLyKqQHUP/X0eYfg4fkp+i47PTdA94AW006zHkD40gv420fIS/GwSueyUxA9jMZY+OF 7MvaVYFaYLMZ7WR21cwGeT7UWwe+jI0L8n1SFfmFl+kR8L14z2/Ojv1p5A8yfZkyb4IeZjps bFAnLk1XGuGO/a4PMYZ7Mhmk13E/wAfZvOMsj/VFaqB9PA9XAlAOdGy0RZe7uJ93ID6O9ID4 JFVAf6Owa+ZpHt9Di3OIc0aUQ5n/4PZOOusDLiIz3E9Eme0Onzmd5ePXxzNrGcfY4y9TzX3K fDuHmD/nEnQWzvpzPqE/PVn/eufRKuZ7Nv6sbcwXrG0Onzmd5ePXxzOVjMNWZ21jfp5P3NeB zJtZ/hyjrJ8df88nNpedfO91RE7bGEf9L2TH6IVse17Pxl/Ptmtfduz2ZduXZG3JjmmScRZn awM+P8jWrStN29i4sfnKx5TrZx5mMuNcP5s+y9l6YnOa/VjFZOg9wOLMB+KGzDucBxz/sLXG 5jtbbyxtLpd64bNdVIOxYXOCr4X5nPvO6WuayeDnWRyTwg8dRuvZmpnP2Rpm62g+53MJa5tx tsaYLD1Hnmx93k/hfO2z9TefO+s/c8UhKgZVgV4GPQR6A+m/AP1AfpeGmG6us16/AXqCEdJC oLIsxUB3im9RBHqnQQXQ6QMFsutssfOT5cwfgqRctm++SynpY7rd1UkV7g/oFfcHwinMpzVs rbpeokbEFfcH4vvgJ0DfAj3OSD5CD2fbWZVtd8RpL9Y3bzvv0y/m9M2T3QvKQCtmeXMBrUSD VuEIMXHH8VEL1VAnHo8ebAHhmvTK0o7tobQk7g5K3wsIo0FpZ0DYt3syoAcMzac/t65rc0QP 5OTWpCVpd9D9SPJ48r2kNBJ0R5Knk78dkEaDC6KpB5P7Um8n5X27p2k5Xp+4mw3i9XIve2ca U9RnnMfLZUBQePwCuTHZa6Gmh9I3r8cdWvGa0+RnCbyOskMDh04cOnLo5KGjh04dOnZ54PKJ y0cun7x89PKpy8cKRoJK64nWI60nW4+2nmo91jvQe6L3SO/J3qO9p3qP5Y/am+4KSguHhBF7 wV27p2jA6Nd6VCthWYlpoVRQLLt1f7+u9eul03h6FPmm0UyGgxzvBaZLVYzHsyuCirJ82TL2 lsbLOtwTYq/p9FJhmr25jX7c4acoPil1b/AxLt/BeOWk684NKGY1rdPT+QSNwg7c7dt95rmb NMrTqGO7ZtwRcpD9XHC2HMtY15Vz5eW616vjHc+p1JwsC7rDRv+OEP/tqbmUvg2PPQb6DuhJ 0PdAT4H+DGSD0qDzoAug56lTn/OZsxcAEgPyhyRh+GWbfOVC9mPp2G/4DiTgBIAOfYQDQT7+ ER7h8joYrvxd+F34fx3YCnJu18Uk8f8eLAflfPb/i0T6P/7JpHKU+fiomYyDmX+4+hqRPrOM PHr4qvZmmn3HSHiIbc7KMuTbsnIO5C8xL8gLENuPXduRBTyRLmVlkQro46wsUbmQl5VlyLVZ OQfy1vDeoQPD/b19o+qaRLVaHwis8wc2qpHU/QOp0VF/ZzxxT3w4uVZtHhhQudqIOpwaSQ3v TyXXbgtvbe/s8O3oH0yN+EN7B5KfnUBh2ov3+gEaxrnTixNoFKO3hhI4jVWqx50tQOtwEgZo I+IRStH9NAAcRfBjZ49D8x7gMPbqtdBo5v8bU+eUNsJjKfAU+H4g09yGerdSO0rowPm/A9qD XKeL/7y4D2WwMm+k5acQWj2Akv4nNLh3hYP0TYx/Cv4QKYkbUwdzsbQBnnHWWRXJ//alvyva vajp13RTLnd7WvtybJZfabxyMZfcCX5dy86c/xRgAGxl0E8KDQplbmRzdHJlYW0NZW5kb2Jq DTExNyAwIG9iag08PC9TdGVtViAxMzMvRm9udE5hbWUvT0NOSlBLK1RpbWVzLUJvbGQvRm9u dFN0cmV0Y2gvTm9ybWFsL0ZvbnRGaWxlMiAxMTYgMCBSL0ZvbnRXZWlnaHQgNzAwL0ZsYWdz IDI2MjE3OC9EZXNjZW50IC0yMjMvRm9udEJCb3hbLTE2OCAtMjE4IDEwMDAgOTM1XS9Bc2Nl bnQgOTExL0ZvbnRGYW1pbHkoVGltZXMpL0NhcEhlaWdodCA2NzYvWEhlaWdodCA0NjEvVHlw ZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwL1N0ZW1IIDEzOT4+DWVuZG9iag0xIDAg b2JqDTw8L0Nyb3BCb3hbMCAwIDYxMiA3OTJdL0Fubm90cyAyIDAgUi9QYXJlbnQgMTIgMCBS L1N0cnVjdFBhcmVudHMgNS9Db250ZW50cyAzIDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAg NjEyIDc5Ml0vUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltMCA1IDAgUj4+L0NvbG9yU3BhY2U8 PC9DUzAgNyAwIFIvQ1MxIDk4IDAgUj4+L0ZvbnQ8PC9UVDAgOTcgMCBSL1RUMSA5NSAwIFI+ Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUMvSW1hZ2VJXS9FeHRHU3RhdGU8PC9HUzAgOTIg MCBSPj4+Pi9UeXBlL1BhZ2U+Pg1lbmRvYmoNMiAwIG9iag1bNiAwIFJdDWVuZG9iag0zIDAg b2JqDTw8L0xlbmd0aCA5MTEvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJfFRdb+M2 EHwX0P+wj3IR06Qk66M4HO7sBEEKBE3PQj9w7QNN0Q57iqhSdIz++y4pS7JzvnuIQYjh7OzM 7qzKYPEE794tHtcPt0Dh/fvV7RqCxf2Gwr4LFmVJgUG5CyihlEZQCnAnhqcjMEqKHB/R04nR HDI8Rnj7EnwOP8K25s0XaaGz3MqXWR7KxoJ95u5HQmu4sErIDirZCaO2spr9Xf7sazE21KKx r1UQLEqhrBAYVIMACt9pcRhgKw2NtsDbtv5vNs9CsBqOyshadh2MuLQYcZcOd94DzxlhbOnQ w0baozZfOtjyTlagG/jl8eMNxPdPTzfAm8qfIuhaKdSs/KdHzUbUzKFGKEK8HOjulOBW6aaD oz7UFWylb79Tjno7m0chcrRw5D1vvYNvyjA/IZ/x5a9aVarZ94oI3exqJSwBeNj5MnfrTw8l uJbcPw2MWTwCM69vThI2EN4bfWhPZFsjd9I4MQ9thS6CsoPuhdO9c1eTvCMsY728Hnei+znk QhwMAjmX8hAQvpbCoigoAd4Y5+UwGb3Rkxoj58RzzsgksuwkDNbdwFFOWj/jSIwT0Rr9qioJ /IxzPsKmPWePe85Z6DOrUINaIVn0yQ/BZC+vNUp8VPYZiVfjZ+2NUMbPJn7dqlrZv37wnEjP 4+7Rbd20iWzYROq5OVp0ZHQbhN7Ht4+i8dFJIgHlj0H4Se65qVCU8c0dbv1DU6tGblAcOQLE A8C/QZGSLCuKIu8XPKZ+u1OakDhyUx6DeEGQFwq3Ovi1h11dhEkyhskUIo7S29SIEDMboF1w XG9u+XVzp5FAx3KSswTmlOQF6x1bSdv1A7bWr7Kur8ucXoC+mQOn3fqZK3NzWvlycz//4yq5 7KxXdtarN47FhEZ9w/7khFwmmev9slu0hdGULPE2JlkEiZtukuS4I8Hujbr51+qyUxGsEFOH EiWkSJxC39K0+I6m18J9ySKSpH24C/ETzOZJnoa/EVjprpPG7QifRWEzCLaRwkjLjcLA9/ov 1hsGouthATrRnKecL7skaR4PS/26vQT+YBXXfnCJNvt+g2E/zlXmGbtQvNouo9+zex6lqPVl VmGHLF3S8HcCf6qxKyulcVm69qng/pTFb+CH5XzQNi1vpurjTl9T4ZTBaZEMvR954xNCfRja VzUxWIn0aUSQWyia6/ExRYGTx0ns3S1IFkeDRBeD978AAwCFcAf4DQplbmRzdHJlYW0NZW5k b2JqDTQgMCBvYmoNPDwvTGVuZ3RoIDE4Mi9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0K aN7swSEPRUAAAODrZruiKK6ZZtNNvGKziyZI8pmoKKLJ2gUTzXZFNFnQTKMois1U937Fa74P ACCEeN+37/sgCKqqOo5jWRZCyPM8vu8rimJZlqqq0zTpuq5p2r7v8zzLsrxtWxRFCCHTNO/7 tm17GIZxHDnnbdsahpGmaVEU67rWdd00zXmeeZ47jhPHMca4LMskSbIsgxBSSq/rYox1XSdJ kuu6YRh6ngc+n3/6CTAAbNlQwgoNCmVuZHN0cmVhbQ1lbmRvYmoNNSAwIG9iag08PC9TdWJ0 eXBlL0ltYWdlL0xlbmd0aCA3ODYvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25l bnQgOC9Db2xvclNwYWNlIDcgMCBSL1dpZHRoIDEyOS9IZWlnaHQgNDAvVHlwZS9YT2JqZWN0 Pj5zdHJlYW0NCmje7FVtk5owEHbCywHZvHAxCJwGUYkI2lba///bGoI3vSli59pr/VB3hpkd QnafffbZBaGHPewfmuN6g+M/ve+iG3xE+jDCQKxHGY/fc/NZwPwDAMiE+oveSUki3nXT41n+ 5/lf8BKtpCVUMW+apyvvwC3Ww2G58ZbXLm0DTn7R1h2vTGpqvBXH+loaRPdQs+wwPiBVsd1V jZTyOhFxf63d/YJGiNEOei/DcK0KVB5ByFOkP42AHSN2ZO28TK+HTjV89qd6tNXNcE0b9qOt cb4I0l7nSIIBuFP5aHYIVs2N+moVoin+C2BAbXnYQXltmA81x1PBDlnfqp8AOPw8o9ktcatp cN65arCduKVCDvTeiqjN1OeRYWBNfm4BbWcUpvP7iRy9W7ZDkPSovaSzbqtz9tw7XRJNxgLX PMW4RFa8KrMc74+KOW/7GJnySg42SVwQxeXQHcnBOrHS04RxF/nYGacQeJia2KhkNMDBW3ZC JQ5mzxV78ELpKkw2l2wUMovdBz69AnK+MVr5MYaON+jXmw1NizN3y0dqCMibdQBno6BaolDU NUC1F6shvZsB77V4EDUWzhSAr6Q0vRKL8qIIRk7WaWYW9LNuUC5aVK7lyUefXmeyTfxLexqW mGPUgBFAy8RnU+8RclRuu0VXzommc800KufpFACi7MbsBpW2vKqYnY1agyHyQCR6IdhtvBCt ZU3gsswog8JrD4HGctOYgdjYUlOO+zoo54SrfT9YHlaEV+mNcYpJVlnpriwC4aLACNjfB6Gv 6jbgbbjDAI7NyQ2lr6NfVrLu5IEaQGtedGpQ8WFvc8Wb5atunzZ5eHNX0mQWpXmef4lYv/mT qIU89RbSBMr1saP9Nj3ZqOlpizSU4xBzRr5tf/tv9SS4OhMFQkkD2rCdBV5m1DxM+/DJm9nk 15bfzvmT/2XrVCsa7/In++8i57PqvEnSGkzRX7VVefv8smHvZ5ql9wVAOPrPASz0nQGAujMA Vt81/QvqILwnAK/8Ju7KAHWj4K4AUE1e0MMe9rCPse8CDAANi185Cg0KZW5kc3RyZWFtDWVu ZG9iag02IDAgb2JqDTw8L1JlY3RbMzEzLjI2IDQ5Ni44NDkgNDIwLjEzMSA1MTEuMjc3XS9T dWJ0eXBlL0xpbmsvQlM8PC9TL1MvVyAwL1R5cGUvQm9yZGVyPj4vQSA4IDAgUi9GIDQvSC9J L1N0cnVjdFBhcmVudCA2L0JvcmRlclswIDAgMF0vVHlwZS9Bbm5vdD4+DWVuZG9iag03IDAg b2JqDVsvSW5kZXhlZCA5OCAwIFIgMjU1IDQgMCBSXQ1lbmRvYmoNOCAwIG9iag08PC9VUkko bWFpbHRvOndhbnlpQG1haWwucml0dC5jb20uY24pL1MvVVJJPj4NZW5kb2JqDTkgMCBvYmoN PDwvRmlyc3QgNTI3L0xlbmd0aCAxNTA4L0ZpbHRlci9GbGF0ZURlY29kZS9OIDY3L1R5cGUv T2JqU3RtPj5zdHJlYW0NCnjaxFjbbttGEPWnLNCX9iEm904CQQDJrhFHiS1EKvog+IGWGVu1 LAoUVcQ/3/bM7lIiadmKgsYJIo12OXPmssOZWXPNYsYN47Fg3DLJFeMJk4llPGU2NkzELDGc Cc7SBCtw4R8TknEhFRNglxr7mnGVYB9IhqQgb0XC8J8nWjCRAs8COAaSlNADmoLikdDYl4CE MEHKVDGpAQ19kqCVZtICGnolII3GOgVNU6aAZ5VkCngWeAp4CfixJZIEz4GXAhxbIoVTCpAx lCu4GqegUC3gs0pBrWI6hilYa6iSRjKYLhWUapiqYL8m0+AcmWAQMk0mYqGBZ4BHrlgLOeAl ccIM8BLIGzI90cwAL00EA7SKEWgD1TEWBiZTXI0Bhd8GpgoEwSSgScwMXJFY2xjUGmZhusKZ WAEKEEsu4qjggtIAscAzXDCwKgOjLPBsDD7gWThpgWdTwwCtEgQPR6dSBP/t22hA6RCzz9Ew K/NFNS7znDKjvXORf60G+SOz0edinn/KlpQ1xDJ+XObRqCrXU8f3uSiq6GSerVaOJyWed+9I y8Q4TPLQEeNJ6knsiA2EeyI8kY5ov1JeAH47oj3xYNZrsF6D9ZzSb0q/Kf2m8hpUwPQalMdU HlN5TOnIVTRk3O1Ho2iUTyvn08X6YTWJKdeJk1Oy0w9B2e5kKd0dFuW7c4IS3jlMGU/ADuh8 MZ8t8tFdhliezW7XZR6dlsXyJFvWy8t1RSzRaJktotH6ejUtZ8uqXi7zsrnRq6pseveAo/tF xDwaRuPLHj4n+Jw5ivOa3efFOvCPcbj94mt0Ovs7OiuLB0jc5dnNbHELeRG9F9FFUT5k89a+ jN7L6PfFzaKocjzH1xnOfrvqFzePYCNsyP2xuMnLrQcw5JwsOYe+7CF3mkc58ZC1s2qeg7bi AReCxNa7VTR04Wv7SxWMDoo8oTJGvxvuUEmjLe8SFbY2g6QaR1sNB6jcubN3JlLRc6lPdlLl o0XDKiqCddrD22ne+1JBKj6OXaR789ktDq3Kyiq6jD5mj3QOf5azCvo/FTd59LEcX3vBfv6l KPON5Dm0Lyr2RtAGQh/WtHJwYU2Pu8q5+b+079GdJE+VJ9+tWxykfIff8eu4/SM1S/NyxLXY cdyipf3DelXNvjy+kufmp8W84/YhqjeiP0H3d73fu/tpaEGhrWrfykzoOXJ/k/UktC3tOUPv +uaWe+XavcT35fVfGCa3c8Jl/wPKIjVTby6a6cfZ4j4a3rJENUcFt6gBwixS83ShtG5ABYDg B98YkeyUFC8ZEbznusZId2H4eWQHxmT34BF/1/wRpoV6GnH2cR4M2xlg2Q0w37h20mqhAIpr eC7coFOLtjptGyEMBAMWNwXqMeEZXn4Ar9jH25uoxI9mAybpIHhgbg5Tz6BP6mO4OsAifQCv 2c/bnLAGmKsbAs1HbZ/pHkM8A5bs19AZAwcs3X24fkhsyr5+AxV1ExvOgUBWhXPcKutjREWu YpjAdUHhW7hvI/F91T0AX7OexiiEUfMQRq7oXZGBZzultosBuXGaT4syq2bFwr1pW9aNgW2u k2JelBP4Sb4yvstG8bKNqraR3gUpfoaNEx3uMq5cPk23hv4e3Ym9waEiD+l27CXGp46nX5Sw aFQ9zvNf//n36OKoOFoc5b+F/bY1+Fw1Dt9xjO9m0/tFvlptGjAsDBdJsTGzrsjjUMlrM4bh mkmPaLgPZcT4Wuytp2oSABrnMs6u53knPfvzYnq/NXCb2jQCm1Zyu6Rt5q9W8tigQkshjxU0 i+M0VlfdMBr5TBgbOUR1w4iXz8XoGpDyiL9mHrnb5GAiwlzSKrf+ptnSfVJfAjt9pb4adpib l9FOd2k+6op5o5jaY0yP/kjyYrFtofpba6fIhqtsh7V5NYbdLVdb1+aO3LaR8m8waMttDuK2 B3EnB3Gnh3CLeC93j/6g5c9ItGKyaf8N5m94d98o/eRCq+p3V6ZoUhifJb3BiabfRta5/vxd +0dfvv4TYABmZvdpDQplbmRzdHJlYW0NZW5kb2JqDTEwIDAgb2JqDTw8L051bXNbMCAxMSAw IFJdPj4NZW5kb2JqDTExIDAgb2JqDTw8L1MvRD4+DWVuZG9iag0xMiAwIG9iag08PC9Db3Vu dCAyL1R5cGUvUGFnZXMvS2lkc1s4NCAwIFIgMSAwIFJdPj4NZW5kb2JqDTEzIDAgb2JqDTw8 L1N1YnR5cGUvWE1ML0xlbmd0aCA0ODAxL1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFj a2V0IGJlZ2luPSLvu78iIGlkPSJXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQiPz4KPHg6eG1w bWV0YSB4bWxuczp4PSJhZG9iZTpuczptZXRhLyIgeDp4bXB0az0iQWRvYmUgWE1QIENvcmUg NC4wLWMzMTYgNDQuMjUzOTIxLCBTdW4gT2N0IDAxIDIwMDYgMTc6MTQ6MzkiPgogICA8cmRm OlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRh eC1ucyMiPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAg ICB4bWxuczpwZGY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8iPgogICAgICAgICA8 cGRmOlByb2R1Y2VyPkFjcm9iYXQgRGlzdGlsbGVyIDguMC4wIChXaW5kb3dzKTwvcGRmOlBy b2R1Y2VyPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlv biByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6cGRmeD0iaHR0cDovL25zLmFkb2Jl LmNvbS9wZGZ4LzEuMy8iPgogICAgICAgICA8cGRmeDpfRW1haWxTdWJqZWN0PkVTSUYgTFM8 L3BkZng6X0VtYWlsU3ViamVjdD4KICAgICAgICAgPHBkZng6X0F1dGhvckVtYWlsRGlzcGxh eU5hbWU+QnVycm91Z2hzLCBLaXJrPC9wZGZ4Ol9BdXRob3JFbWFpbERpc3BsYXlOYW1lPgog ICAgICAgICA8cGRmeDpfQXV0aG9yRW1haWw+a2lya2JAcXVhbGNvbW0uY29tPC9wZGZ4Ol9B dXRob3JFbWFpbD4KICAgICAgICAgPHBkZng6X0FkSG9jUmV2aWV3Q3ljbGVJRD4xMDk2MDY4 NTkxPC9wZGZ4Ol9BZEhvY1Jldmlld0N5Y2xlSUQ+CiAgICAgICAgIDxwZGZ4OkNvbW1lbnRz PkFkb3B0ZWQgMTEvMTgvMjAwMjwvcGRmeDpDb21tZW50cz4KICAgICAgICAgPHBkZng6U291 cmNlTW9kaWZpZWQ+RDoyMDA4MDUxMjA3MDIyNjwvcGRmeDpTb3VyY2VNb2RpZmllZD4KICAg ICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0 PSIiCiAgICAgICAgICAgIHhtbG5zOnhhcD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4w LyI+CiAgICAgICAgIDx4YXA6Q3JlYXRvclRvb2w+QWNyb2JhdCBQREZNYWtlciA4LjAgZm9y IFdvcmQ8L3hhcDpDcmVhdG9yVG9vbD4KICAgICAgICAgPHhhcDpNb2RpZnlEYXRlPjIwMDgt MDUtMTJUMDM6MDI6MzYtMDQ6MDA8L3hhcDpNb2RpZnlEYXRlPgogICAgICAgICA8eGFwOkNy ZWF0ZURhdGU+MjAwOC0wNS0xMlQwMzowMjozMy0wNDowMDwveGFwOkNyZWF0ZURhdGU+CiAg ICAgICAgIDx4YXA6TWV0YWRhdGFEYXRlPjIwMDgtMDUtMTJUMDM6MDI6MzYtMDQ6MDA8L3hh cDpNZXRhZGF0YURhdGU+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRl c2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4YXBNTT0iaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyI+CiAgICAgICAgIDx4YXBNTTpEb2N1bWVudElE PnV1aWQ6ZTRiMzNmY2MtY2Q4OS00ZDk5LTg0ODctNjFjMmY2MWExYWI1PC94YXBNTTpEb2N1 bWVudElEPgogICAgICAgICA8eGFwTU06SW5zdGFuY2VJRD51dWlkOmU5OTNjNDdiLWZkNjEt NGYyNy1iMjBkLWE5YmRlMGUyZjFmNjwveGFwTU06SW5zdGFuY2VJRD4KICAgICAgICAgPHhh cE1NOnN1YmplY3Q+CiAgICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8cmRm OmxpPjQ8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6U2VxPgogICAgICAgICA8L3hhcE1N OnN1YmplY3Q+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0 aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczpkYz0iaHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8iPgogICAgICAgICA8ZGM6Zm9ybWF0PmFwcGxpY2F0aW9uL3Bk ZjwvZGM6Zm9ybWF0PgogICAgICAgICA8ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpT ZXE+CiAgICAgICAgICAgICAgIDxyZGY6bGk+QmV0c3kgS2lkd2VsbDwvcmRmOmxpPgogICAg ICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwvZGM6Y3JlYXRvcj4KICAgICAgICAgPGRj OnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4 bWw6bGFuZz0ieC1kZWZhdWx0Ij5UU0ctTiBPdXRnb2luZyBDb3JyZXNwb25kZW5jZSBUZW1w bGF0ZTwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0 bGU+CiAgICAgICAgIDxkYzpkZXNjcmlwdGlvbj4KICAgICAgICAgICAgPHJkZjpBbHQ+CiAg ICAgICAgICAgICAgIDxyZGY6bGkgeG1sOmxhbmc9IngtZGVmYXVsdCI+M0dQUDIgQ29ycmVz cG9uZGVuY2U8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2Rj OmRlc2NyaXB0aW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6cGhvdG9zaG9wPSJodHRw Oi8vbnMuYWRvYmUuY29tL3Bob3Rvc2hvcC8xLjAvIj4KICAgICAgICAgPHBob3Rvc2hvcDpo ZWFkbGluZT4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAgIDxyZGY6bGk+ M0dQUDIgQ29ycmVzcG9uZGVuY2U8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6U2VxPgog ICAgICAgICA8L3Bob3Rvc2hvcDpoZWFkbGluZT4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+ CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/Pg0KZW5kc3RyZWFt DWVuZG9iag0xNCAwIG9iag08PC9DcmVhdGlvbkRhdGUoRDoyMDA4MDUxMjAzMDIzMy0wNCcw MCcpL19FbWFpbFN1YmplY3QoRVNJRiBMUykvU3ViamVjdCgzR1BQMiBDb3JyZXNwb25kZW5j ZSkvQXV0aG9yKEJldHN5IEtpZHdlbGwpL0NyZWF0b3IoQWNyb2JhdCBQREZNYWtlciA4LjAg Zm9yIFdvcmQpL19BdXRob3JFbWFpbERpc3BsYXlOYW1lKEJ1cnJvdWdocywgS2lyaykvUHJv ZHVjZXIoQWNyb2JhdCBEaXN0aWxsZXIgOC4wLjAgXChXaW5kb3dzXCkpL19BdXRob3JFbWFp bChraXJrYkBxdWFsY29tbS5jb20pL01vZERhdGUoRDoyMDA4MDUxMjAzMDIzNi0wNCcwMCcp L19BZEhvY1Jldmlld0N5Y2xlSUQoMTA5NjA2ODU5MSkvQ29tbWVudHMoQWRvcHRlZCAxMS8x OC8yMDAyKS9Tb3VyY2VNb2RpZmllZChEOjIwMDgwNTEyMDcwMjI2KS9UaXRsZShUU0ctTiBP dXRnb2luZyBDb3JyZXNwb25kZW5jZSBUZW1wbGF0ZSk+Pg1lbmRvYmoNeHJlZg0KMCA4Mg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDI0NjIwIDAwMDAwIG4NCjAwMDAwMjQ5MjEgMDAw MDAgbg0KMDAwMDAyNDk0NCAwMDAwMCBuDQowMDAwMDI1OTI0IDAwMDAwIG4NCjAwMDAwMjYx NzUgMDAwMDAgbg0KMDAwMDAyNzExMyAwMDAwMCBuDQowMDAwMDI3MjY2IDAwMDAwIG4NCjAw MDAwMjczMDkgMDAwMDAgbg0KMDAwMDAyNzM3MCAwMDAwMCBuDQowMDAwMDI4OTc1IDAwMDAw IG4NCjAwMDAwMjkwMTEgMDAwMDAgbg0KMDAwMDAyOTAzNiAwMDAwMCBuDQowMDAwMDI5MDk1 IDAwMDAwIG4NCjAwMDAwMzM5NzQgMDAwMDAgbg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQp0cmFpbGVyDQo8PC9TaXplIDgyPj4NCnN0YXJ0eHJlZg0K MTE2DQolJUVPRg0K --------------010406000408050109050106 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --------------010406000408050109050106-- From ecrit-bounces@ietf.org Mon May 12 10:26:42 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A8F28C298; Mon, 12 May 2008 10:26:42 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877FA28C28A for ; Mon, 12 May 2008 10:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLv4xm6jL9ky for ; Mon, 12 May 2008 10:26:39 -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 4BF7F3A676A for ; Mon, 12 May 2008 10:26:39 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 12 May 2008 10:25:45 -0700 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 m4CHPi9M014679 for ; Mon, 12 May 2008 10:25:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4CHPhcx008790 for ; Mon, 12 May 2008 17:25:44 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 10:25:39 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.88.236]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 10:25:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 May 2008 12:25:38 -0500 To: "'ECRIT'" From: "James M. Polk" In-Reply-To: <48287315.5080100@gmx.net> References: <48287315.5080100@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 12 May 2008 17:25:39.0462 (UTC) FILETIME=[329FEA60:01C8B455] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1661; t=1210613144; x=1211477144; 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]=20[Fwd=3A=203GPP2=20TSG-X=20Cor r=20to=20IETF=20re=20ECRIT/WGLC] |Sender:=20; bh=8nv/2nPmoYtvjSUlOhCHSlKcKlImMafiSEDjWRYZBHw=; b=rmwNmDa/42OIZe0s4kvc3GCnW6osL5+iNeO+q7cvY6hA6yZbS7zX1xwUNR xpLwA49HKW+sM06DAu6RMjbAvolg/BKIFaxx79dG/gxkV3YT1JyD64Tzq0Yk EtZZ0hrPUO; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org wow... I'm curious if all of these "requirements they don't support" are because: - they leaning or dependent on legacy/circuit-switched infrastructures, - which of the requirements they ever plan on adopting (in full or in part), or - which of the requirements they do not see the desire to ever support? In other words, giving the list of requires they simply want to list as non-compliant is a good start, but stating why ("not yet", "not ever", or "only if this one is changed" (hopefully also pointing "in this (X) way")) would obviously be what I would like to read next from them. James At 11:40 AM 5/12/2008, Hannes Tschofenig wrote: >Comments from 3GPP2 regarding the ECRIT framework and Phone BCP documents. > >Would be interesting to hear your feedback. > >-------- Original Message -------- >Subject: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC >Date: Mon, 12 May 2008 03:30:19 -0400 >From: Andrew Dryden >To: Hannes Tschofenig >CC: TSG-X Chairman's reflector , Victoria >Bosserman , > > > >Dear Hannes: > > >Please see attached correspondence from 3GPP2 TSG-X to IETF. > > >Many thanks, > >Andy Dryden (for Betsy Covell, 3GPP2 TSG-X Chair) > > >Andy Dryden > >3GPP2 > >2500 Wilson Blvd., Suite 300 > >Arlington, VA 22201 > >Phone: +1 703-907-7702 > >Fax: +1 703-907-7728 > >http://www.3gpp2.org > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 12 10:45:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8543A67EE; Mon, 12 May 2008 10:45:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C1E3A67EE for ; Mon, 12 May 2008 10:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+dkwNazhqFX for ; Mon, 12 May 2008 10:45:30 -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 3F24F3A67E1 for ; Mon, 12 May 2008 10:45:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,474,1204531200"; d="scan'208";a="46017262" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 12 May 2008 10:45:07 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4CHj7lU028121; Mon, 12 May 2008 10:45:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4CHitdN028610; Mon, 12 May 2008 17:45:07 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 10:45:03 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.88.236]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 10:45:03 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 May 2008 12:45:02 -0500 To: Hannes Tschofenig From: "James M. Polk" In-Reply-To: <48287EB8.2060702@gmx.net> References: <48287315.5080100@gmx.net> <48287EB8.2060702@gmx.net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 12 May 2008 17:45:03.0621 (UTC) FILETIME=[E8847B50:01C8B457] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2779; t=1210614307; x=1211478307; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20[Fwd=3A=203GPP2=20TSG-X=20Cor r=20to=20IETF=20re=20ECRIT/WGLC] |Sender:=20; bh=hHzP7wen1dMdwxcXhT7nbxRpvRrO3GRJIx2CXI0YV2s=; b=Xgr7a7hofCT3p2j/3E3VVVUX8rbHONWv/9s5lNqSDc3rHgw+MKa7mNvG6H o740xiK5pljtJKB5s2nCHID6moZK1oj8Q7xoHbeIUNMTUutMhrdtYioCPxXG bsu37qFoE6FXtqEPMX6mAvAUq1MYd92xpSXMOdBExJXKT+cwv//YM=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:30 PM 5/12/2008, Hannes Tschofenig wrote: >I asked them how they want the feedback to their comments. > >I was easy to see that someone would come up with further questions... Initially, I just want them to categorize where they see each requirement. Someone (of a group) obviously went through what's in both docs and said: "no , no, no, not yet, not that way, not that way, not yet, wish we could - but we can't (for whatever reason), no, not yet, not ever, etc, etc..." to the list of reqs. I just want to know which category each req is in. Having a blanket "not ever" (which is how that list comes across) isn't good enough, because it lacks the information they likely already have (i.e., the category) from their notes or emails)... James >Ciao >Hannes > > >James M. Polk wrote: >>wow... >> >>I'm curious if all of these "requirements they don't support" are because: >> >>- they leaning or dependent on legacy/circuit-switched infrastructures, >>- which of the requirements they ever plan on adopting (in full or >>in part), or >>- which of the requirements they do not see the desire to ever support? >> >>In other words, giving the list of requires they simply want to >>list as non-compliant is a good start, but stating why ("not yet", >>"not ever", or "only if this one is changed" (hopefully also >>pointing "in this (X) way")) would obviously be what I would like >>to read next from them. >> >>James >> >>At 11:40 AM 5/12/2008, Hannes Tschofenig wrote: >> >>>Comments from 3GPP2 regarding the ECRIT framework and Phone BCP documents. >>> >>>Would be interesting to hear your feedback. >>> >>>-------- Original Message -------- >>>Subject: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC >>>Date: Mon, 12 May 2008 03:30:19 -0400 >>>From: Andrew Dryden >>>To: Hannes Tschofenig >>>CC: TSG-X Chairman's reflector , >>>Victoria Bosserman , >>> >>> >>> >>>Dear Hannes: >>> >>> >>>Please see attached correspondence from 3GPP2 TSG-X to IETF. >>> >>> >>>Many thanks, >>> >>>Andy Dryden (for Betsy Covell, 3GPP2 TSG-X Chair) >>> >>> >>>Andy Dryden >>> >>>3GPP2 >>> >>>2500 Wilson Blvd., Suite 300 >>> >>>Arlington, VA 22201 >>> >>>Phone: +1 703-907-7702 >>> >>>Fax: +1 703-907-7728 >>> >>>http://www.3gpp2.org >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www.ietf.org/mailman/listinfo/ecrit >>> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 12 10:48:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4791B3A680A; Mon, 12 May 2008 10:48:33 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611783A67E1 for ; Mon, 12 May 2008 10:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 7S5MvOTWe9Pl for ; Mon, 12 May 2008 10:48:30 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0A2C63A68EC for ; Mon, 12 May 2008 10:48:29 -0700 (PDT) Received: (qmail invoked by alias); 12 May 2008 17:48:18 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp017) with SMTP; 12 May 2008 19:48:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18g5MheqakgVDTswT6v5dJmXVKuhXBFCwmqxUD/8i RzrF07aGLxVCu4 Message-ID: <482882E7.5020001@gmx.net> Date: Mon, 12 May 2008 20:48:23 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "James M. Polk" References: <48287315.5080100@gmx.net> <48287EB8.2060702@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I fully understand your reasoning. I hope that they can some 3GPP2 members are interested to join for this discussion Ciao Hannes James M. Polk wrote: > At 12:30 PM 5/12/2008, Hannes Tschofenig wrote: >> I asked them how they want the feedback to their comments. >> >> I was easy to see that someone would come up with further questions... > > Initially, I just want them to categorize where they see each > requirement. Someone (of a group) obviously went through what's in > both docs and said: "no , no, no, not yet, not that way, not that > way, not yet, wish we could - but we can't (for whatever reason), no, > not yet, not ever, etc, etc..." to the list of reqs. I just want to > know which category each req is in. > > Having a blanket "not ever" (which is how that list comes across) > isn't good enough, because it lacks the information they likely > already have (i.e., the category) from their notes or emails)... > > James > > > >> Ciao >> Hannes >> >> >> James M. Polk wrote: >>> wow... >>> >>> I'm curious if all of these "requirements they don't support" are >>> because: >>> >>> - they leaning or dependent on legacy/circuit-switched infrastructures, >>> - which of the requirements they ever plan on adopting (in full or >>> in part), or >>> - which of the requirements they do not see the desire to ever support? >>> >>> In other words, giving the list of requires they simply want to list >>> as non-compliant is a good start, but stating why ("not yet", "not >>> ever", or "only if this one is changed" (hopefully also pointing "in >>> this (X) way")) would obviously be what I would like to read next >>> from them. >>> >>> James >>> >>> At 11:40 AM 5/12/2008, Hannes Tschofenig wrote: >>> >>>> Comments from 3GPP2 regarding the ECRIT framework and Phone BCP >>>> documents. >>>> >>>> Would be interesting to hear your feedback. >>>> >>>> -------- Original Message -------- >>>> Subject: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC >>>> Date: Mon, 12 May 2008 03:30:19 -0400 >>>> From: Andrew Dryden >>>> To: Hannes Tschofenig >>>> CC: TSG-X Chairman's reflector , Victoria >>>> Bosserman , >>>> >>>> >>>> >>>> Dear Hannes: >>>> >>>> >>>> Please see attached correspondence from 3GPP2 TSG-X to IETF. >>>> >>>> >>>> Many thanks, >>>> >>>> Andy Dryden (for Betsy Covell, 3GPP2 TSG-X Chair) >>>> >>>> >>>> Andy Dryden >>>> >>>> 3GPP2 >>>> >>>> 2500 Wilson Blvd., Suite 300 >>>> >>>> Arlington, VA 22201 >>>> >>>> Phone: +1 703-907-7702 >>>> >>>> Fax: +1 703-907-7728 >>>> >>>> http://www.3gpp2.org >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 12 10:57:50 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6C0C3A67EE; Mon, 12 May 2008 10:57:50 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC953A688B for ; Mon, 12 May 2008 10:57:48 -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 26aBaAXHC546 for ; Mon, 12 May 2008 10:57:47 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 1BDEF3A6807 for ; Mon, 12 May 2008 10:57:46 -0700 (PDT) Received: (qmail invoked by alias); 12 May 2008 17:30:28 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp032) with SMTP; 12 May 2008 19:30:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+VYgoxI+2VRjc5VABUfwDhH/TA1/WthjH20jukYN yv37mmNUlcJYPk Message-ID: <48287EB8.2060702@gmx.net> Date: Mon, 12 May 2008 20:30:32 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "James M. Polk" References: <48287315.5080100@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I asked them how they want the feedback to their comments. I was easy to see that someone would come up with further questions... Ciao Hannes James M. Polk wrote: > wow... > > I'm curious if all of these "requirements they don't support" are because: > > - they leaning or dependent on legacy/circuit-switched infrastructures, > - which of the requirements they ever plan on adopting (in full or in > part), or > - which of the requirements they do not see the desire to ever support? > > In other words, giving the list of requires they simply want to list > as non-compliant is a good start, but stating why ("not yet", "not > ever", or "only if this one is changed" (hopefully also pointing "in > this (X) way")) would obviously be what I would like to read next from them. > > James > > At 11:40 AM 5/12/2008, Hannes Tschofenig wrote: > >> Comments from 3GPP2 regarding the ECRIT framework and Phone BCP documents. >> >> Would be interesting to hear your feedback. >> >> -------- Original Message -------- >> Subject: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC >> Date: Mon, 12 May 2008 03:30:19 -0400 >> From: Andrew Dryden >> To: Hannes Tschofenig >> CC: TSG-X Chairman's reflector , Victoria >> Bosserman , >> >> >> >> Dear Hannes: >> >> >> Please see attached correspondence from 3GPP2 TSG-X to IETF. >> >> >> Many thanks, >> >> Andy Dryden (for Betsy Covell, 3GPP2 TSG-X Chair) >> >> >> Andy Dryden >> >> 3GPP2 >> >> 2500 Wilson Blvd., Suite 300 >> >> Arlington, VA 22201 >> >> Phone: +1 703-907-7702 >> >> Fax: +1 703-907-7728 >> >> http://www.3gpp2.org >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 12 11:53:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9712F28C1CD; Mon, 12 May 2008 11:53:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D55E3A67C1 for ; Mon, 12 May 2008 11:53:25 -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 yH2cgCHlgdtm for ; Mon, 12 May 2008 11:53:23 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 221E53A68C3 for ; Mon, 12 May 2008 11:52:10 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jvd61-00005B-Io; Mon, 12 May 2008 13:50:01 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <48287315.5080100@gmx.net> Date: Mon, 12 May 2008 14:50:04 -0400 Message-ID: <0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoA In-Reply-To: <48287315.5080100@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I would say that we have to design for the Internet, and systems that work in walled gardens may not need everything that a general Internet device would. Specifics: ED-5 is devices must recognize local dial strings. I believe 3GPP does this. I don't know what 3GPP2 does. ED-5 is also SP-4. It's possible we could water down this to say where the SP knows for certain where the location of the devices is at all times, then it can handle the recognition of dial strings and not require the end device to do that. I'd rather not do that. ED-7 local dial strings should be determined from LoST. It's a should. There is no exception condition, but I would say access network knowledge and any other mechanism is what the exception would be. ED-12 Endpoints, Intermediate Devices and Service Providers MUST be prepared to handle location represented in either civic or geo form. This is an interesting one. If the device knows it's on a mobile network and always gets geo, what does this mean? Should we alter the text? What do they actually do if the device is a dual WiFi/mobile and roams to a WiFi network that reports civic? ED-15 Devices, intermediate Devices and/or access networks SHOULD support a manual method to "override" the location the access network determines. It's a "should". This has always been a controversial requirement. We've discussed the tradeoffs. You can argue for a known mobile device with a network that knows it always using GPS wouldn't do this. Same question on WiFi roaming. ED-16 Devices MAY support end-system measured location. Its definitely a MAY, but of course this is the usual 3GPP determination method (A-GPS) ED-17 Devices that support endpoint measuring of location MUST have at least a coarse location capability (typically <1km accuracy when not location hiding) at all times for routing of calls. This mechanism MAY be a service provided by the access network. They do this. Why are they complaining? ED-18 Endpoints SHOULD configure their own location It's a SHOULD. Do 3GPP2 systems assume no fixed devices? In 3GPP, the fixed devices are expected to do endpoint location configuration. Maybe they haven't gotten to that point yet ED-24 This is "supply an API to get location for apps that need it" I think they are dead wrong. AIM on a 3GPP2 phone needs a location API. ED-25 Endpoints SHOULD obtain location immediately after obtaining local network configuration information It's a should. I happen to think they should do this, but that's just me. ED-26 If the device is configured to use DHCP for bootstrapping, it MUST include both options for location acquisition (civic and geodetic), the option for LIS discovery, and the option for LoST discovery Huh? Since they don't support DHCP, this is a don't care ED-37 For calls sent with location-by-reference, with a SIP or SIPS scheme, the server resolving the reference MUST support a SUBSCRIBE [RFC3265] to the presence event [RFC3856]. Huh? So far, they aren't saying what they will support. It will have to be SIP or HELD in the U.S. ED-47 Endpoints MUST support one or more mechanisms that allow them to determine their public IP address. We may want to change this. If the device does LoST or LIS discovery, it needs its IP address. If it doesn't do LIS or LoST discovery, it doesn't need it. On the other hand, they have the AOL problem. They need a solution for that, and it may be LIS and/or LoST discovery. ED-48 Endpoints MUST support LIS discovery as described in [I-D.thomson-geopriv-lis-discovery], and the LoST discovery as described in [I-D.ietf-ecrit-dhc-lost-discovery]. Same as above ED-49 The device MUST have a configurable default LoST server parameter. Same as above ED-50 Endpoints who obtain their own location SHOULD perform LoST mapping to the PSAP URI. It says "endpoints who obtain their own location". Otherwise, same as above ED-51 Mapping SHOULD be performed at boot time and whenever location ... Same as above ED-52 The endpoint MUST attempt to update its location at the time of an emergency call Same as above ED-53 The endpoint SHOULD attempt to update the LoST mapping at the time of an emergency call Same as above SP-4 Local dial strings MUST be recognized Can't have it both ways folks. Either the endpoint does it or the service provider does it (see ED-5) SP-6 Local emergency dial strings SHOULD be determined from LoST It's a should for this reason. SP-10 Endpoints, Intermediate Devices and Service Providers MUST be prepared to handle location represented in either civic or geo form. See above on ED-12 SP-17 If a proxy is attempting to insert location but the UA conveyed a location to it, the proxy MUST use the UA's location for routing and MUST convey that location towards the PSAP. I more or less understand them, but I disagree. I think they say that they insert location, and if an endpoint sends them location, they ignore it. I think they are wrong; if the endpoint says it's somewhere, you are best to believe it. The network can add what it thinks the location is to the call. SP-18 All location objects received by a proxy MUST be delivered to the PSAP. Again, I think this is incorrect. If the device sends location, it should be sent to the PSAP. SP-32 SIP Proxy servers processing emergency calls: 1. If the proxy does interprets dial plans on behalf of user agents, the proxy MUST look for the local emergency dial string at the location of the end device and MAY look for the home dial string. If it finds it, the proxy MUST: * Insert a Geolocation header as above. Location-by-reference MUST be used because proxies must not insert bodies. * Include the Geolocation "inserted-by=server" and "used-for- routing" parameters. * Map the location to a PSAP URI using LoST. * Add a Route header with the PSAP URI. * Replace the Request-URI (which was the dial string) with the service URN appropriate for the emergency dial string. * Route the call using normal SIP routing mechanisms. 2. If the proxy recognizes the service URN in the Request URI, and does not find a Route header with a PSAP URI, it MUST run LoST routing. If a location was provided (which should be the case), the proxy uses that location to query LoST. The proxy may have to dereference a location by reference to get a value. If a location is not present, and the proxy can query a LIS which has the location of the UA it MUST do so. If no location is present, and the proxy does not have access to a LIS which could provide location, the proxy MUST supply a default location (See Section 6.11). The location (in the signaling, obtained from a LIS, or default) MUST be used in a query to LoST with the service URN received with the call. The resulting URI MUST be placed in a Route header added to the call. 3. The "inserted-by=" parameter in any Geolocation: header received on the call MUST NOT be modified or deleted in transit. 4. The proxy SHOULD NOT modify any parameters in Geolocation headers received in the call. It MAY add a Geolocation header. Such an additional location SHOULD NOT be used for routing; the location provided by the UA should be used. 5. Either a P-Asserted-Identity [RFC3325] or an Identity header [RFC4474], or both, MUST be included to identify the sender. I think this is pretty close to what they do, although they don't (currently) do anything with LoST. They would have to do this for NENA i3. SP-34 Unitialized devices SHOULD have a persistent URI in a P-Asserted-Identity: header if there is some way to assign such an identifier to the device This shouldn't be a problem. It's SHOULD, and it says "if possible". The ability to call back an unitialized device is important. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 12, 2008 12:41 PM To: 'ECRIT' Subject: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Comments from 3GPP2 regarding the ECRIT framework and Phone BCP documents. Would be interesting to hear your feedback. -------- Original Message -------- Subject: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC Date: Mon, 12 May 2008 03:30:19 -0400 From: Andrew Dryden To: Hannes Tschofenig CC: TSG-X Chairman's reflector , Victoria Bosserman , Dear Hannes: Please see attached correspondence from 3GPP2 TSG-X to IETF. Many thanks, Andy Dryden (for Betsy Covell, 3GPP2 TSG-X Chair) Andy Dryden 3GPP2 2500 Wilson Blvd., Suite 300 Arlington, VA 22201 Phone: +1 703-907-7702 Fax: +1 703-907-7728 http://www.3gpp2.org _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 12 12:16:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2B13A67CE; Mon, 12 May 2008 12:16:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88143A67C1 for ; Mon, 12 May 2008 12:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN90puxBIYnP for ; Mon, 12 May 2008 12:16:10 -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 717763A67CE for ; Mon, 12 May 2008 12:16:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,475,1204531200"; d="scan'208";a="46064048" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 12 May 2008 12:15:09 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4CJF8eq021992; Mon, 12 May 2008 12:15:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4CJF8a5021989; Mon, 12 May 2008 19:15:08 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 12:15:08 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.88.236]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 12:15:07 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 May 2008 14:15:06 -0500 To: "Brian Rosen" , "'Hannes Tschofenig'" , "'ECRIT'" From: "James M. Polk" In-Reply-To: <0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com> References: <48287315.5080100@gmx.net> <0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 12 May 2008 19:15:08.0006 (UTC) FILETIME=[7DC83060:01C8B464] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10096; t=1210619709; x=1211483709; c=relaxed/simple; s=sjdkim2002; 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]=20[Fwd=3A=203GPP2=20TSG-X=20Cor r=20to=20IETF=20re=20ECRIT/WGLC] |Sender:=20; bh=Lk53pJ7vhXxtUO/dhmvQYz2Fq5+bZWH+60Td9XEXXFg=; b=NWceKo3v83p23BmqSENib5U9QpjbNz0OyEUNBrSr5q+WM8hCzPZzD71kYO PT+xY+AptE9v5VzMXIIb4qj7sboWtve+EFE6g9cvucvS6jGjbZMosut5s3tK eL79HL0qkd; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org While I appreciate what my co-author has offered (as far as details are concerned), I want to hear what 3GPP2 thinks, and at least the categorization (see previous email today about this) of why they will not support each of the 44 requirements they listed. James At 01:50 PM 5/12/2008, Brian Rosen wrote: >I would say that we have to design for the Internet, and systems that work >in walled gardens may not need everything that a general Internet device >would. > >Specifics: >ED-5 is devices must recognize local dial strings. I believe 3GPP does >this. I don't know what 3GPP2 does. ED-5 is also SP-4. It's possible we >could water down this to say where the SP knows for certain where the >location of the devices is at all times, then it can handle the recognition >of dial strings and not require the end device to do that. I'd rather not >do that. > >ED-7 local dial strings should be determined from LoST. It's a should. >There is no exception condition, but I would say access network knowledge >and any other mechanism is what the exception would be. > >ED-12 Endpoints, Intermediate Devices and Service > Providers MUST be prepared to handle location represented in either > civic or geo form. >This is an interesting one. If the device knows it's on a mobile network >and always gets geo, what does this mean? Should we alter the text? What >do they actually do if the device is a dual WiFi/mobile and roams to a WiFi >network that reports civic? > >ED-15 Devices, intermediate Devices and/or access networks > SHOULD support a manual method to "override" the location the access > network determines. > >It's a "should". This has always been a controversial requirement. We've >discussed the tradeoffs. You can argue for a known mobile device with a >network that knows it always using GPS wouldn't do this. Same question on >WiFi roaming. > >ED-16 Devices MAY support end-system measured location. Its definitely a >MAY, but of course this is the usual 3GPP determination method (A-GPS) > >ED-17 Devices that support endpoint measuring of location > MUST have at least a coarse location capability (typically <1km > accuracy when not location hiding) at all times for routing of calls. > This mechanism MAY be a service provided by the access network. >They do this. Why are they complaining? > >ED-18 Endpoints SHOULD configure their own location >It's a SHOULD. Do 3GPP2 systems assume no fixed devices? In 3GPP, the >fixed devices are expected to do endpoint location configuration. Maybe >they haven't gotten to that point yet > >ED-24 This is "supply an API to get location for apps that need it" >I think they are dead wrong. AIM on a 3GPP2 phone needs a location API. > >ED-25 Endpoints SHOULD obtain location immediately after > obtaining local network configuration information >It's a should. I happen to think they should do this, but that's just me. > >ED-26 If the device is configured to use DHCP for > bootstrapping, it MUST include both options for location acquisition > (civic and geodetic), the option for LIS discovery, and the option > for LoST discovery >Huh? Since they don't support DHCP, this is a don't care > >ED-37 For calls sent with location-by-reference, with a SIP or > SIPS scheme, the server resolving the reference MUST support a > SUBSCRIBE [RFC3265] to the presence event [RFC3856]. >Huh? So far, they aren't saying what they will support. It will have to be >SIP or HELD in the U.S. > >ED-47 Endpoints MUST support one or more mechanisms that allow them > to determine their public IP address. >We may want to change this. If the device does LoST or LIS discovery, it >needs its IP address. If it doesn't do LIS or LoST discovery, it doesn't >need it. On the other hand, they have the AOL problem. They need a >solution for that, and it may be LIS and/or LoST discovery. > >ED-48 Endpoints MUST support LIS discovery as described in > [I-D.thomson-geopriv-lis-discovery], and the LoST discovery as > described in [I-D.ietf-ecrit-dhc-lost-discovery]. >Same as above > >ED-49 The device MUST have a configurable default LoST server > parameter. >Same as above > >ED-50 Endpoints who obtain their own location SHOULD perform LoST > mapping to the PSAP URI. >It says "endpoints who obtain their own location". Otherwise, same as above > >ED-51 Mapping SHOULD be performed at boot time and whenever location ... >Same as above > >ED-52 The endpoint MUST attempt to update its location at the time of > an emergency call >Same as above > >ED-53 The endpoint SHOULD attempt to update the LoST mapping at the > time of an emergency call >Same as above > >SP-4 Local dial strings MUST be recognized >Can't have it both ways folks. Either the endpoint does it or the service >provider does it (see ED-5) > >SP-6 Local emergency dial strings SHOULD be determined from LoST >It's a should for this reason. > >SP-10 Endpoints, Intermediate Devices and Service Providers MUST be > prepared to handle location represented in either civic or geo form. >See above on ED-12 > >SP-17 If a proxy is attempting to insert location but the UA conveyed > a location to it, the proxy MUST use the UA's location for routing > and MUST convey that location towards the PSAP. >I more or less understand them, but I disagree. I think they say that they >insert location, and if an endpoint sends them location, they ignore it. I >think they are wrong; if the endpoint says it's somewhere, you are best to >believe it. The network can add what it thinks the location is to the call. > >SP-18 All location objects received by a proxy MUST be delivered to > the PSAP. >Again, I think this is incorrect. If the device sends location, it should >be sent to the PSAP. > > >SP-32 SIP Proxy servers processing emergency calls: > 1. If the proxy does interprets dial plans on behalf of user agents, > the proxy MUST look for the local emergency dial string at the > location of the end device and MAY look for the home dial string. > If it finds it, the proxy MUST: > * Insert a Geolocation header as above. Location-by-reference > MUST be used because proxies must not insert bodies. > * Include the Geolocation "inserted-by=server" and "used-for- > routing" parameters. > * Map the location to a PSAP URI using LoST. > * Add a Route header with the PSAP URI. > * Replace the Request-URI (which was the dial string) with the > service URN appropriate for the emergency dial string. > * Route the call using normal SIP routing mechanisms. > > 2. If the proxy recognizes the service URN in the Request URI, and > does not find a Route header with a PSAP URI, it MUST run LoST > routing. If a location was provided (which should be the case), > the proxy uses that location to query LoST. The proxy may have > to dereference a location by reference to get a value. If a > location is not present, and the proxy can query a LIS which has > the location of the UA it MUST do so. If no location is present, > and the proxy does not have access to a LIS which could provide > location, the proxy MUST supply a default location (See > Section 6.11). The location (in the signaling, obtained from a > LIS, or default) MUST be used in a query to LoST with the service > URN received with the call. The resulting URI MUST be placed in > a Route header added to the call. > 3. The "inserted-by=" parameter in any Geolocation: header received > on the call MUST NOT be modified or deleted in transit. > 4. The proxy SHOULD NOT modify any parameters in Geolocation headers > received in the call. It MAY add a Geolocation header. Such an > additional location SHOULD NOT be used for routing; the location > provided by the UA should be used. > 5. Either a P-Asserted-Identity [RFC3325] or an Identity header > [RFC4474], or both, MUST be included to identify the sender. >I think this is pretty close to what they do, although they don't >(currently) do anything with LoST. They would have to do this for NENA i3. > >SP-34 Unitialized devices SHOULD have a persistent URI in a > P-Asserted-Identity: header if there is some way to assign such an > identifier to the device >This shouldn't be a problem. It's SHOULD, and it says "if possible". The >ability to call back an unitialized device is important. > >rest later> > >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >Hannes Tschofenig >Sent: Monday, May 12, 2008 12:41 PM >To: 'ECRIT' >Subject: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > >Comments from 3GPP2 regarding the ECRIT framework and Phone BCP documents. > >Would be interesting to hear your feedback. > >-------- Original Message -------- >Subject: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC >Date: Mon, 12 May 2008 03:30:19 -0400 >From: Andrew Dryden >To: Hannes Tschofenig >CC: TSG-X Chairman's reflector , Victoria >Bosserman , > > > >Dear Hannes: > > > >Please see attached correspondence from 3GPP2 TSG-X to IETF. > > > >Many thanks, > >Andy Dryden (for Betsy Covell, 3GPP2 TSG-X Chair) > > > >Andy Dryden > >3GPP2 > >2500 Wilson Blvd., Suite 300 > >Arlington, VA 22201 > >Phone: +1 703-907-7702 > >Fax: +1 703-907-7728 > >http://www.3gpp2.org > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 12 17:53:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7483A3A68B9; Mon, 12 May 2008 17:53:01 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931B53A68B9 for ; Mon, 12 May 2008 17:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 5SN3DK7l0kpr for ; Mon, 12 May 2008 17:52:58 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B0B053A687E for ; Mon, 12 May 2008 17:52:57 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_12_20_06_52 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, 12 May 2008 20:06:52 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 May 2008 19:52:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 May 2008 19:52:51 -0500 Message-ID: In-Reply-To: <0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoAAAz7mrA= References: <48287315.5080100@gmx.net> <0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 13 May 2008 00:52:54.0292 (UTC) FILETIME=[AD6E0540:01C8B493] Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, I think I disagree with some of your assessments below, and my rationale is included inline. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Tuesday, 13 May 2008 4:50 AM > To: 'Hannes Tschofenig'; 'ECRIT' > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > I would say that we have to design for the Internet, and systems that work > in walled gardens may not need everything that a general Internet device > would. > > Specifics: > ED-5 is devices must recognize local dial strings. I believe 3GPP does > this. I don't know what 3GPP2 does. ED-5 is also SP-4. It's possible we > could water down this to say where the SP knows for certain where the > location of the devices is at all times, then it can handle the > recognition > of dial strings and not require the end device to do that. I'd rather not > do that. > [AJW] I think what is important is that the SP knows the what the user is intending. I think that in a great many case, a user plugging into a foreign network, but communicating back to a home SP will use home SP dial strings. I want to make sure we allow this for several reasons. The first is that it makes it MUCH easier for the SP to behave in a manner that the caller expects without the SP having to become aware of the location and associated call semantics associated with that environment. Secondly, like it or not, people are creatures of habit, they want to dial the same thing to get the same service no matter where they are. Yes, part 2 can be addressed with UI and device mapping stuff, but then you arrive at having to provide a solution for problem 1. Simply allowing the SP to know the service based on the notion of "home dial strings" avoids this whole can of worms. > ED-7 local dial strings should be determined from LoST. It's a should. > There is no exception condition, but I would say access network knowledge > and any other mechanism is what the exception would be. > > ED-12 Endpoints, Intermediate Devices and Service > Providers MUST be prepared to handle location represented in either > civic or geo form. > This is an interesting one. If the device knows it's on a mobile network > and always gets geo, what does this mean? Should we alter the text? What > do they actually do if the device is a dual WiFi/mobile and roams to a > WiFi > network that reports civic? > [AJW] With the introduction and deployment of femto cells I think that civic for 3GPP devices, at least packet-based devices is a reasonable thing. I think assuming geo here is a bit short-sighted. > ED-15 Devices, intermediate Devices and/or access networks > SHOULD support a manual method to "override" the location the access > network determines. > > It's a "should". This has always been a controversial requirement. We've > discussed the tradeoffs. You can argue for a known mobile device with a > network that knows it always using GPS wouldn't do this. Same question on > WiFi roaming. > [AJW] I am not a fan of this requirement, but its not a battle that I am prepared to put the energy into trying to win. At least on in this forum... ;) > ED-16 Devices MAY support end-system measured location. Its definitely a > MAY, but of course this is the usual 3GPP determination method (A-GPS) > [AJW] This seems an odd requirement for 3GPP2 to not support. I think that the priory solution deployed in these networks is MS-Assisted, but is there no MS-based deployed at all anywhere? > ED-17 Devices that support endpoint measuring of location > MUST have at least a coarse location capability (typically <1km > accuracy when not location hiding) at all times for routing of calls. > This mechanism MAY be a service provided by the access network. > They do this. Why are they complaining? > [AJW] I really hate the parenthetical as in many cellular cases, particularly for omni-cell systems this is not practical, and if it is for routing, it may not even be necessary. I think I have asked before for this to be removed, and if I haven't I am definitely and strongly asking now. > ED-18 Endpoints SHOULD configure their own location > It's a SHOULD. Do 3GPP2 systems assume no fixed devices? In 3GPP, the > fixed devices are expected to do endpoint location configuration. Maybe > they haven't gotten to that point yet > [AJW] I think for your comment on 3GPP fixed solutions a clear document reference to this information very important for any response to 3GPP2. It isn't a requirement in 3GPP that I am aware of, so I wouldn't mind seeing it also.... ;) > ED-24 This is "supply an API to get location for apps that need it" > I think they are dead wrong. AIM on a 3GPP2 phone needs a location API. > [AJW] I think that this is going to be more of a handset and carrier issue. Handset vendors and handset OS definers need to make APIs available, certainly Android is doing this (though I don't like the level it is pitched at). Carrier need to make it possible for the necessary applications to get access this information in their networks, until now putting third-party applications on some network operator phones was essentially impossible. I am not sure that defining a standard API in 3GPP(2) is the right thing to do. > ED-25 Endpoints SHOULD obtain location immediately after > obtaining local network configuration information > It's a should. I happen to think they should do this, but that's just me. > [AJW] This one I think just highlights the fundamental difference in assumed architectures. The Internet model is putting near total control at the end-point, 3GPP(2) still assumes that a single entity owns access and service, owns it by proxy using roaming agreements. The Internet model can work in the 2GPP(2) architecture, but the converse is not true. I think ultimately that the Internet model will prevail as roaming agreements and their associated complexities will drown under their own weight, but until that happens I think we need to accepts that not all network will make location available directly to the end-point when it attaches to the network. > ED-26 If the device is configured to use DHCP for > bootstrapping, it MUST include both options for location acquisition > (civic and geodetic), the option for LIS discovery, and the option > for LoST discovery > Huh? Since they don't support DHCP, this is a don't care > [AJW] Should just be not applicable then. > ED-37 For calls sent with location-by-reference, with a SIP or > SIPS scheme, the server resolving the reference MUST support a > SUBSCRIBE [RFC3265] to the presence event [RFC3856]. > Huh? So far, they aren't saying what they will support. It will have to > be > SIP or HELD in the U.S. > [AJW] At present I, and a number of other people, remain unconvinced that the current event packages and presence filter options for SIP meet the needs of subscribing for location in this way. We probably need to decide if we an a generic change of a specific one. I tend to think a specific one is better since I don't see an application outside of location at this point, so the "generic" component doesn't really have a point of reference. > ED-47 Endpoints MUST support one or more mechanisms that allow them > to determine their public IP address. > We may want to change this. If the device does LoST or LIS discovery, it > needs its IP address. If it doesn't do LIS or LoST discovery, it doesn't > need it. On the other hand, they have the AOL problem. They need a > solution for that, and it may be LIS and/or LoST discovery. > [AJW] LIS discovery does not always require you to know the external IP address. Similarly I don't believe that LoST discovery does either. > ED-48 Endpoints MUST support LIS discovery as described in > [I-D.thomson-geopriv-lis-discovery], and the LoST discovery as > described in [I-D.ietf-ecrit-dhc-lost-discovery]. > Same as above > [AJW] Reference update to LIS discovery si required. > ED-49 The device MUST have a configurable default LoST server > parameter. > Same as above > > ED-50 Endpoints who obtain their own location SHOULD perform LoST > mapping to the PSAP URI. > It says "endpoints who obtain their own location". Otherwise, same as > above > > ED-51 Mapping SHOULD be performed at boot time and whenever location ... > Same as above > > ED-52 The endpoint MUST attempt to update its location at the time of > an emergency call > Same as above > > ED-53 The endpoint SHOULD attempt to update the LoST mapping at the > time of an emergency call > Same as above > > SP-4 Local dial strings MUST be recognized > Can't have it both ways folks. Either the endpoint does it or the service > provider does it (see ED-5) > [AJW] See my note above.. I think you can definitely have it both ways. > SP-6 Local emergency dial strings SHOULD be determined from LoST > It's a should for this reason. > > SP-10 Endpoints, Intermediate Devices and Service Providers MUST be > prepared to handle location represented in either civic or geo form. > See above on ED-12 > > SP-17 If a proxy is attempting to insert location but the UA conveyed > a location to it, the proxy MUST use the UA's location for routing > and MUST convey that location towards the PSAP. > I more or less understand them, but I disagree. I think they say that > they > insert location, and if an endpoint sends them location, they ignore it. > I > think they are wrong; if the endpoint says it's somewhere, you are best to > believe it. The network can add what it thinks the location is to the > call. > [AJW] A proxy can't insert location it goes against the rule in 3261. Either we change this to a location URI, or we change the text to say B2BUA, the term proxy is incorrect without a normative change to SIP. > SP-18 All location objects received by a proxy MUST be delivered to > the PSAP. > Again, I think this is incorrect. If the device sends location, it should > be sent to the PSAP. > [AJW] Delivered does not mean delivered in-band. I2, for example, would meet this requirement, but the location will not be sent to the PSAP in-band. > > SP-32 SIP Proxy servers processing emergency calls: > 1. If the proxy does interprets dial plans on behalf of user agents, > the proxy MUST look for the local emergency dial string at the > location of the end device and MAY look for the home dial string. > If it finds it, the proxy MUST: > * Insert a Geolocation header as above. Location-by-reference > MUST be used because proxies must not insert bodies. > * Include the Geolocation "inserted-by=server" and "used-for- > routing" parameters. > * Map the location to a PSAP URI using LoST. > * Add a Route header with the PSAP URI. > * Replace the Request-URI (which was the dial string) with the > service URN appropriate for the emergency dial string. > * Route the call using normal SIP routing mechanisms. > > 2. If the proxy recognizes the service URN in the Request URI, and > does not find a Route header with a PSAP URI, it MUST run LoST > routing. If a location was provided (which should be the case), > the proxy uses that location to query LoST. The proxy may have > to dereference a location by reference to get a value. If a > location is not present, and the proxy can query a LIS which has > the location of the UA it MUST do so. If no location is present, > and the proxy does not have access to a LIS which could provide > location, the proxy MUST supply a default location (See > Section 6.11). The location (in the signaling, obtained from a > LIS, or default) MUST be used in a query to LoST with the service > URN received with the call. The resulting URI MUST be placed in > a Route header added to the call. > 3. The "inserted-by=" parameter in any Geolocation: header received > on the call MUST NOT be modified or deleted in transit. > 4. The proxy SHOULD NOT modify any parameters in Geolocation headers > received in the call. It MAY add a Geolocation header. Such an > additional location SHOULD NOT be used for routing; the location > provided by the UA should be used. > 5. Either a P-Asserted-Identity [RFC3325] or an Identity header > [RFC4474], or both, MUST be included to identify the sender. > I think this is pretty close to what they do, although they don't > (currently) do anything with LoST. They would have to do this for NENA > i3. > > SP-34 Unitialized devices SHOULD have a persistent URI in a > P-Asserted-Identity: header if there is some way to assign such an > identifier to the device > This shouldn't be a problem. It's SHOULD, and it says "if possible". The > ability to call back an unitialized device is important. > [AJW] Uninitialized devices that have an IP address and general access to the Internet. I really hate this term because it so ambiguous as to what the device has rights to use. > rest later> > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Monday, May 12, 2008 12:41 PM > To: 'ECRIT' > Subject: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > Comments from 3GPP2 regarding the ECRIT framework and Phone BCP documents. > > Would be interesting to hear your feedback. > > -------- Original Message -------- > Subject: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC > Date: Mon, 12 May 2008 03:30:19 -0400 > From: Andrew Dryden > To: Hannes Tschofenig > CC: TSG-X Chairman's reflector , Victoria > Bosserman , > > > > Dear Hannes: > > > > Please see attached correspondence from 3GPP2 TSG-X to IETF. > > > > Many thanks, > > Andy Dryden (for Betsy Covell, 3GPP2 TSG-X Chair) > > > > Andy Dryden > > 3GPP2 > > 2500 Wilson Blvd., Suite 300 > > Arlington, VA 22201 > > Phone: +1 703-907-7702 > > Fax: +1 703-907-7728 > > http://www.3gpp2.org > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 12 23:55:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE49628C2D3; Mon, 12 May 2008 23:55:11 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9113628C2CA for ; Mon, 12 May 2008 23:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g5tkjDCDNL6 for ; Mon, 12 May 2008 23:55:09 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 6C22028C2D3 for ; Mon, 12 May 2008 23:55:09 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4D6rpK0001610 for ; Tue, 13 May 2008 09:54:22 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 09:54:19 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 09:54:11 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 09:54:11 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT: Next Steps Thread-Index: Aci0xiYT8Tfr/b0sTjidVQI13yxHHQ== From: To: X-OriginalArrivalTime: 13 May 2008 06:54:11.0969 (UTC) FILETIME=[26550710:01C8B4C6] X-Nokia-AV: Clean Subject: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, The chairs had a chat with our AD regarding the next steps with the working group. Here is a short summary. It is OK for Jon to add the following documents to the charter of the group: * Location Hiding PS and Requirements * Synchronizing Location-to-Service Translation (LoST) Servers * Specifying Holes in LoST Service Boundaries I asked the Henning and James to tell whether it is useful to merge the last two documents or not. No useful response so far. Hence, I will treat these two documents separately. I will ask the group in separate mails for a hum on these documents. The following items are currently outside the scope of the working group and would, if necessary, require a rechartering: * Unauthenticated Emergency Services * Solution for Location Hiding We plan to start the rechartering discussions before the next IETF meeting. Another topic of interest for discussion is the "early warning topic". There is a separate mailing list for it (see https://www1.ietf.org/mailman/listinfo/earlywarning) and we should discuss there what we could do and where that work could take place. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon May 12 23:59:26 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F0028C2EC; Mon, 12 May 2008 23:59:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3927D28C2DC for ; Mon, 12 May 2008 23:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDKBQyqTghfo for ; Mon, 12 May 2008 23:59:23 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 33CFF28C2E2 for ; Mon, 12 May 2008 23:59:23 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4D6w5t2014137 for ; Tue, 13 May 2008 01:59:03 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 09:58:56 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 09:58:55 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 09:58:56 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Joint Meeting with the 3GPP Thread-Index: Aci0xs+n4p4X0MQFSwyEeoI65gafGQ== From: To: X-OriginalArrivalTime: 13 May 2008 06:58:56.0165 (UTC) FILETIME=[CFB9E550:01C8B4C6] X-Nokia-AV: Clean Subject: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, We would like to inform you that we are currently planning to organize a meeting with the 3GPP around August 2008. The main topic for our discussion is the harmonization of the 3GPP and the IETF emergency services architecture. We will distribute more details as soon as they are available. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 00:12:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B993A6BDA; Tue, 13 May 2008 00:12:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F463A6883 for ; Tue, 13 May 2008 00:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 PJWdCKtmtfHa for ; Tue, 13 May 2008 00:12:15 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7FB563A6803 for ; Tue, 13 May 2008 00:12:15 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4D79qWB002575 for ; Tue, 13 May 2008 10:09:54 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 10:09:46 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 10:09:45 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 10:09:45 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hum: draft-schulzrinne-ecrit-location-hiding-req Thread-Index: Aci0yFKCAdMTvHCNQROxAcz1h6h62g== From: To: X-OriginalArrivalTime: 13 May 2008 07:09:45.0908 (UTC) FILETIME=[5300CF40:01C8B4C8] X-Nokia-AV: Clean Subject: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0330946127==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0330946127== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B4C8.52CB610A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B4C8.52CB610A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 Henning gave a presentation about this draft at previous IETF meetings. Although this is a controversal topic we believe it is important to capture the problem statement and the requirements. This document is NOT meant to capture solutions -- this is something for future work. We would therefore like to confirm the hum on the mailing list. If you have not stated your opinion or if you object please let us know.=20 Deadline for your response: 30 May 2008 Ciao Hannes & Marc ------_=_NextPart_001_01C8B4C8.52CB610A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hum: draft-schulzrinne-ecrit-location-hiding-req

Hi all,

Henning gave a presentation about = this draft at previous IETF meetings. Although this is a controversal = topic we believe it is important to capture the problem statement and = the requirements. This document is NOT meant to capture solutions -- = this is something for future work. We would therefore like to confirm = the hum on the mailing list. If you have not stated your opinion or if = you object please let us know.

Deadline for your response: 30 = May 2008

Ciao
Hannes & Marc

------_=_NextPart_001_01C8B4C8.52CB610A-- --===============0330946127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0330946127==-- From ecrit-bounces@ietf.org Tue May 13 00:12:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE983A6883; Tue, 13 May 2008 00:12:19 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C1F83A6883 for ; Tue, 13 May 2008 00:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 E1fzwHy1p9nk for ; Tue, 13 May 2008 00:12:17 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9BEE03A6803 for ; Tue, 13 May 2008 00:12:17 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4D79di0026481 for ; Tue, 13 May 2008 02:09:57 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 10:09:53 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 10:09:52 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 10:09:51 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hum: draft-schulzrinne-ecrit-lost-sync Thread-Index: Aci0yFZmL/J7cDnVTXWULpWjb9Xfkw== From: To: X-OriginalArrivalTime: 13 May 2008 07:09:52.0726 (UTC) FILETIME=[57112760:01C8B4C8] X-Nokia-AV: Clean Subject: [Ecrit] Hum: draft-schulzrinne-ecrit-lost-sync X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1863624256==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1863624256== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B4C8.56A66E96" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B4C8.56A66E96 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 Henning gave a presentation about this draft at previous IETF meetings. There was very positive feedback from the group. We would therefore like to confirm the hum on the mailing list. If you have not stated your opinion or if you object please let us know.=20 Deadline for your response: 30 May 2008 Ciao Hannes & Marc ------_=_NextPart_001_01C8B4C8.56A66E96 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hum: draft-schulzrinne-ecrit-lost-sync

Hi all,

Henning gave a presentation about = this draft at previous IETF meetings. There was very positive feedback = from the group. We would therefore like to confirm the hum on the = mailing list. If you have not stated your opinion or if you object = please let us know.

Deadline for your response: 30 = May 2008

Ciao
Hannes & Marc


------_=_NextPart_001_01C8B4C8.56A66E96-- --===============1863624256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1863624256==-- From ecrit-bounces@ietf.org Tue May 13 00:15:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30323A6883; Tue, 13 May 2008 00:15:42 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867633A6883 for ; Tue, 13 May 2008 00:15:41 -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 2K9BcJfRXDdy for ; Tue, 13 May 2008 00:15:40 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id EA5593A6803 for ; Tue, 13 May 2008 00:15:39 -0700 (PDT) Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4D7D9IT014148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 May 2008 10:13:10 +0300 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4D79v2S017894 for ; Tue, 13 May 2008 10:09:59 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 10:09:58 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 10:09:57 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 10:09:56 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hum: draft-winterbottom-ecrit-specifying-holes-00.txt Thread-Index: Aci0yFlT7K4XRgHpQjWo9BBW+hAgxQ== From: "hannes.tschofenig@nsn.com" To: X-OriginalArrivalTime: 13 May 2008 07:09:57.0210 (UTC) FILETIME=[59BD5BA0:01C8B4C8] X-Nokia-AV: Clean Subject: [Ecrit] Hum: draft-winterbottom-ecrit-specifying-holes-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi all, James gave a presentation about this draft at previous IETF meetings. There was positive feedback from the group. We would therefore like to confirm the hum on the mailing list. If you have not stated your opinion or if you object please let us know. Deadline for your response: 30 May 2008 Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 01:37:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E249028C2B1; Tue, 13 May 2008 01:37:35 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 209803A67A5 for ; Tue, 13 May 2008 01:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SPEC_LEO_MEDS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+DtDO4qmV+D for ; Tue, 13 May 2008 01:37:33 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 842C928C2C9 for ; Tue, 13 May 2008 01:37:32 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2256638fga.41 for ; Tue, 13 May 2008 01:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5KQtjFO4cRX3zWNiMvp0e0tm6mx2sHDRBj4C7b5kPsU=; b=xVnSvllBYgkjM67pugnfpyQLWbHq35eO5/cp2CDVsmq4/k1CjxxW66ygAw3YdcF3PqU+nYZiNI5hRVqmO1Jg/o07VS43BjU9dpH0Z8ftO9wBElofNn129hY1F+sXzlzGUq0YFjai7xtMleQTq/lPVthfIXf+HIS750wHmjmUnQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W4UXb5Ss9AWTnm6ne+xmI/A3Ms5T8YaUq4iD/xBN70YRWukFw2ubW4yUWnvunjYKHl8ywhIZvK4B7QJghXhstPXryKZhcFFA8m4ihUl/jHCrlQ7BxsPVIsJdHmo0K0gZxNex1NIqgQUKzKWKq9+QiXG7/RAxVNKp+ZtdzovrX7s= Received: by 10.82.169.4 with SMTP id r4mr900173bue.66.1210667798575; Tue, 13 May 2008 01:36:38 -0700 (PDT) Received: by 10.82.165.10 with HTTP; Tue, 13 May 2008 01:36:38 -0700 (PDT) Message-ID: Date: Tue, 13 May 2008 10:36:38 +0200 From: "Karl Heinz Wolf" To: "Stark, Barbara" In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA087DA942@crexc41p> MIME-Version: 1.0 Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA080ECE71@crexc41p> <7E6ACFE7-BF6B-4AF8-9F36-9A70010502B9@cisco.com> <7582BC68E4994F4ABF0BD4723975C3FA087DA7B6@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA087DA942@crexc41p> Cc: ECRIT Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Barbara! I'm not sure if your DSL Forum document is the right place for my ELIN concern: should there be a note "do not to use the LLDP-MED location data type ELIN"? At least an ELIN would be problematic in your document looking at server location requirement 10 saying location from LLDP-MED format is translated to a PIDF-LO. There is no PIDF-LO element that could hold an ELIN. Concerning the time to wait for LLDP-MED: recommending the fast start-up-behaviour could reduce the time to wait. However, I think it is feasible to activate all ways to get location in parallel, and then use a defined order in case of multiple locations. karl heinz On Thu, Apr 24, 2008 at 4:53 PM, Stark, Barbara wrote: > James, > My document does have details for handling multiple locations. I don't > think there's any lack of guidance there (and it is the contents of the > DSL Forum document we're talking about, and not phonebcp). It says "The > device MAY allow configuration of the rules for ordering multiple > locations, and selecting the one to use for the LoST query and routing. > The recommended default order is LLDP-MED, DHCP, HELD, GPS, and manual." > I think this statement needs to be improved to make a default > recommendation in case other configuration mechanisms exist. > > But the guidance that phonebcp does supply is that a device should try > all location config protocols (LCPs), and that the device needs to be > able to handle multiple locations. So, I believe that the DSL Forum > document is consistent in this area, except that it doesn't recommend > proceeding with HELD, if there is success at the lower layers. I'll > probably change that to do HELD if the device got a LIS server URL via > DHCP. But I'm not sure of the benefits of doing public IP address > discovery, followed by LIS discovery through reverse DNS, followed by > HELD, if the device got location already. If others feel strongly that > HELD must always be attempted, then I'll consider changing that. > > So, do you disagree with the phonebcp recommendation to try all LCPs? If > you do, how long would you recommend waiting for LLDP-MED to timeout, in > case there is no LLDP server in the premises? What do you recommend to > address the concerns of people who want to try to make this location > config process as quick as possible? My approach was to do a step as > soon as possible, without waiting for other things to complete, instead > of using lots of timers and timeouts to make sure everything was purely > sequential. > > I'm also a bit confused about your pushback to my statement that LLDP > wouldn't be present in the majority of consumer scenarios. You say you > disagree with that statement. Does that mean you think it will be > present in the majority (over 50%) of consumer (residential) scenarios? > That's interesting. Are you aware of consumer-grade equipment that does > this today? I'm not, which is why I made that statement. I realize that > there are a number of consumers who do use high end equipment, either > because of their enterprise job, or their home-based business. But > statistics that I've seen suggest that this population is very small > compared to the population that uses low-end retail home routers. I > currently don't see any LLDP servers in my home in the near future. > Barbara > > > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Wednesday, April 23, 2008 4:30 PM > To: Stark, Barbara; Karl Heinz Wolf > Cc: ECRIT > Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv > > > > Barbara > > comments in-line > > At 01:12 PM 4/23/2008, Stark, Barbara wrote: > >Hi Karl Heinz, > >Thanks for reading it. > > > >I specifically removed the check for whether or not there was a > response > >from LLDP-MED. By removing that, the device no longer has to wait for > >LLDP-MED to timeout before initiating the DHCP. I'm assuming there will > >be no LLDP in the majority of consumer scenarios. > > however, LLDP-MED will likely be quite often in enterprise > situations, and understanding the level of spillover between the two > network environments (residential and enterprise -- not to mention > that there really isn't a clear-cut choice for the SMB market to > choose between these two, meaning they will come from either, > therefore both point products) -- I'm not sure I agree with this > opinion. > > >Not waiting makes > >things work faster. > > but could (possibly) result in receiving location from two sources. > Given the lack of guidance of what to do with more than one location > source (does the UA send both?') and what the receiver does with > receiving both (which *one* does it deem true (or truer) to use?). > > >In discussions with various people, we came to the > >conclusion that there was really no negative consequence to not waiting > >for LLDP-MED to either return a response or timeout. This is also > >consistent with phonebcp, which expresses a preference for trying all > >location configuration protocols. > > --------------- I deleted everything below this ------------------- > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 04:14:22 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2473A67A5; Tue, 13 May 2008 04:14:22 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C1B3A67A5 for ; Tue, 13 May 2008 04:14:20 -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 f6l+Top1x7tL for ; Tue, 13 May 2008 04:14:19 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 4BE893A65A6 for ; Tue, 13 May 2008 04:14:19 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.44) id 1JvsRf-0000Fk-To; Tue, 13 May 2008 07:13:24 -0400 Received: from [207.96.236.134] (helo=[192.168.3.100]) by relay.infoteck.qc.ca with esmtp (Exim 4.43) id 1JvsRa-0000FE-5Y; Tue, 13 May 2008 07:13:23 -0400 Message-Id: From: Francois Menard To: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 13 May 2008 07:13:18 -0400 References: X-Mailer: Apple Mail (2.919.2) Cc: ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org So that we may come prepared to this meeting, could you provide links to the latest specs, particularly the transmission of location by value from the end-point to the PSAP. F. On 13-May-08, at 2:58 AM, wrote: > Hi all, > > We would like to inform you that we are currently planning to > organize a > meeting with the 3GPP around August 2008. The main topic for our > discussion is the harmonization of the 3GPP and the IETF emergency > services architecture. > > We will distribute more details as soon as they are available. > > Ciao > Hannes & Marc > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Francois Menard fmenard@xittelecom.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 04:40:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1803A6C03; Tue, 13 May 2008 04:40:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B20343A6C03 for ; Tue, 13 May 2008 04:40:25 -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 U+ze3Z+aYoNT for ; Tue, 13 May 2008 04:40:24 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id C5A3B3A6BF4 for ; Tue, 13 May 2008 04:40:24 -0700 (PDT) Received: from [128.89.252.30] (helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jvsqy-0005zt-5z; Tue, 13 May 2008 07:39:34 -0400 Message-ID: <48297DE7.5000107@bbn.com> Date: Tue, 13 May 2008 07:39:19 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Francois Menard References: In-Reply-To: Cc: "" , ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Francois, I don't have a complete list, but to answer your specific question, location is transmitted by value from the endpoint to the PSAP in the SIP INVITE message using the mechanism described in draft-ietf-sip-location-conveyance. --Richard Francois Menard wrote: > So that we may come prepared to this meeting, could you provide links > to the latest specs, particularly the transmission of location by > value from the end-point to the PSAP. > > F. > > > On 13-May-08, at 2:58 AM, > wrote: > >> Hi all, >> >> We would like to inform you that we are currently planning to >> organize a >> meeting with the 3GPP around August 2008. The main topic for our >> discussion is the harmonization of the 3GPP and the IETF emergency >> services architecture. >> >> We will distribute more details as soon as they are available. >> >> Ciao >> Hannes & Marc >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > -- > Francois Menard > fmenard@xittelecom.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 ecrit-bounces@ietf.org Tue May 13 04:48:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC3C3A6C03; Tue, 13 May 2008 04:48:33 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D613A6C10 for ; Tue, 13 May 2008 04:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 YHhHYi2hZerx for ; Tue, 13 May 2008 04:48:26 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 556733A6C08 for ; Tue, 13 May 2008 04:46:34 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DBj2tq030020; Tue, 13 May 2008 14:45:18 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 14:45:02 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 14:45:02 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 14:45:02 +0300 Message-ID: In-Reply-To: <48297DE7.5000107@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Joint Meeting with the 3GPP Thread-Index: Aci07gs1084uf8btS+uXuNMOQb9/nwAAHphw References: <48297DE7.5000107@bbn.com> From: To: , X-OriginalArrivalTime: 13 May 2008 11:45:02.0085 (UTC) FILETIME=[C7696B50:01C8B4EE] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks Richard for responding. Additionally, I think a good start for the overall picture is the ECRIT framework and Phone BCP documents: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-04.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-05.txt I will ask Hannu to provide us with the latest 3GPP specifications. Ciao Hannes >-----Original Message----- >From: ext Richard Barnes [mailto:rbarnes@bbn.com] >Sent: 13 May, 2008 14:39 >To: Francois Menard >Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >Subject: Re: [Ecrit] Joint Meeting with the 3GPP > >Francois, > >I don't have a complete list, but to answer your specific >question, location is transmitted by value from the endpoint >to the PSAP in the SIP INVITE message using the mechanism >described in draft-ietf-sip-location-conveyance. > >--Richard > > > >Francois Menard wrote: >> So that we may come prepared to this meeting, could you >provide links >> to the latest specs, particularly the transmission of location by >> value from the end-point to the PSAP. >> >> F. >> >> >> On 13-May-08, at 2:58 AM, >> wrote: >> >>> Hi all, >>> >>> We would like to inform you that we are currently planning to >>> organize a meeting with the 3GPP around August 2008. The main topic >>> for our discussion is the harmonization of the 3GPP and the IETF >>> emergency services architecture. >>> >>> We will distribute more details as soon as they are available. >>> >>> Ciao >>> Hannes & Marc >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> -- >> Francois Menard >> fmenard@xittelecom.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 ecrit-bounces@ietf.org Tue May 13 06:48:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4784F28C2E6; Tue, 13 May 2008 06:48:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0406428C2E8 for ; Tue, 13 May 2008 06:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-1.750, 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 SlohzEQvgSyf for ; Tue, 13 May 2008 06:48:29 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id ACA3528C2E6 for ; Tue, 13 May 2008 06:48:28 -0700 (PDT) Received: from mgw-mx03.nokia.com (mgw-mx03.nokia.com [192.100.122.230]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DBrOQ3026613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 May 2008 14:53:25 +0300 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DBo5BB002782 for ; Tue, 13 May 2008 14:50:14 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 14:50:10 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 14:50:10 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 14:50:10 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Joint Meeting with the 3GPP Thread-Index: Aci0xs+n4p4X0MQFSwyEeoI65gafGQAKApFQ References: From: "hannes.tschofenig@nsn.com" To: , X-OriginalArrivalTime: 13 May 2008 11:50:10.0298 (UTC) FILETIME=[7F1EFDA0:01C8B4EF] X-Nokia-AV: Clean Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Since Dan Romascanu asked me, I should also mention the following few things. There was already a joint meeting with the 3GPP in July 2006. That meeting was labeled as "information sharing activity", i.e., it was not an official IETF meeting and hence the note well statement did not apply. The meeting was open to everyone. Meeting minutes, presentations etc. were made available to everyone (and they are still available). Based on what was discussed so far the upcoming meeting will have the same style but will be attached to a 3GPP meeting. I hope that this clarifies a bit. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext hannes.tschofenig@nsn.com >Sent: 13 May, 2008 09:59 >To: ecrit@ietf.org >Subject: [Ecrit] Joint Meeting with the 3GPP > >Hi all, > >We would like to inform you that we are currently planning to >organize a meeting with the 3GPP around August 2008. The main >topic for our discussion is the harmonization of the 3GPP and >the IETF emergency services architecture. > >We will distribute more details as soon as they are available. > >Ciao >Hannes & Marc > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 07:04:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74BE3A67EA; Tue, 13 May 2008 07:04:29 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0191D3A6815 for ; Tue, 13 May 2008 07:04:24 -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_46=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 ae3Qd4Y1Raci for ; Tue, 13 May 2008 07:04:21 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id B58DF3A65A6 for ; Tue, 13 May 2008 07:04:17 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.44) id 1Jvumq-0004td-Di; Tue, 13 May 2008 09:43:25 -0400 Received: from [205.151.16.4] (helo=itos) by relay.infoteck.qc.ca with esmtp (Exim 4.43) id 1Jvump-0004tR-0M; Tue, 13 May 2008 09:43:24 -0400 From: "Francois Menard" To: "'Richard Barnes'" References: <48297DE7.5000107@bbn.com> In-Reply-To: <48297DE7.5000107@bbn.com> Date: Tue, 13 May 2008 09:43:19 -0400 Organization: Xit telecom inc. Message-ID: <008a01c8b4ff$4e149110$ea3db330$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aci07gY9FyL7KUBPSBqNdXkLhfM8lwAEPrVQ Content-Language: fr-ca Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fmenard@xittelecom.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Does the spec calls for digitally signing the LbyV by the PSAP, such that the PSAP can recognize an LbyV as being signed by itself as dispatch-able (i.e. MSAG-VALID), msag=master street address guide. F. -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: 13 mai 2008 07:39 To: Francois Menard Cc: ; ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP Francois, I don't have a complete list, but to answer your specific question, location is transmitted by value from the endpoint to the PSAP in the SIP INVITE message using the mechanism described in draft-ietf-sip-location-conveyance. --Richard Francois Menard wrote: > So that we may come prepared to this meeting, could you provide links > to the latest specs, particularly the transmission of location by > value from the end-point to the PSAP. > > F. > > > On 13-May-08, at 2:58 AM, > wrote: > >> Hi all, >> >> We would like to inform you that we are currently planning to >> organize a >> meeting with the 3GPP around August 2008. The main topic for our >> discussion is the harmonization of the 3GPP and the IETF emergency >> services architecture. >> >> We will distribute more details as soon as they are available. >> >> Ciao >> Hannes & Marc >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > -- > Francois Menard > fmenard@xittelecom.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 ecrit-bounces@ietf.org Tue May 13 07:40:47 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DCC93A6BF4; Tue, 13 May 2008 07:40:47 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37783A6815 for ; Tue, 13 May 2008 07:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Alcf6NEibZh7 for ; Tue, 13 May 2008 07:40:42 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3C1D53A65A6 for ; Tue, 13 May 2008 07:40:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,479,1204531200"; d="scan'208";a="26682207" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 13 May 2008 07:39:44 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4DEdiP2027997 for ; Tue, 13 May 2008 07:39:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m4DEdiQQ025749 for ; Tue, 13 May 2008 14:39:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 07:39:27 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.235]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 07:39:27 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 May 2008 09:39:25 -0500 To: From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 13 May 2008 14:39:27.0560 (UTC) FILETIME=[25522C80:01C8B507] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=566; t=1210689584; x=1211553584; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=3A=20Next=20Steps |Sender:=20; bh=Zrh4rzGYDQc1xwLw7Kr8q1qoDi02onJw2nAmUIywXWk=; b=iGjiRAdAR9GaqReBe1JFHJRLs2JLbMdMgbi45GtcUBNYCEBs+9GwKOZi37 7RuJ70tLIkKuZI+VRl6O1vs5My1CeJVmH+6O0pg7pyTjfrHljj4RWYOL7Fqz edx3iYWpMuG/sKGfXYfaHdlWQl4A743oR7Ri0iVqW5pNKkWlGbIIs=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >Hi all, > >The chairs had a chat with our AD regarding the next steps with the >working group. Here is a short summary. > >It is OK for Jon to add the following documents to the charter of the >group: >* Location Hiding PS and Requirements What does Location Hiding really have to do with ECRIT when "Location" is Geopriv's charter? >Ciao >Hannes & Marc > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 07:51:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FED3A6C1F; Tue, 13 May 2008 07:51:30 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5BE3A67F7 for ; Tue, 13 May 2008 07:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 nwLLP2ufax3z for ; Tue, 13 May 2008 07:51:22 -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 536733A6C23 for ; Tue, 13 May 2008 07:51:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,480,1204531200"; d="scan'208";a="33251486" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 May 2008 07:50:43 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4DEohmd029325 for ; Tue, 13 May 2008 07:50:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4DEoh2E006759 for ; Tue, 13 May 2008 14:50:43 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.1830); Tue, 13 May 2008 07:50:43 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.235]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 07:50:42 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 May 2008 09:50:41 -0500 To: From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 13 May 2008 14:50:42.0959 (UTC) FILETIME=[B7E3E1F0:01C8B508] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=464; t=1210690243; x=1211554243; c=relaxed/simple; s=sjdkim2002; 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]=20Joint=20Meeting=20with=20the= 203GPP |Sender:=20; bh=1/GlckNFIiTWqtZKblkr3RwlJGria09AMi4P2Fwwhy8=; b=Pi4k/dYvgtLK8zMUK2sZL+0Tw7Zx0yDVLQpb+duVnDJBEql4mXnGahelt5 lUKiesNqeZy97BOZtAendrF/97WTbbbgWMOZK1XMTckp4OMIWW3/oDOnQgv4 dKfvP17gDW; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 06:50 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >Based on what was discussed so far the upcoming meeting will have the >same style but will be attached to a 3GPP meeting. "attached to a 3GPP meeting" sounds like you have a date and place in mind for the meeting. Care to share that with us (please)? Many of us have travel restrictions or limited budgets, and need to plan accordingly. >I hope that this clarifies a bit. > >Ciao >Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 07:54:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B4B3A6C1A; Tue, 13 May 2008 07:54:49 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890EA3A682D for ; Tue, 13 May 2008 07:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 sC6M8gFh980y for ; Tue, 13 May 2008 07:54:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 97F8C3A67F7 for ; Tue, 13 May 2008 07:54:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,479,1204531200"; d="scan'208";a="26686884" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 13 May 2008 07:46:56 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m4DEkupf009444; Tue, 13 May 2008 07:46:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4DEkunN009470; Tue, 13 May 2008 14:46:56 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.1830); Tue, 13 May 2008 07:46:55 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.235]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 07:46:55 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 May 2008 09:46:53 -0500 To: , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 13 May 2008 14:46:55.0493 (UTC) FILETIME=[304F5350:01C8B508] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1238; t=1210690016; x=1211554016; 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]=20Hum=3A=20draft-schulzrinne-ec rit-location-hiding-req |Sender:=20; bh=5FK7TToZ2jJBrYTiCGJixLr3sI+OQndGHTng6hQt5TQ=; b=mCgfXwTw5eyFE8AIV5pK32c7X1k5Wi9zsH968YT77vh9kQJaJ5mpTLyrO7 BEOw2zew4X2D+YTF+k2h7Dl5PHgdYelIqdZwz9ciArAl/hw4xVgijJZ6pdHX JsU9oIAfWE; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 02:09 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C8B4C8.52CB610A" > >Hi all, > >Henning gave a presentation about this draft at previous IETF >meetings. Although this is a controversal topic we believe it is >important to capture the problem statement and the requirements. >This document is NOT meant to capture solutions -- this is something >for future work. We would therefore like to confirm the hum on the >mailing list. If you have not stated your opinion or if you object >please let us know. I am opposed to anything that will enable or guide the ability of a user (or device on the user's behalf) to lie about where they are. A user should be able to increase their target area to the point of "I'm in Manhattan (or just New York, or just US, or just North America), instead of which street address I'm on" (i.e., reducing one's granularity or resolution). >Deadline for your response: 30 May 2008 > >Ciao >Hannes & Marc >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 07:58:56 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE0C23A6C27; Tue, 13 May 2008 07:58:56 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FFF028C2EB for ; Tue, 13 May 2008 07:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_46=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 qUv0CAwOUYgw for ; Tue, 13 May 2008 07:58:52 -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 0AB2128C2E5 for ; Tue, 13 May 2008 07:58:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,480,1204531200"; d="scan'208";a="98085180" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 May 2008 07:57:47 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4DEvlG6013076; Tue, 13 May 2008 07:57:47 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4DEvkMT014374; Tue, 13 May 2008 14:57:47 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 07:57:47 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.235]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 07:57:46 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 May 2008 09:57:44 -0500 To: fmenard@xittelecom.com From: "James M. Polk" In-Reply-To: <008a01c8b4ff$4e149110$ea3db330$@net> References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 13 May 2008 14:57:46.0949 (UTC) FILETIME=[B49B9F50:01C8B509] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2415; t=1210690667; x=1211554667; c=relaxed/simple; s=sjdkim2002; 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]=20LbyV=20and=20MSAG |Sender:=20; bh=Vw1gzHvtBhdhfJnb5vNtvBtbGTPggp01BLsRYUl6+YI=; b=Cvi9CFnM6MEiGqZMO4rKR1ViQwwGi+56vGDvOvRfk68e+1PgG8m+FN436d O33+Nr8M/M+KLbhRhE5uYEDERfl4Yef7e1KW4UBlIdTLsOTDKZ+c30gJTUiO YVhsi46b+7; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] LbyV and MSAG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:43 AM 5/13/2008, Francois Menard wrote: >Does the spec calls for digitally signing the LbyV by the PSAP, such that >the PSAP can recognize an LbyV as being signed by itself as dispatch-able >(i.e. MSAG-VALID), msag=master street address guide. no, there is no MSAG component or element within the LbyV. Location will become more than an emergency calling feature, and shouldn't be held up or bound to MSAG validation (and costs) for every location usage. Location can be transmitted by 12 of the 14 SIP request methods, including the INVITE, per http://tools.ietf.org/wg/sip/draft-ietf-sip-location-conveyance/ >F. > >-----Original Message----- >From: Richard Barnes [mailto:rbarnes@bbn.com] >Sent: 13 mai 2008 07:39 >To: Francois Menard >Cc: ; ecrit@ietf.org >Subject: Re: [Ecrit] Joint Meeting with the 3GPP > >Francois, > >I don't have a complete list, but to answer your specific question, >location is transmitted by value from the endpoint to the PSAP in the >SIP INVITE message using the mechanism described in >draft-ietf-sip-location-conveyance. > >--Richard > > > >Francois Menard wrote: > > So that we may come prepared to this meeting, could you provide links > > to the latest specs, particularly the transmission of location by > > value from the end-point to the PSAP. > > > > F. > > > > > > On 13-May-08, at 2:58 AM, > > > wrote: > > > >> Hi all, > >> > >> We would like to inform you that we are currently planning to > >> organize a > >> meeting with the 3GPP around August 2008. The main topic for our > >> discussion is the harmonization of the 3GPP and the IETF emergency > >> services architecture. > >> > >> We will distribute more details as soon as they are available. > >> > >> Ciao > >> Hannes & Marc > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > -- > > Francois Menard > > fmenard@xittelecom.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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 08:10:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B303A68B6; Tue, 13 May 2008 08:10:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483B43A68B6 for ; Tue, 13 May 2008 08:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[AWL=-0.304, 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 WSvlLRTHo+w6 for ; Tue, 13 May 2008 08:10:40 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 4A4693A67F7 for ; Tue, 13 May 2008 08:10:40 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jvw6o-00086z-HS; Tue, 13 May 2008 10:08:06 -0500 From: "Brian Rosen" To: "'James M. Polk'" , References: Date: Tue, 13 May 2008 11:08:08 -0400 Message-ID: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci1B1N6AL+v6O+fQ+evtbXK7M0rwQAA6IJg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It's a requirement peculiar to emergency services. Location must be provided (typically by regulation) for emergency calls, but not for other uses. We need a mechanism to restrict handing out of location to only the emergency case. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Tuesday, May 13, 2008 10:39 AM To: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >Hi all, > >The chairs had a chat with our AD regarding the next steps with the >working group. Here is a short summary. > >It is OK for Jon to add the following documents to the charter of the >group: >* Location Hiding PS and Requirements What does Location Hiding really have to do with ECRIT when "Location" is Geopriv's charter? >Ciao >Hannes & Marc > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 08:21:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF73D28C300; Tue, 13 May 2008 08:21:53 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703163A6C22 for ; Tue, 13 May 2008 08:21:51 -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 bQVPmYRWVknn for ; Tue, 13 May 2008 08:21:50 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 510D93A6C38 for ; Tue, 13 May 2008 08:18:37 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m4DFHuUP022595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 May 2008 11:17:56 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 13 May 2008 11:17:56 -0400 References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org As noted before, this is not a technical requirement. This also does not, in any way, benefit end users or make the Internet a better place. This is a maximizing-profit requirement for certain operators and thus differs from typical IETF requirements (at least the publicly stated ones...). On May 13, 2008, at 11:08 AM, Brian Rosen wrote: > It's a requirement peculiar to emergency services. Location must be > provided (typically by regulation) for emergency calls, but not for > other > uses. We need a mechanism to restrict handing out of location to > only the > emergency case. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 08:24:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736903A6C24; Tue, 13 May 2008 08:24:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6690728C2FB for ; Tue, 13 May 2008 08:24:16 -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 JbsE1Nz3jMBR for ; Tue, 13 May 2008 08:24:10 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 6329A3A67AE for ; Tue, 13 May 2008 08:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1210692250; x=1242228250; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<0c7701c8b50b$28af8b80$64 0fa8c0@cis.neustar.com>|References:=20=0D=0A=20=0D =0A=20<0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> |Date:=20Tue,=2013=20May=202008=2008:23:06=20-0700|To:=20 Brian=20Rosen=20,=20"'James=20M.=20Pol k'"=20,=0D=0A=20=20=20=20=20=20=20=20"e crit@ietf.org"=20|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20ECRIT: =20Next=20Steps|Content-Type:=20text/plain=3B=20charset =3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188 ,5293"=3B=20a=3D"2905791"; bh=hYwlwwhBYiikmoBTwmUSnzDLm5rCwG9VKfn8oUCCnto=; b=GsbnDEseMIfzCFqCFcG5itgdgACbPXbYA2mNWDJO7MjWccAQCZJVUYTw dorV4kCu9F+ti2+Jet+MY4xotwDDkL6kYfHgwBvYVoRfOX0L/NepZD/GK d3jMiyczk41mh1DBBuPGPfW8rrxXhQNzanh/tM980sxMfvdWx6XiBScIF Q=; X-IronPort-AV: E=McAfee;i="5100,188,5293"; a="2905791" 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; 13 May 2008 08:23:11 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4DFNAw8001589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 May 2008 08:23:11 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4DFNAFN024516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 May 2008 08:23:10 -0700 Received: from [24.4.239.115] (10.50.0.24) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.263.0; Tue, 13 May 2008 08:23:09 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> Date: Tue, 13 May 2008 08:23:06 -0700 To: Brian Rosen , "'James M. Polk'" , "ecrit@ietf.org" From: Ted Hardie Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 8:08 AM -0700 5/13/08, Brian Rosen wrote: >It's a requirement peculiar to emergency services. Location must be >provided (typically by regulation) for emergency calls, but not for other >uses. We need a mechanism to restrict handing out of location to only the >emergency case. > >Brian You top-posted away James' point, which is that GeoPRIV in general handles location issues. Though you are right that handing out location for emergency calls is mandated, there are lots of other cases where the location-seller wants to hand out location for a single app/purpose/instance and wants to get paid again for the next app/purpose/instance. Having an agreement on a common mechanism for that seems like better design for those that believe in the requirement than is having a design that kind-of works for emergencies and does not apply at all to other cases. Note that I think the requirement is, in general, completely bogus. It is handled trivially by allowing location-selleres that wish to be paid for location to charge for it for emergency use. That puts the problem squarely in the economic/regulatory realms (where it belongs) and leaves out stupid protocol tricks to get around it. I also fall into the camp of believing that location information is rapidly ceasing to be data valuable enough to charge for separately, but that is an argument for the Internet Economic Task Force, not this one. Color me opposed to the requirement and believing that if it is solved at all, it ought to be generally solved. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 09:09:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EAC13A6893; Tue, 13 May 2008 09:09:47 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72F93A6893 for ; Tue, 13 May 2008 09:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[AWL=-0.261, 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 H2Zgkq6qgwi8 for ; Tue, 13 May 2008 09:09:29 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 595BF3A67F7 for ; Tue, 13 May 2008 09:09:29 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jvx2j-0004oy-25; Tue, 13 May 2008 11:07:57 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Hannes Tschofenig'" , "'ECRIT'" References: <48287315.5080100@gmx.net> <0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com> Date: Tue, 13 May 2008 12:07:59 -0400 Message-ID: <0c8701c8b513$85091470$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoAAAz7mrAAH4ynQA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Snipped to deal with James' comments, with my responses in line > ED-5 is devices must recognize local dial strings. I believe 3GPP does > this. I don't know what 3GPP2 does. ED-5 is also SP-4. It's possible we > could water down this to say where the SP knows for certain where the > location of the devices is at all times, then it can handle the > recognition > of dial strings and not require the end device to do that. I'd rather not > do that. > [AJW] I think what is important is that the SP knows the what the user is intending. I think that in a great many case, a user plugging into a foreign network, but communicating back to a home SP will use home SP dial strings. I want to make sure we allow this for several reasons. The first is that it makes it MUCH easier for the SP to behave in a manner that the caller expects without the SP having to become aware of the location and associated call semantics associated with that environment. Secondly, like it or not, people are creatures of habit, they want to dial the same thing to get the same service no matter where they are. Yes, part 2 can be addressed with UI and device mapping stuff, but then you arrive at having to provide a solution for problem 1. Simply allowing the SP to know the service based on the notion of "home dial strings" avoids this whole can of worms.
Let's not start this again. Local dial strings are required. Home dial strings are optional. That's the way it works now, that's the way the PSAPs want it. You are speculating that home strings are a good idea. Whether I believe you or not doesn't matter. It doesn't work that way now although in GSM systems, 9-1-1 and 1-1-2 always work, so if those are your home strings you are in luck. It is unacceptable to require home dial strings in lieu of local dial strings. Since local strings are required, this requirement is necessary. > ED-12 Endpoints, Intermediate Devices and Service > Providers MUST be prepared to handle location represented in either > civic or geo form. > This is an interesting one. If the device knows it's on a mobile network > and always gets geo, what does this mean? Should we alter the text? What > do they actually do if the device is a dual WiFi/mobile and roams to a > WiFi > network that reports civic? > [AJW] With the introduction and deployment of femto cells I think that civic for 3GPP devices, at least packet-based devices is a reasonable thing. I think assuming geo here is a bit short-sighted. > ED-15 Devices, intermediate Devices and/or access networks > SHOULD support a manual method to "override" the location the access > network determines. > > It's a "should". This has always been a controversial requirement. We've > discussed the tradeoffs. You can argue for a known mobile device with a > network that knows it always using GPS wouldn't do this. Same question on > WiFi roaming. > [AJW] I am not a fan of this requirement, but its not a battle that I am prepared to put the energy into trying to win. At least on in this forum... ;) > ED-16 Devices MAY support end-system measured location. Its definitely a > MAY, but of course this is the usual 3GPP determination method (A-GPS) > [AJW] This seems an odd requirement for 3GPP2 to not support. I think that the priory solution deployed in these networks is MS-Assisted, but is there no MS-based deployed at all anywhere? > ED-17 Devices that support endpoint measuring of location > MUST have at least a coarse location capability (typically <1km > accuracy when not location hiding) at all times for routing of calls. > This mechanism MAY be a service provided by the access network. > They do this. Why are they complaining? > [AJW] I really hate the parenthetical as in many cellular cases, particularly for omni-cell systems this is not practical, and if it is for routing, it may not even be necessary. I think I have asked before for this to be removed, and if I haven't I am definitely and strongly asking now.
Because we have to provide some guidance. So, we did. "Typically" is guidance, and not a hard requirement. > ED-18 Endpoints SHOULD configure their own location > It's a SHOULD. Do 3GPP2 systems assume no fixed devices? In 3GPP, the > fixed devices are expected to do endpoint location configuration. Maybe > they haven't gotten to that point yet > [AJW] I think for your comment on 3GPP fixed solutions a clear document reference to this information very important for any response to 3GPP2. It isn't a requirement in 3GPP that I am aware of, so I wouldn't mind seeing it also.... ;)
TISPAN, now brought to you by 3GPP. I don't have the doc reference. Hannes? > ED-24 This is "supply an API to get location for apps that need it" > I think they are dead wrong. AIM on a 3GPP2 phone needs a location API. > [AJW] I think that this is going to be more of a handset and carrier issue. Handset vendors and handset OS definers need to make APIs available, certainly Android is doing this (though I don't like the level it is pitched at). Carrier need to make it possible for the necessary applications to get access this information in their networks, until now putting third-party applications on some network operator phones was essentially impossible. I am not sure that defining a standard API in 3GPP(2) is the right thing to do.
But isn't the text correct? There has to be a way. > ED-25 Endpoints SHOULD obtain location immediately after > obtaining local network configuration information > It's a should. I happen to think they should do this, but that's just me. > [AJW] This one I think just highlights the fundamental difference in assumed architectures. The Internet model is putting near total control at the end-point, 3GPP(2) still assumes that a single entity owns access and service, owns it by proxy using roaming agreements. The Internet model can work in the 2GPP(2) architecture, but the converse is not true. I think ultimately that the Internet model will prevail as roaming agreements and their associated complexities will drown under their own weight, but until that happens I think we need to accepts that not all network will make location available directly to the end-point when it attaches to the network.
Does text need to change? I don't think so. > ED-26 If the device is configured to use DHCP for > bootstrapping, it MUST include both options for location acquisition > (civic and geodetic), the option for LIS discovery, and the option > for LoST discovery > Huh? Since they don't support DHCP, this is a don't care > [AJW] Should just be not applicable then.
Right, no text change. > ED-37 For calls sent with location-by-reference, with a SIP or > SIPS scheme, the server resolving the reference MUST support a > SUBSCRIBE [RFC3265] to the presence event [RFC3856]. > Huh? So far, they aren't saying what they will support. It will have to > be > SIP or HELD in the U.S. > [AJW] At present I, and a number of other people, remain unconvinced that the current event packages and presence filter options for SIP meet the needs of subscribing for location in this way. We probably need to decide if we an a generic change of a specific one. I tend to think a specific one is better since I don't see an application outside of location at this point, so the "generic" component doesn't really have a point of reference.
I disagree, but since at present, all we have is 3856, that's what we cite. > ED-47 Endpoints MUST support one or more mechanisms that allow them > to determine their public IP address. > We may want to change this. If the device does LoST or LIS discovery, it > needs its IP address. If it doesn't do LIS or LoST discovery, it doesn't > need it. On the other hand, they have the AOL problem. They need a > solution for that, and it may be LIS and/or LoST discovery. > [AJW] LIS discovery does not always require you to know the external IP address. Similarly I don't believe that LoST discovery does either.
Some change is needed. The next requirement is LIS/LoST discovery. Perhaps we just drop the requirement and assume it's in ED-48, or perhaps we augment ED-48 to point out the potential need to get your own IP address. > ED-48 Endpoints MUST support LIS discovery as described in > [I-D.thomson-geopriv-lis-discovery], and the LoST discovery as > described in [I-D.ietf-ecrit-dhc-lost-discovery]. > Same as above > [AJW] Reference update to LIS discovery si required.
Okay > > SP-4 Local dial strings MUST be recognized > Can't have it both ways folks. Either the endpoint does it or the service > provider does it (see ED-5) > [AJW] See my note above.. I think you can definitely have it both ways. > SP-17 If a proxy is attempting to insert location but the UA conveyed > a location to it, the proxy MUST use the UA's location for routing > and MUST convey that location towards the PSAP. > I more or less understand them, but I disagree. I think they say that > they > insert location, and if an endpoint sends them location, they ignore it. > I > think they are wrong; if the endpoint says it's somewhere, you are best to > believe it. The network can add what it thinks the location is to the > call. > [AJW] A proxy can't insert location it goes against the rule in 3261. Either we change this to a location URI, or we change the text to say B2BUA, the term proxy is incorrect without a normative change to SIP.
I was assuming a proxy inserts a reference. I can change this easily enough. > SP-18 All location objects received by a proxy MUST be delivered to > the PSAP. > Again, I think this is incorrect. If the device sends location, it should > be sent to the PSAP. > [AJW] Delivered does not mean delivered in-band. I2, for example, would meet this requirement, but the location will not be sent to the PSAP in-band.
Are you arguing for a change in text? I don't think we need to. "Received by a proxy" is in-band. > > SP-34 Unitialized devices SHOULD have a persistent URI in a > P-Asserted-Identity: header if there is some way to assign such an > identifier to the device > This shouldn't be a problem. It's SHOULD, and it says "if possible". The > ability to call back an unitialized device is important. > [AJW] Uninitialized devices that have an IP address and general access to the Internet. I really hate this term because it so ambiguous as to what the device has rights to use. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 09:13:26 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6D33A68B6; Tue, 13 May 2008 09:13:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 509CE3A6893 for ; Tue, 13 May 2008 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 F4yegTMkRHSZ for ; Tue, 13 May 2008 09:13:16 -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 BF5683A6BF4 for ; Tue, 13 May 2008 09:13:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,480,1204531200"; d="scan'208";a="33287438" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 13 May 2008 09:11:22 -0700 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 m4DGBM0L005091; Tue, 13 May 2008 09:11:22 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.13.8/8.13.8) with SMTP id m4DGBMnR000749; Tue, 13 May 2008 16:11:22 GMT From: Cullen Jennings To: Brian Rosen In-Reply-To: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 13 May 2008 09:11:11 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1227; t=1210695082; x=1211559082; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=3A=20Next=20Steps |Sender:=20; bh=EsiIE2btKIneUeJck1EnXCU+Ja75hYX6CMk3nIkxrbI=; b=Dy0uNP1U3eaRsP8kXgVMyGVyF/hrpJUFDHBYgFzI4obgVIMQEJ3ylFMhZ/ sYkeHWtOCjHuijgdLNlfIyuAchOJ4ElSgOfzoMFSbp4vF2uPatCa5Ik/Bttt /sZKhFhD53; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I certainly understand ECRIT doing requirements here, but I was hoping the mechanisms geopriv was developing would be general enough to meet these needs. If not, that seems to indicate a pretty serious concern with the mechanisms. On May 13, 2008, at 8:08 AM, Brian Rosen wrote: > It's a requirement peculiar to emergency services. Location must be > provided (typically by regulation) for emergency calls, but not for > other > uses. We need a mechanism to restrict handing out of location to > only the > emergency case. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > James M. Polk > Sent: Tuesday, May 13, 2008 10:39 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT: Next Steps > > At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >> Hi all, >> >> The chairs had a chat with our AD regarding the next steps with the >> working group. Here is a short summary. >> >> It is OK for Jon to add the following documents to the charter of the >> group: >> * Location Hiding PS and Requirements > > What does Location Hiding really have to do with ECRIT when > "Location" is Geopriv's charter? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 10:17:06 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16C328C305; Tue, 13 May 2008 10:17:06 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5977C28C305 for ; Tue, 13 May 2008 10:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=-0.228, 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 vn96SDa3dLGS for ; Tue, 13 May 2008 10:17:03 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id CD71828C301 for ; Tue, 13 May 2008 10:17:02 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Jvy4W-0001A0-DJ; Tue, 13 May 2008 12:13:52 -0500 From: "Brian Rosen" To: "'Cullen Jennings'" References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> Date: Tue, 13 May 2008 13:13:54 -0400 Message-ID: <0ca201c8b51c$ba8095c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci1E/1g6Q/Jijr/SQehMRv8MFxFQwACK3/g In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a requirements doc. -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Tuesday, May 13, 2008 12:11 PM To: Brian Rosen Cc: 'James M. Polk'; ecrit@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps I certainly understand ECRIT doing requirements here, but I was hoping the mechanisms geopriv was developing would be general enough to meet these needs. If not, that seems to indicate a pretty serious concern with the mechanisms. On May 13, 2008, at 8:08 AM, Brian Rosen wrote: > It's a requirement peculiar to emergency services. Location must be > provided (typically by regulation) for emergency calls, but not for > other > uses. We need a mechanism to restrict handing out of location to > only the > emergency case. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf Of > James M. Polk > Sent: Tuesday, May 13, 2008 10:39 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT: Next Steps > > At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >> Hi all, >> >> The chairs had a chat with our AD regarding the next steps with the >> working group. Here is a short summary. >> >> It is OK for Jon to add the following documents to the charter of the >> group: >> * Location Hiding PS and Requirements > > What does Location Hiding really have to do with ECRIT when > "Location" is Geopriv's charter? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 10:37:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717DC3A687D; Tue, 13 May 2008 10:37:59 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC3F3A687D for ; Tue, 13 May 2008 10:37:58 -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_46=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 fqqmVwiNeaIZ for ; Tue, 13 May 2008 10:37:57 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A94293A6C4F for ; Tue, 13 May 2008 10:37:42 -0700 (PDT) Received: from dhcp33-081-019.bbn.com ([128.33.81.19] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JvyQh-0002ic-3m; Tue, 13 May 2008 13:36:47 -0400 Message-ID: <4829D1AD.1070905@bbn.com> Date: Tue, 13 May 2008 13:36:45 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: fmenard@xittelecom.com References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net> In-Reply-To: <008a01c8b4ff$4e149110$ea3db330$@net> Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Francois, Let me answer your question in three parts: 1. The spec allows the LbyV to be digitally signed. The location is carried as a MIME body in the SIP message, and thus can also be included in S/MIME form, signed, encrypted, or both. See Appendix B of draft-ietf-sip-location-conveyance-10 for an example. 2. The signer does not necessarily have to be the PSAP (though this is definitely allowed). In the model described in framework/phonebcp, the endpoint gets its location from a server in the access network to which it's connected, so when we talk about location signing, I usually imagine that it's signed by the access network's location server. However, if a PSAP wanted to, it could provide signed location objects to access networks in its jurisdiction that could then be handed out to endpoints, who would then send them back to the PSAP: +------------+ | PSAP |<------(3)--------+ +------------+ | | | (1) | | | V | +------------+ +----------+ | Access Net |----(2)----->| Endpoint | +------------+ +----------+ 3. The IETF has not defined anything directly analogous to the MSAG, in the sense of a consolidated database (in fact, I believe that the NENA i3 architecture does away with the MSAG entirely). However, there is a location validation function provided by the LoST protocol: There is no current standard way for a location to be marked as valid (this could be hard, since notions of validity vary from place to place), but a PSAP could easily verify that a location is valid using LoST. Cheers, --Richard Francois Menard wrote: > Does the spec calls for digitally signing the LbyV by the PSAP, such that > the PSAP can recognize an LbyV as being signed by itself as dispatch-able > (i.e. MSAG-VALID), msag=master street address guide. > > F. > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: 13 mai 2008 07:39 > To: Francois Menard > Cc: ; ecrit@ietf.org > Subject: Re: [Ecrit] Joint Meeting with the 3GPP > > Francois, > > I don't have a complete list, but to answer your specific question, > location is transmitted by value from the endpoint to the PSAP in the > SIP INVITE message using the mechanism described in > draft-ietf-sip-location-conveyance. > > --Richard > > > > Francois Menard wrote: >> So that we may come prepared to this meeting, could you provide links >> to the latest specs, particularly the transmission of location by >> value from the end-point to the PSAP. >> >> F. >> >> >> On 13-May-08, at 2:58 AM, > > > wrote: >> >>> Hi all, >>> >>> We would like to inform you that we are currently planning to >>> organize a >>> meeting with the 3GPP around August 2008. The main topic for our >>> discussion is the harmonization of the 3GPP and the IETF emergency >>> services architecture. >>> >>> We will distribute more details as soon as they are available. >>> >>> Ciao >>> Hannes & Marc >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> -- >> Francois Menard >> fmenard@xittelecom.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 ecrit-bounces@ietf.org Tue May 13 10:40:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3723D3A6836; Tue, 13 May 2008 10:40:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B262F3A6836 for ; Tue, 13 May 2008 10:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhiopOz4b5vp for ; Tue, 13 May 2008 10:40:19 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 30AFA3A6805 for ; Tue, 13 May 2008 10:40:19 -0700 (PDT) Received: from dhcp33-081-019.bbn.com ([128.33.81.19] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JvyT3-0002lO-4r; Tue, 13 May 2008 13:39:13 -0400 Message-ID: <4829D240.4020201@bbn.com> Date: Tue, 13 May 2008 13:39:12 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: hannes.tschofenig@nsn.com References: In-Reply-To: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I strongly support solving this problem. However I believe the problem is well-enough understood at this point that we should be driving toward solutions, not just documenting requirements. If we're going to add scope, that scope should include solutions in addition to requirements. So I hum in favor, with additional support for pursuing solutions as well. --Richard hannes.tschofenig@nsn.com wrote: > Hi all, > > Henning gave a presentation about this draft at previous IETF meetings. > Although this is a controversal topic we believe it is important to > capture the problem statement and the requirements. This document is NOT > meant to capture solutions -- this is something for future work. We > would therefore like to confirm the hum on the mailing list. If you have > not stated your opinion or if you object please let us know. > > Deadline for your response: 30 May 2008 > > Ciao > Hannes & Marc > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 10:54:17 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6C63A6BF3; Tue, 13 May 2008 10:54:17 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28F43A6C21 for ; Tue, 13 May 2008 10:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGjWhUKIjsCA for ; Tue, 13 May 2008 10:54:14 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7EC443A6BF3 for ; Tue, 13 May 2008 10:54:14 -0700 (PDT) Received: from dhcp33-081-019.bbn.com ([128.33.81.19] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jvyf7-000305-4Y; Tue, 13 May 2008 13:51:41 -0400 Message-ID: <4829D52C.6070803@bbn.com> Date: Tue, 13 May 2008 13:51:40 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Cullen Jennings References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> In-Reply-To: Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think that current and planned GEOPRIV mechanisms will be sufficient for providing selective access to location, but that's not the whole story. There's some sort of framework document called for here that describes how the location access mechanisms are used. This document is necessary because if different entities (callers, location providers, VSPs) make different assumptions about who is authorized and whose job it is to access location, then you can run into serious interoperability issues. If you look at the solution sketches on the wiki, they're not all interoperable with each other (i.e., if one entity behaves as if its in one scenario, and another another, then the call fails). Depending on what that framework looks like, there could be some ECRIT changes necessary in addition to describing how to use GEOPRIV mechanisms. For example, several of the solutions require a mechanism to discover an entity that's authorized to receive location. For emergency services, it seems to me that this would be an ECRIT function. If, as Ted suggests, there's a more general interest in discovering services that are authorized to use a given access-restricted location object, then it might be of interest in GEOPRIV. Note though that while LoST was developed in ECRIT, it has non-emergency use cases as well. --Richard Cullen Jennings wrote: > I certainly understand ECRIT doing requirements here, but I was hoping > the mechanisms geopriv was developing would be general enough to meet > these needs. If not, that seems to indicate a pretty serious concern > with the mechanisms. > > On May 13, 2008, at 8:08 AM, Brian Rosen wrote: > >> It's a requirement peculiar to emergency services. Location must be >> provided (typically by regulation) for emergency calls, but not for >> other >> uses. We need a mechanism to restrict handing out of location to >> only the >> emergency case. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of >> James M. Polk >> Sent: Tuesday, May 13, 2008 10:39 AM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT: Next Steps >> >> At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >>> Hi all, >>> >>> The chairs had a chat with our AD regarding the next steps with the >>> working group. Here is a short summary. >>> >>> It is OK for Jon to add the following documents to the charter of the >>> group: >>> * Location Hiding PS and Requirements >> What does Location Hiding really have to do with ECRIT when >> "Location" is Geopriv's charter? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 11:06:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82C63A67E9; Tue, 13 May 2008 11:06:01 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53DC3A67E9 for ; Tue, 13 May 2008 11:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 ACn9kpDbZzWA for ; Tue, 13 May 2008 11:05:59 -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 D8DFA3A67A4 for ; Tue, 13 May 2008 11:05:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,480,1204531200"; d="scan'208";a="46445983" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 13 May 2008 11:04:23 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4DI4LkK014520 for ; Tue, 13 May 2008 11:04:21 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4DI4Lep010938 for ; Tue, 13 May 2008 18:04:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 11:04:21 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.235]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 11:04:21 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 May 2008 13:04:20 -0500 To: From: "James M. Polk" In-Reply-To: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 13 May 2008 18:04:21.0286 (UTC) FILETIME=[C4F3E460:01C8B523] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1481; t=1210701861; x=1211565861; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20ECRIT=3A=20Next=20Steps |Sender:=20; bh=RwjPaQIBAXKs5FmoduQCv8GxE7n/7nNiV/O3KR/bDnA=; b=dGac7VzQK2bNjP8vWV+wV7/jDPnzDgsEet9EewPn9uYzl686cnjeRxHyGl T+OPDE+rWjjlEHRerP5ymfx6XakWJO9p+v3aLgiS303ki556yOAHbTqsoljm 5xA/e7GgR2B1Dbv/C++xZJOl+efZyg3xy784bF38JFnbbZEO0QYdU=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 10:08 AM 5/13/2008, Brian Rosen wrote: >It's a requirement peculiar to emergency services. Location must be >provided (typically by regulation) for emergency calls, but not for other >uses. We need a mechanism to restrict handing out of location to only the >emergency case. Isn't this a configuration choice? (and one I agree with BTW) Why do we need a mechanism? Diffserv is a mechanism. Shirley we don't need something like that to just say when and when not to include location. >Brian > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >James M. Polk >Sent: Tuesday, May 13, 2008 10:39 AM >To: ecrit@ietf.org >Subject: Re: [Ecrit] ECRIT: Next Steps > >At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: > >Hi all, > > > >The chairs had a chat with our AD regarding the next steps with the > >working group. Here is a short summary. > > > >It is OK for Jon to add the following documents to the charter of the > >group: > >* Location Hiding PS and Requirements > >What does Location Hiding really have to do with ECRIT when >"Location" is Geopriv's charter? > > >Ciao > >Hannes & Marc > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 11:15:40 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19613A67E9; Tue, 13 May 2008 11:15:40 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9513A6836 for ; Tue, 13 May 2008 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 A0q+YVAB1iwx for ; Tue, 13 May 2008 11:15:29 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D14603A67A4 for ; Tue, 13 May 2008 11:15:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,480,1204531200"; d="scan'208";a="67472712" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 13 May 2008 11:11:15 -0700 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 m4DIBFtb027710 for ; Tue, 13 May 2008 11:11:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m4DIBFN6027851 for ; Tue, 13 May 2008 18:11:15 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.1830); Tue, 13 May 2008 11:11:15 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.80.235]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 11:11:14 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 May 2008 13:11:13 -0500 To: From: "James M. Polk" In-Reply-To: <0ca201c8b51c$ba8095c0$640fa8c0@cis.neustar.com> References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> <0ca201c8b51c$ba8095c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 13 May 2008 18:11:15.0237 (UTC) FILETIME=[BBAFCD50:01C8B524] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1671; t=1210702275; x=1211566275; 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=3A=20Next=20Steps |Sender:=20; bh=4JLdlm1o9VXyXGUxJ3iWh8z0Q0hsmGrITWBWga46Dm8=; b=eRM7uO5/4QaSyMJb9UbcVkOeHnRBUeXAFBddLuaolVhcNJ6xIj2IsPv2RB NE01+2WvbdzDeEGbW1XOT8qyDLI7HZNgpLaMyTN1bgn25JUg1ji1e2qkgBMZ UOIuDpmLHW; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 12:13 PM 5/13/2008, Brian Rosen wrote: >This is a requirements doc. ...which lead to solution(s) being proposed before the requirements are even agreed to... >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] >Sent: Tuesday, May 13, 2008 12:11 PM >To: Brian Rosen >Cc: 'James M. Polk'; ecrit@ietf.org >Subject: Re: [Ecrit] ECRIT: Next Steps > > >I certainly understand ECRIT doing requirements here, but I was hoping >the mechanisms geopriv was developing would be general enough to meet >these needs. If not, that seems to indicate a pretty serious concern >with the mechanisms. > >On May 13, 2008, at 8:08 AM, Brian Rosen wrote: > > > It's a requirement peculiar to emergency services. Location must be > > provided (typically by regulation) for emergency calls, but not for > > other > > uses. We need a mechanism to restrict handing out of location to > > only the > > emergency case. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf Of > > James M. Polk > > Sent: Tuesday, May 13, 2008 10:39 AM > > To: ecrit@ietf.org > > Subject: Re: [Ecrit] ECRIT: Next Steps > > > > At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: > >> Hi all, > >> > >> The chairs had a chat with our AD regarding the next steps with the > >> working group. Here is a short summary. > >> > >> It is OK for Jon to add the following documents to the charter of the > >> group: > >> * Location Hiding PS and Requirements > > > > What does Location Hiding really have to do with ECRIT when > > "Location" is Geopriv's charter? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 11:31:02 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E07A3A6809; Tue, 13 May 2008 11:31:02 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3014C3A6809 for ; Tue, 13 May 2008 11:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=-0.203, 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 06131vvzZ1Fh for ; Tue, 13 May 2008 11:30:58 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 9C8FF3A67E9 for ; Tue, 13 May 2008 11:30:58 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JvzCk-0001ga-Cq; Tue, 13 May 2008 13:26:26 -0500 From: "Brian Rosen" To: "'James M. Polk'" , References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com><0ca201c8b51c$ba8095c0$640fa8c0@cis.neustar.com> Date: Tue, 13 May 2008 14:26:23 -0400 Message-ID: <0cc401c8b526$daea6c00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci1JVqwLYObxHx6R3CIh38kHXf/ngAAVcqw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Actually, the solutions preceded the requirements work, and we correctly decided to first agree on requirements before we specified mechanisms. This is a request to work on requirements. It's appropriate in ecrit I believe. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Tuesday, May 13, 2008 2:11 PM To: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps At 12:13 PM 5/13/2008, Brian Rosen wrote: >This is a requirements doc. ...which lead to solution(s) being proposed before the requirements are even agreed to... >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] >Sent: Tuesday, May 13, 2008 12:11 PM >To: Brian Rosen >Cc: 'James M. Polk'; ecrit@ietf.org >Subject: Re: [Ecrit] ECRIT: Next Steps > > >I certainly understand ECRIT doing requirements here, but I was hoping >the mechanisms geopriv was developing would be general enough to meet >these needs. If not, that seems to indicate a pretty serious concern >with the mechanisms. > >On May 13, 2008, at 8:08 AM, Brian Rosen wrote: > > > It's a requirement peculiar to emergency services. Location must be > > provided (typically by regulation) for emergency calls, but not for > > other > > uses. We need a mechanism to restrict handing out of location to > > only the > > emergency case. > > > > Brian > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf Of > > James M. Polk > > Sent: Tuesday, May 13, 2008 10:39 AM > > To: ecrit@ietf.org > > Subject: Re: [Ecrit] ECRIT: Next Steps > > > > At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: > >> Hi all, > >> > >> The chairs had a chat with our AD regarding the next steps with the > >> working group. Here is a short summary. > >> > >> It is OK for Jon to add the following documents to the charter of the > >> group: > >> * Location Hiding PS and Requirements > > > > What does Location Hiding really have to do with ECRIT when > > "Location" is Geopriv's charter? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 11:46:10 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA87A3A6937; Tue, 13 May 2008 11:46:10 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA693A6936 for ; Tue, 13 May 2008 11:46:08 -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 38H-aG85iVxf for ; Tue, 13 May 2008 11:46:07 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5BE143A6935 for ; Tue, 13 May 2008 11:46:07 -0700 (PDT) Received: from dhcp33-081-019.bbn.com ([128.33.81.19] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jvyk5-00034h-4u; Tue, 13 May 2008 13:56:49 -0400 Message-ID: <4829D660.3030006@bbn.com> Date: Tue, 13 May 2008 13:56:48 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "James M. Polk" References: In-Reply-To: Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, I'm confused. As I see it, location hiding doesn't do anything to encourage or discourage endpoints lying about their location. If anything, it denies them information from which to diverge -- at worst, it forces them to guess about their location (for non-emergency services). It doesn't give them a basis of truth from which to generate falsehood. Could you explain your concern? --Richard James M. Polk wrote: > At 02:09 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >> Content-class: urn:content-classes:message >> Content-Type: multipart/alternative; >> boundary="----_=_NextPart_001_01C8B4C8.52CB610A" >> >> Hi all, >> >> Henning gave a presentation about this draft at previous IETF >> meetings. Although this is a controversal topic we believe it is >> important to capture the problem statement and the requirements. >> This document is NOT meant to capture solutions -- this is something >> for future work. We would therefore like to confirm the hum on the >> mailing list. If you have not stated your opinion or if you object >> please let us know. > > I am opposed to anything that will enable or guide the ability of a > user (or device on the user's behalf) to lie about where they are. A > user should be able to increase their target area to the point of > "I'm in Manhattan (or just New York, or just US, or just North > America), instead of which street address I'm on" (i.e., reducing > one's granularity or resolution). > > >> Deadline for your response: 30 May 2008 >> >> Ciao >> Hannes & Marc >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 12:19:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD54F3A68B3; Tue, 13 May 2008 12:19:46 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173E63A6890 for ; Tue, 13 May 2008 12:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.445, 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 DaMtG3F+fkoM for ; Tue, 13 May 2008 12:19:44 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1B47C3A67A4 for ; Tue, 13 May 2008 12:19:43 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJGb1d016410; Tue, 13 May 2008 14:17:20 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:17:18 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:17:17 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 22:17:23 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Joint Meeting with the 3GPP Thread-Index: Aci1CNn5PtfJ9D9ZQZC5Ssad+TiPsgAJM16A References: From: To: , X-OriginalArrivalTime: 13 May 2008 19:17:17.0994 (UTC) FILETIME=[F5AC88A0:01C8B52D] X-Nokia-AV: Clean Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Actually, Hannu Hietalahti promised to discuss this with other 3GPP folks during the next 2 weeks. Then, he will tell us. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext James M. Polk >Sent: 13 May, 2008 17:51 >To: ecrit@ietf.org >Subject: Re: [Ecrit] Joint Meeting with the 3GPP > >At 06:50 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >>Based on what was discussed so far the upcoming meeting will have the >>same style but will be attached to a 3GPP meeting. > >"attached to a 3GPP meeting" sounds like you have a date and >place in mind for the meeting. Care to share that with us >(please)? Many of us have travel restrictions or limited >budgets, and need to plan accordingly. > > >>I hope that this clarifies a bit. >> >>Ciao >>Hannes > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 12:47:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993333A68B3; Tue, 13 May 2008 12:47:04 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0AB63A68B3 for ; Tue, 13 May 2008 12:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 BOZ09S7K+P2j for ; Tue, 13 May 2008 12:47:01 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id DC48E3A6880 for ; Tue, 13 May 2008 12:47:00 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJfnvf006646; Tue, 13 May 2008 14:44:07 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:43:54 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:43:53 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 22:43:53 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT: Next Steps Thread-Index: Aci1FEqJj+ZNQpEsT9mSUJNuYsEwMAAG01jQ References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> From: To: , X-OriginalArrivalTime: 13 May 2008 19:43:53.0901 (UTC) FILETIME=[ACE89DD0:01C8B531] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Cullen, >I certainly understand ECRIT doing requirements here, but I >was hoping the mechanisms geopriv was developing would be >general enough to meet these needs. If not, that seems to >indicate a pretty serious concern with the mechanisms. Our discussions focused on emergency services. I don't think that the discussion makes a lot of sense outside the emergency services space. The current PS and requirements / design goal document does not address solutions. It documents the discussions we had. Ciao Hannes > >On May 13, 2008, at 8:08 AM, Brian Rosen wrote: > >> It's a requirement peculiar to emergency services. Location must be >> provided (typically by regulation) for emergency calls, but not for >> other uses. We need a mechanism to restrict handing out of location >> to only the emergency case. >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of James M. Polk >> Sent: Tuesday, May 13, 2008 10:39 AM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT: Next Steps >> >> At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >>> Hi all, >>> >>> The chairs had a chat with our AD regarding the next steps with the >>> working group. Here is a short summary. >>> >>> It is OK for Jon to add the following documents to the >charter of the >>> group: >>> * Location Hiding PS and Requirements >> >> What does Location Hiding really have to do with ECRIT when >"Location" >> is Geopriv's charter? > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 12:48:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4291B3A6921; Tue, 13 May 2008 12:48:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76FE3A6921 for ; Tue, 13 May 2008 12:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, J_CHICKENPOX_46=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 0vFRl4Uuebzg for ; Tue, 13 May 2008 12:48:48 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 529F63A6890 for ; Tue, 13 May 2008 12:48:48 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJki96004112; Tue, 13 May 2008 22:47:02 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:45:21 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:45:21 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 22:45:20 +0300 Message-ID: In-Reply-To: <4829D1AD.1070905@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Joint Meeting with the 3GPP Thread-Index: Aci1H+8K0ee7uMxIQU+zrT1gyzYslQAEeeZQ References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net> <4829D1AD.1070905@bbn.com> From: To: , X-OriginalArrivalTime: 13 May 2008 19:45:21.0577 (UTC) FILETIME=[E12AE990:01C8B531] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org We did not agree todo anything close to (2). >-----Original Message----- >From: ext Richard Barnes [mailto:rbarnes@bbn.com] >Sent: 13 May, 2008 20:37 >To: fmenard@xittelecom.com >Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >Subject: Re: [Ecrit] Joint Meeting with the 3GPP > >Francois, > >Let me answer your question in three parts: > >1. The spec allows the LbyV to be digitally signed. The >location is carried as a MIME body in the SIP message, and >thus can also be included in S/MIME form, signed, encrypted, >or both. See Appendix B of >draft-ietf-sip-location-conveyance-10 for an example. >10#appendix-B> > >2. The signer does not necessarily have to be the PSAP (though >this is definitely allowed). In the model described in >framework/phonebcp, the endpoint gets its location from a >server in the access network to which it's connected, so when >we talk about location signing, I usually imagine that it's >signed by the access network's location server. >However, if a PSAP wanted to, it could provide signed location >objects to access networks in its jurisdiction that could then >be handed out to endpoints, who would then send them back to the PSAP: > >+------------+ >| PSAP |<------(3)--------+ >+------------+ | > | | > (1) | > | | > V | >+------------+ +----------+ >| Access Net |----(2)----->| Endpoint | >+------------+ +----------+ > >3. The IETF has not defined anything directly analogous to the >MSAG, in the sense of a consolidated database (in fact, I >believe that the NENA >i3 architecture does away with the MSAG entirely). However, >there is a location validation function provided by the LoST protocol: > >There is no current standard way for a location to be marked >as valid (this could be hard, since notions of validity vary >from place to place), but a PSAP could easily verify that a >location is valid using LoST. > >Cheers, >--Richard > > > > > > > >Francois Menard wrote: >> Does the spec calls for digitally signing the LbyV by the PSAP, such >> that the PSAP can recognize an LbyV as being signed by itself as >> dispatch-able (i.e. MSAG-VALID), msag=master street address guide. >> >> F. >> >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: 13 mai 2008 07:39 >> To: Francois Menard >> Cc: ; ecrit@ietf.org >> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >> >> Francois, >> >> I don't have a complete list, but to answer your specific question, >> location is transmitted by value from the endpoint to the >PSAP in the >> SIP INVITE message using the mechanism described in >> draft-ietf-sip-location-conveyance. >> >> --Richard >> >> >> >> Francois Menard wrote: >>> So that we may come prepared to this meeting, could you >provide links >>> to the latest specs, particularly the transmission of location by >>> value from the end-point to the PSAP. >>> >>> F. >>> >>> >>> On 13-May-08, at 2:58 AM, >> >> > wrote: >>> >>>> Hi all, >>>> >>>> We would like to inform you that we are currently planning to >>>> organize a meeting with the 3GPP around August 2008. The >main topic >>>> for our discussion is the harmonization of the 3GPP and the IETF >>>> emergency services architecture. >>>> >>>> We will distribute more details as soon as they are available. >>>> >>>> Ciao >>>> Hannes & Marc >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> -- >>> Francois Menard >>> fmenard@xittelecom.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 ecrit-bounces@ietf.org Tue May 13 12:49:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728A43A68F2; Tue, 13 May 2008 12:49:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077523A68F2 for ; Tue, 13 May 2008 12:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 ytQhQ3GUj8Fe for ; Tue, 13 May 2008 12:49:42 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CB0683A6890 for ; Tue, 13 May 2008 12:49:41 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJmOuL032166; Tue, 13 May 2008 22:48:33 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:48:30 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:48:29 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 22:48:28 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT: Next Steps Thread-Index: Aci1JVzjOck9lBWuRFasdm9h35KH4QADLf6Q References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com><0ca201c8b51c$ba8095c0$640fa8c0@cis.neustar.com> From: To: , X-OriginalArrivalTime: 13 May 2008 19:48:29.0775 (UTC) FILETIME=[5157A5F0:01C8B532] X-Nokia-AV: Clean Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It always happen that people propose solutions before the requirements work is finished. At least in the IETF this is quite common. In fact, I would even argue that working on strawman proposals at the same time as you work on requirements is a good thing since otherwise you might get a lot of surprises later on because the requirements are unrealistic. In general, you cannot prevent someone from thinking ahead.... >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext James M. Polk >Sent: 13 May, 2008 21:11 >To: ecrit@ietf.org >Subject: Re: [Ecrit] ECRIT: Next Steps > >At 12:13 PM 5/13/2008, Brian Rosen wrote: >>This is a requirements doc. > >...which lead to solution(s) being proposed before the >requirements are even agreed to... > > >>-----Original Message----- >>From: Cullen Jennings [mailto:fluffy@cisco.com] >>Sent: Tuesday, May 13, 2008 12:11 PM >>To: Brian Rosen >>Cc: 'James M. Polk'; ecrit@ietf.org >>Subject: Re: [Ecrit] ECRIT: Next Steps >> >> >>I certainly understand ECRIT doing requirements here, but I was hoping >>the mechanisms geopriv was developing would be general enough to meet >>these needs. If not, that seems to indicate a pretty serious concern >>with the mechanisms. >> >>On May 13, 2008, at 8:08 AM, Brian Rosen wrote: >> >> > It's a requirement peculiar to emergency services. >Location must be >> > provided (typically by regulation) for emergency calls, but not for >> > other >> > uses. We need a mechanism to restrict handing out of location to >> > only the >> > emergency case. >> > >> > Brian >> > >> > -----Original Message----- >> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> > Behalf Of >> > James M. Polk >> > Sent: Tuesday, May 13, 2008 10:39 AM >> > To: ecrit@ietf.org >> > Subject: Re: [Ecrit] ECRIT: Next Steps >> > >> > At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >> >> Hi all, >> >> >> >> The chairs had a chat with our AD regarding the next >steps with the >> >> working group. Here is a short summary. >> >> >> >> It is OK for Jon to add the following documents to the >charter of the >> >> group: >> >> * Location Hiding PS and Requirements >> > >> > What does Location Hiding really have to do with ECRIT when >> > "Location" is Geopriv's charter? > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 12:50:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6263A6921; Tue, 13 May 2008 12:50:01 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019673A6935 for ; Tue, 13 May 2008 12:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 6jNZG3-qQ--b for ; Tue, 13 May 2008 12:49:58 -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 241163A68F2 for ; Tue, 13 May 2008 12:49:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,481,1204531200"; d="scan'208";a="46486944" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 13 May 2008 12:48:17 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4DJmHEA005455; Tue, 13 May 2008 12:48:17 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.13.8/8.13.8) with SMTP id m4DJmGoj006183; Tue, 13 May 2008 19:48:16 GMT From: Cullen Jennings To: "" In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> Message-Id: <8298B117-2B1C-4166-B87D-172A4049EC49@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 13 May 2008 12:48:06 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1991; t=1210708097; x=1211572097; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=3A=20Next=20Steps |Sender:=20; bh=nAWNOX1gWn5LJovhz8fnO5rm7pjfQRX10eLw5JMwe7g=; b=qHUb/NjVGFCsXHIig01mLe/H6aeZ67Yp1tEozASJmnETDrbKuRu7OmulU+ 6SjCeZ5kbgjQLrriqaeQP1svfm+IszLXs3MSS5rIouQ1HiRu/YKaCBKwbBkr dlol7TBT0kIskONF4QsF+IFugebehCzq9brNTJyxuz+itdG+ZY5FQ=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think I was just confused on what "PS" means. What does it mean here? On May 13, 2008, at 12:43 PM, wrote: > Hi Cullen, > > >I certainly understand ECRIT doing requirements here, but I > >was hoping the mechanisms geopriv was developing would be > >general enough to meet these needs. If not, that seems to > >indicate a pretty serious concern with the mechanisms. > > Our discussions focused on emergency services. I don't think that the > discussion makes a lot of sense outside the emergency services space. > > The current PS and requirements / design goal document does not > address > solutions. It documents the discussions we had. > > > Ciao > Hannes > > > > >On May 13, 2008, at 8:08 AM, Brian Rosen wrote: > > > >> It's a requirement peculiar to emergency services. Location must > be > >> provided (typically by regulation) for emergency calls, but not for > >> other uses. We need a mechanism to restrict handing out of > location > >> to only the emergency case. > >> > >> Brian > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >On Behalf > >> Of James M. Polk > >> Sent: Tuesday, May 13, 2008 10:39 AM > >> To: ecrit@ietf.org > >> Subject: Re: [Ecrit] ECRIT: Next Steps > >> > >> At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: > >>> Hi all, > >>> > >>> The chairs had a chat with our AD regarding the next steps with > the > >>> working group. Here is a short summary. > >>> > >>> It is OK for Jon to add the following documents to the > >charter of the > >>> group: > >>> * Location Hiding PS and Requirements > >> > >> What does Location Hiding really have to do with ECRIT when > >"Location" > >> is Geopriv's charter? > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 12:58:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01BC3A683B; Tue, 13 May 2008 12:58:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533B63A683B for ; Tue, 13 May 2008 12:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.268 X-Spam-Level: X-Spam-Status: No, score=-4.268 tagged_above=-999 required=5 tests=[AWL=-1.669, 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 KmZakdLG-yP9 for ; Tue, 13 May 2008 12:58:10 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id D64B73A67AE for ; Tue, 13 May 2008 12:58:09 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJtUVq002852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 May 2008 22:55:32 +0300 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJpXI8015713; Tue, 13 May 2008 14:52:03 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:52:01 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:52:00 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 22:51:59 +0300 Message-ID: In-Reply-To: <8298B117-2B1C-4166-B87D-172A4049EC49@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT: Next Steps Thread-Index: Aci1Mk+nBuD+yI5JTouWSHeh0hhhVwAAFFPw References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> <8298B117-2B1C-4166-B87D-172A4049EC49@cisco.com> From: "hannes.tschofenig@nsn.com" To: X-OriginalArrivalTime: 13 May 2008 19:52:00.0954 (UTC) FILETIME=[CF3701A0:01C8B532] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Oh. I should have spelled it out. That can easily be confused with Proposed Standard. Sorry. Was meant to mean "Problem Statement" >-----Original Message----- >From: ext Cullen Jennings [mailto:fluffy@cisco.com] >Sent: 13 May, 2008 22:48 >To: Tschofenig Hannes (NSN - FI/Espoo) >Cc: br@brianrosen.net; ecrit@ietf.org >Subject: Re: [Ecrit] ECRIT: Next Steps > > >I think I was just confused on what "PS" means. What does it mean here? > > >On May 13, 2008, at 12:43 PM, > wrote: > >> Hi Cullen, >> >> >I certainly understand ECRIT doing requirements here, but I was >> >hoping the mechanisms geopriv was developing would be >general enough >> >to meet these needs. If not, that seems to indicate a >pretty serious >> >concern with the mechanisms. >> >> Our discussions focused on emergency services. I don't think >that the >> discussion makes a lot of sense outside the emergency services space. >> >> The current PS and requirements / design goal document does not >> address solutions. It documents the discussions we had. >> >> >> Ciao >> Hannes >> >> > >> >On May 13, 2008, at 8:08 AM, Brian Rosen wrote: >> > >> >> It's a requirement peculiar to emergency services. Location must >> be >> >> provided (typically by regulation) for emergency calls, >but not for >> >> other uses. We need a mechanism to restrict handing out of >> location >> >> to only the emergency case. >> >> >> >> Brian >> >> >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> >On Behalf >> >> Of James M. Polk >> >> Sent: Tuesday, May 13, 2008 10:39 AM >> >> To: ecrit@ietf.org >> >> Subject: Re: [Ecrit] ECRIT: Next Steps >> >> >> >> At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >> >>> Hi all, >> >>> >> >>> The chairs had a chat with our AD regarding the next steps with >> the >> >>> working group. Here is a short summary. >> >>> >> >>> It is OK for Jon to add the following documents to the >> >charter of the >> >>> group: >> >>> * Location Hiding PS and Requirements >> >> >> >> What does Location Hiding really have to do with ECRIT when >> >"Location" >> >> is Geopriv's charter? >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit >> > >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 13:05:55 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC2A3A6937; Tue, 13 May 2008 13:05:55 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FD343A6937 for ; Tue, 13 May 2008 13:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 7v9bHKh2ZGnH for ; Tue, 13 May 2008 13:05:38 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 18D193A6923 for ; Tue, 13 May 2008 13:05:38 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JvwAr-0000B9-3u; Tue, 13 May 2008 10:12:17 -0500 From: "Brian Rosen" To: "'James M. Polk'" , , References: Date: Tue, 13 May 2008 11:12:18 -0400 Message-ID: <0c7801c8b50b$be10aa10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci1CUlZ/vUPZGucRIWYVLl9bMnNHwAAecNQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At least one proposed way to do this works that way; you return a location accurate enough to get the right route out of LoST, but otherwise a large area polygon (or some equivalent civic). A user or a device can always lie. Actually, that is a significant problem for emergency services, and many of us want location signing, or some other way to assure that the location obtained from a LIS via a device is at the very least, a real ("MSAG valid", although that's not what we really mean any more) address. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Tuesday, May 13, 2008 10:47 AM To: hannes.tschofenig@nsn.com; ecrit@ietf.org Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req At 02:09 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C8B4C8.52CB610A" > >Hi all, > >Henning gave a presentation about this draft at previous IETF >meetings. Although this is a controversal topic we believe it is >important to capture the problem statement and the requirements. >This document is NOT meant to capture solutions -- this is something >for future work. We would therefore like to confirm the hum on the >mailing list. If you have not stated your opinion or if you object >please let us know. I am opposed to anything that will enable or guide the ability of a user (or device on the user's behalf) to lie about where they are. A user should be able to increase their target area to the point of "I'm in Manhattan (or just New York, or just US, or just North America), instead of which street address I'm on" (i.e., reducing one's granularity or resolution). >Deadline for your response: 30 May 2008 > >Ciao >Hannes & Marc >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 13:58:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED30F3A68D4; Tue, 13 May 2008 13:58:03 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3E23A68D4 for ; Tue, 13 May 2008 13:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[AWL=-1.550, 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 JTRkGNFFYZey for ; Tue, 13 May 2008 13:58:01 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id C18DC3A67ED for ; Tue, 13 May 2008 13:58:00 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DK3C2a008892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 May 2008 23:03:14 +0300 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJwr1S021872; Tue, 13 May 2008 15:00:00 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 23:00:00 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:59:59 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 22:59:57 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT: Next Steps Thread-Index: Aci1JAOmKCwKUrEIQwWPWD1YRPUISwAD6N2w References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> From: "hannes.tschofenig@nsn.com" To: , X-OriginalArrivalTime: 13 May 2008 19:59:59.0753 (UTC) FILETIME=[EC99EF90:01C8B533] X-Nokia-AV: Clean Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It seems that you have skipped our tough location hiding discussion. Lucky you! This might be a good basis to read the requirements and problem statement draft in order to tell us whether we captured the discussion in a reasonable fashion. Do you volunteer? >At 10:08 AM 5/13/2008, Brian Rosen wrote: >>It's a requirement peculiar to emergency services. Location must be >>provided (typically by regulation) for emergency calls, but not for >>other uses. We need a mechanism to restrict handing out of >location to >>only the emergency case. > >Isn't this a configuration choice? (and one I agree with BTW) > >Why do we need a mechanism? > >Diffserv is a mechanism. Shirley we don't need something like >that to just say when and when not to include location. > > >>Brian >> >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of >>James M. Polk >>Sent: Tuesday, May 13, 2008 10:39 AM >>To: ecrit@ietf.org >>Subject: Re: [Ecrit] ECRIT: Next Steps >> >>At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >> >Hi all, >> > >> >The chairs had a chat with our AD regarding the next steps with the >> >working group. Here is a short summary. >> > >> >It is OK for Jon to add the following documents to the >charter of the >> >group: >> >* Location Hiding PS and Requirements >> >>What does Location Hiding really have to do with ECRIT when >>"Location" is Geopriv's charter? >> >> >Ciao >> >Hannes & Marc >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 14:51:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E02BF3A6942; Tue, 13 May 2008 14:51:49 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D72A3A6942 for ; Tue, 13 May 2008 14:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.046 X-Spam-Level: X-Spam-Status: No, score=-4.046 tagged_above=-999 required=5 tests=[AWL=-1.447, 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 Fxo7Qc8c-iIx for ; Tue, 13 May 2008 14:51:46 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 79EF93A67E9 for ; Tue, 13 May 2008 14:51:46 -0700 (PDT) Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJHqbd004387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 May 2008 22:17:53 +0300 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJELGb008304; Tue, 13 May 2008 22:14:35 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:13:14 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:13:14 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 22:13:19 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT: Next Steps Thread-Index: Aci1B16LXPHOxlDWQzKiHIx761QD7AAJelAg References: From: "hannes.tschofenig@nsn.com" To: , X-OriginalArrivalTime: 13 May 2008 19:13:14.0639 (UTC) FILETIME=[649F81F0:01C8B52D] X-Nokia-AV: Clean Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org "Location Hiding" was just the name of the topic under which the discussion took place. Everyone knows what is meant with it >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext James M. Polk >Sent: 13 May, 2008 17:39 >To: ecrit@ietf.org >Subject: Re: [Ecrit] ECRIT: Next Steps > >At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >>Hi all, >> >>The chairs had a chat with our AD regarding the next steps with the >>working group. Here is a short summary. >> >>It is OK for Jon to add the following documents to the charter of the >>group: >>* Location Hiding PS and Requirements > >What does Location Hiding really have to do with ECRIT when >"Location" is Geopriv's charter? > >>Ciao >>Hannes & Marc >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 15:06:42 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F098D3A685D; Tue, 13 May 2008 15:06:41 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F0743A685D for ; Tue, 13 May 2008 15:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.955 X-Spam-Level: X-Spam-Status: No, score=-3.955 tagged_above=-999 required=5 tests=[AWL=-1.356, 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 JiTD66ziES7n for ; Tue, 13 May 2008 15:06:39 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 0B86A3A67E9 for ; Tue, 13 May 2008 15:06:38 -0700 (PDT) Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJHmMM004357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 May 2008 22:17:49 +0300 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4DJECfd007986; Tue, 13 May 2008 22:14:36 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:14:12 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 22:14:11 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 22:14:17 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req Thread-Index: Aci1CDd1n9j7KGufRoW5JmY+mcMyLAAJT4Ag References: From: "hannes.tschofenig@nsn.com" To: , X-OriginalArrivalTime: 13 May 2008 19:14:11.0913 (UTC) FILETIME=[86C2D390:01C8B52D] X-Nokia-AV: Clean Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I guess you have to read the draft. This is not about making false claims of where you are. Ciao Hannes >-----Original Message----- >From: ext James M. Polk [mailto:jmpolk@cisco.com] >Sent: 13 May, 2008 17:47 >To: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req > >At 02:09 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >>Content-class: urn:content-classes:message >>Content-Type: multipart/alternative; >> boundary="----_=_NextPart_001_01C8B4C8.52CB610A" >> >>Hi all, >> >>Henning gave a presentation about this draft at previous IETF >meetings. >>Although this is a controversal topic we believe it is important to >>capture the problem statement and the requirements. >>This document is NOT meant to capture solutions -- this is something >>for future work. We would therefore like to confirm the hum on the >>mailing list. If you have not stated your opinion or if you object >>please let us know. > >I am opposed to anything that will enable or guide the ability >of a user (or device on the user's behalf) to lie about where >they are. A user should be able to increase their target area >to the point of "I'm in Manhattan (or just New York, or just >US, or just North America), instead of which street address >I'm on" (i.e., reducing one's granularity or resolution). > > >>Deadline for your response: 30 May 2008 >> >>Ciao >>Hannes & Marc >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 15:24:35 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CE53A688E; Tue, 13 May 2008 15:24:35 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0E63A688E for ; Tue, 13 May 2008 15:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 cUz1+Ie1VQIY for ; Tue, 13 May 2008 15:24:33 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id DCCCA3A67E9 for ; Tue, 13 May 2008 15:24:32 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_13_17_21_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); Tue, 13 May 2008 17:21:28 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 17:07:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 17:07:28 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT: Next Steps Thread-Index: Aci1B1WJ702KE9ZJQXGGti1lu3yHuwAPkhjg References: From: "Winterbottom, James" To: "James M. Polk" , X-OriginalArrivalTime: 13 May 2008 22:07:29.0355 (UTC) FILETIME=[BC1E91B0:01C8B545] Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Totally right James, I believe that I have been saying this for the best part of a year now. Please may the record stand that James Polk and I agree on this point also. I think that is 3 things this year! > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Wednesday, 14 May 2008 12:39 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] ECRIT: Next Steps > > At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: > >Hi all, > > > >The chairs had a chat with our AD regarding the next steps with the > >working group. Here is a short summary. > > > >It is OK for Jon to add the following documents to the charter of the > >group: > >* Location Hiding PS and Requirements > > What does Location Hiding really have to do with ECRIT when > "Location" is Geopriv's charter? > > >Ciao > >Hannes & Marc > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 16:35:37 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907263A6968; Tue, 13 May 2008 16:35:37 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 770A73A6968 for ; Tue, 13 May 2008 16:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 vzVYwbATzJna for ; Tue, 13 May 2008 16:35:34 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9087F3A6922 for ; Tue, 13 May 2008 16:35:34 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_13_18_14_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 13 May 2008 18:14:13 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 18:00:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 18:00:11 -0500 Message-ID: In-Reply-To: <4829D240.4020201@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req Thread-Index: Aci1IG7Esn+cFKp/Rt+Im/eixPQ00gALA8ag References: <4829D240.4020201@bbn.com> From: "Winterbottom, James" To: "Richard Barnes" , X-OriginalArrivalTime: 13 May 2008 23:00:13.0811 (UTC) FILETIME=[1A483C30:01C8B54D] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Then I believe that two solutions have been provided One is a location "obscuring" solution where the end-point is provided a location. The other, that has been discussed, hides location by providing the end-point with a location URI, and a set of service URNs and corresponding destination URIs. Only the thing on the end of the destination URI is allowed to dereference the location URI. I will state again, that how this is done is a Geopriv problem, how it is used in emergency communications is an ECRIT problem. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Richard Barnes > Sent: Wednesday, 14 May 2008 3:39 AM > To: hannes.tschofenig@nsn.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req > > I strongly support solving this problem. However I believe the problem > is well-enough understood at this point that we should be driving toward > solutions, not just documenting requirements. If we're going to add > scope, that scope should include solutions in addition to requirements. > > So I hum in favor, with additional support for pursuing solutions as well. > > --Richard > > > > hannes.tschofenig@nsn.com wrote: > > Hi all, > > > > Henning gave a presentation about this draft at previous IETF meetings. > > Although this is a controversal topic we believe it is important to > > capture the problem statement and the requirements. This document is NOT > > meant to capture solutions -- this is something for future work. We > > would therefore like to confirm the hum on the mailing list. If you have > > not stated your opinion or if you object please let us know. > > > > Deadline for your response: 30 May 2008 > > > > Ciao > > Hannes & Marc > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 16:58:21 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8729B3A69AE; Tue, 13 May 2008 16:58:21 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BD13A6994 for ; Tue, 13 May 2008 16:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 08Rb262ekHmx for ; Tue, 13 May 2008 16:58:18 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 5456D3A69AE for ; Tue, 13 May 2008 16:58:18 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_13_17_18_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); Tue, 13 May 2008 17:18:48 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 17:04:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 17:04:44 -0500 Message-ID: In-Reply-To: <0c8701c8b513$85091470$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoAAAz7mrAAH4ynQAAPH2mA References: <48287315.5080100@gmx.net> <0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com> <0c8701c8b513$85091470$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 13 May 2008 22:04:48.0788 (UTC) FILETIME=[5C69FD40:01C8B545] Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Brian, Not quote certain people. "but just because that's way it works now is not a good reason to make it work that way next time". Some comments inline, only one Salvo over the bow though I think, and maybe some small arms fire in the background. Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 14 May 2008 2:08 AM > To: Winterbottom, James; 'Hannes Tschofenig'; 'ECRIT' > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > Snipped to deal with James' comments, with my responses in line > > > ED-5 is devices must recognize local dial strings. I believe 3GPP > does > > this. I don't know what 3GPP2 does. ED-5 is also SP-4. It's > possible we > > could water down this to say where the SP knows for certain where the > > location of the devices is at all times, then it can handle the > > recognition > > of dial strings and not require the end device to do that. I'd rather > not > > do that. > > > > [AJW] I think what is important is that the SP knows the what the user > is intending. I think that in a great many case, a user plugging into a > foreign network, but communicating back to a home SP will use home SP > dial strings. I want to make sure we allow this for several reasons. The > first is that it makes it MUCH easier for the SP to behave in a manner > that the caller expects without the SP having to become aware of the > location and associated call semantics associated with that environment. > Secondly, like it or not, people are creatures of habit, they want to > dial the same thing to get the same service no matter where they are. > Yes, part 2 can be addressed with UI and device mapping stuff, but then > you arrive at having to provide a solution for problem 1. Simply > allowing the SP to know the service based on the notion of "home dial > strings" avoids this whole can of worms. > >
Let's not start this again. > Local dial strings are required. Home dial strings are optional. That's > the way it works now, that's the way the PSAPs want it. You are > speculating > that home strings are a good idea. Whether I believe you or not doesn't > matter. It doesn't work that way now although in GSM systems, 9-1-1 and > 1-1-2 always work, so if those are your home strings you are in luck. It > is > unacceptable to require home dial strings in lieu of local dial strings. > > Since local strings are required, this requirement is necessary. > [AJW] Seriously, our entire ECRIT, i2 and i3 architectures are fundamentally different to the way in which GSM and UMTS networks operate. In the latter two, call service functions, all of them, are handled in the visited network, the ECRIT, i2 and i3 architectures don't. In the NENA and ECRIT architectures only the local access and location services are immediately used, call handling as it were, is handled by a home VSP, call-server, proxy, call it what you will. That home service then either routes, or determines the route to the PSAP. It is totally unclear to me how the dial-string even enters into this as long as the correct service URN is present, and that mapping doesn't need to be managed by an end-point. Since the home VSP knows its home dial string it can map that to the appropriate service URN when making a LoST request, it just works. I don't think that the current network analogies hold up under scrutiny, can you please provide reasonable rationale given that the routing trombones through a home service? > > > > > [AJW] I really hate the parenthetical as in many cellular cases, > particularly for omni-cell systems this is not practical, and if it is > for routing, it may not even be necessary. I think I have asked before > for this to be removed, and if I haven't I am definitely and strongly > asking now. >
Because we have to provide some guidance. So, we did. "Typically" > is > guidance, and not a hard requirement. > [AJW] I think no guidance is fine here since it will jurisdictional, and the jurisdictions will layout what needs to be provided. This is a bit like suggesting what civic fields need to populated, we haven't done this because we couldn't in any meaningful way. > > > ED-18 Endpoints SHOULD configure their own location > > It's a SHOULD. Do 3GPP2 systems assume no fixed devices? In 3GPP, > the > > fixed devices are expected to do endpoint location configuration. > Maybe > > they haven't gotten to that point yet > > > > [AJW] I think for your comment on 3GPP fixed solutions a clear document > reference to this information very important for any response to 3GPP2. > It isn't a requirement in 3GPP that I am aware of, so I wouldn't mind > seeing it also.... ;) >
TISPAN, now brought to you by 3GPP. I don't have the doc reference. > Hannes? > [AJW] I would like to see this. If you say it is in TISPAN that may be enough for me to go on if nobody has it handy. > > > ED-24 This is "supply an API to get location for apps that need it" > > I think they are dead wrong. AIM on a 3GPP2 phone needs a location > API. > > > [AJW] I think that this is going to be more of a handset and carrier > issue. Handset vendors and handset OS definers need to make APIs > available, certainly Android is doing this (though I don't like the > level it is pitched at). Carrier need to make it possible for the > necessary applications to get access this information in their networks, > until now putting third-party applications on some network operator > phones was essentially impossible. I am not sure that defining a > standard API in 3GPP(2) is the right thing to do. >
But isn't the text correct? There has to be a way. > [AJW] yup, there does. > > > ED-25 Endpoints SHOULD obtain location immediately after > > obtaining local network configuration information > > It's a should. I happen to think they should do this, but that's just > me. > > > > [AJW] This one I think just highlights the fundamental difference in > assumed architectures. The Internet model is putting near total control > at the end-point, 3GPP(2) still assumes that a single entity owns access > and service, owns it by proxy using roaming agreements. The Internet > model can work in the 2GPP(2) architecture, but the converse is not > true. I think ultimately that the Internet model will prevail as roaming > agreements and their associated complexities will drown under their own > weight, but until that happens I think we need to accepts that not all > network will make location available directly to the end-point when it > attaches to the network. >
Does text need to change? I don't think so. > [AJW] I think that I would change the text to say location information, that way a location URI is okay. > > [AJW] At present I, and a number of other people, remain unconvinced > that the current event packages and presence filter options for SIP meet > the needs of subscribing for location in this way. We probably need to > decide if we an a generic change of a specific one. I tend to think a > specific one is better since I don't see an application outside of > location at this point, so the "generic" component doesn't really have a > point of reference. >
I disagree, but since at present, all we have is 3856, that's what we > cite. > [AJW] I think the wording needs a little clean up then, because I totally misread this. I think something like the reword below might address my goofy-eyed problem: "Where a sip or sips URI scheme is used for a location reference, the server resolving the reference MUST support a SUBSCRIBE [RFC3265] to the presence event [RFC3856]." > > > ED-47 Endpoints MUST support one or more mechanisms that allow them > > to determine their public IP address. > > We may want to change this. If the device does LoST or LIS discovery, > it > > needs its IP address. If it doesn't do LIS or LoST discovery, it > doesn't > > need it. On the other hand, they have the AOL problem. They need a > > solution for that, and it may be LIS and/or LoST discovery. > > > > [AJW] LIS discovery does not always require you to know the external IP > address. Similarly I don't believe that LoST discovery does either. >
Some change is needed. The next requirement is LIS/LoST discovery. > Perhaps we just drop the requirement and assume it's in ED-48, or perhaps > we > augment ED-48 to point out the potential need to get your own IP address. > > > > > ED-48 Endpoints MUST support LIS discovery as described in > > [I-D.thomson-geopriv-lis-discovery], and the LoST discovery as > > described in [I-D.ietf-ecrit-dhc-lost-discovery]. > > Same as above > > > > [AJW] Reference update to LIS discovery si required. >
Okay > > > > > > SP-4 Local dial strings MUST be recognized > > Can't have it both ways folks. Either the endpoint does it or the > service > > provider does it (see ED-5) > > > > [AJW] See my note above.. I think you can definitely have it both ways. > > > > SP-17 If a proxy is attempting to insert location but the UA conveyed > > a location to it, the proxy MUST use the UA's location for routing > > and MUST convey that location towards the PSAP. > > I more or less understand them, but I disagree. I think they say that > > they > > insert location, and if an endpoint sends them location, they ignore > it. > > I > > think they are wrong; if the endpoint says it's somewhere, you are > best to > > believe it. The network can add what it thinks the location is to the > > call. > > > > > [AJW] A proxy can't insert location it goes against the rule in 3261. > Either we change this to a location URI, or we change the text to say > B2BUA, the term proxy is incorrect without a normative change to SIP. >
I was assuming a proxy inserts a reference. I can change this easily > enough. > > > > SP-18 All location objects received by a proxy MUST be delivered to > > the PSAP. > > Again, I think this is incorrect. If the device sends location, it > should > > be sent to the PSAP. > > > > [AJW] Delivered does not mean delivered in-band. I2, for example, would > meet this requirement, but the location will not be sent to the PSAP > in-band. >
Are you arguing for a change in text? I don't think we need to. > "Received by a proxy" is in-band. > [AJW] I am arguing that this requirement is already covered in any 3GPP(2) architecture that delivers a location to the PSAP today. No text change required. > > > > > SP-34 Unitialized devices SHOULD have a persistent URI in a > > P-Asserted-Identity: header if there is some way to assign such an > > identifier to the device > > This shouldn't be a problem. It's SHOULD, and it says "if possible". > The > > ability to call back an unitialized device is important. > > > [AJW] Uninitialized devices that have an IP address and general access > to the Internet. I really hate this term because it so ambiguous as to > what the device has rights to use. > > > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 18:01:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B943B3A692E; Tue, 13 May 2008 18:01:13 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45BD93A68BF for ; Tue, 13 May 2008 18:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 4qlXhgb+Ipb5 for ; Tue, 13 May 2008 18:01:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4FB5C3A692E for ; Tue, 13 May 2008 18:01:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,482,1204531200"; d="scan'208";a="26830783" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 13 May 2008 17:59:38 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4E0xcwx017737; Tue, 13 May 2008 17:59:38 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.13.8/8.13.8) with SMTP id m4E0xbAl019345; Wed, 14 May 2008 00:59:37 GMT From: Cullen Jennings To: "" In-Reply-To: Impp: xmpp:cullenfluffyjennings@jabber.org References: <0c7701c8b50b$28af8b80$640fa8c0@cis.neustar.com> <8298B117-2B1C-4166-B87D-172A4049EC49@cisco.com> Message-Id: <74252FA2-14D8-406E-BB2F-C81EA606E7C2@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 13 May 2008 17:59:27 -0700 X-Mailer: Apple Mail (2.919.2) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2683; t=1210726778; x=1211590778; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Ecrit]=20ECRIT=3A=20Next=20Steps |Sender:=20; bh=p2QpXVG8NIxK0rt6jK6eqehBIDK/c0WD1hSNYGKSCOw=; b=kW865DufK3HjBVT2hvMIkHdXHo2OjQR4S82I5LSAA+OyloQRDo8QNxAzE/ rE49FrHlUUSKIrOP3rN3jVyBf5SAemBh8V2jS1SmFc830RFI9zW5CPntPC/z a8y2IAxSw3; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ecrit@ietf.org Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ah, thanks, now I understand. I should have known. That makes sense. On May 13, 2008, at 12:51 PM, wrote: > Oh. I should have spelled it out. That can easily be confused with > Proposed Standard. Sorry. Was meant to mean "Problem Statement" > >> -----Original Message----- >> From: ext Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: 13 May, 2008 22:48 >> To: Tschofenig Hannes (NSN - FI/Espoo) >> Cc: br@brianrosen.net; ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT: Next Steps >> >> >> I think I was just confused on what "PS" means. What does it mean >> here? >> >> >> On May 13, 2008, at 12:43 PM, >> wrote: >> >>> Hi Cullen, >>> >>>> I certainly understand ECRIT doing requirements here, but I was >>>> hoping the mechanisms geopriv was developing would be >> general enough >>>> to meet these needs. If not, that seems to indicate a >> pretty serious >>>> concern with the mechanisms. >>> >>> Our discussions focused on emergency services. I don't think >> that the >>> discussion makes a lot of sense outside the emergency services >>> space. >>> >>> The current PS and requirements / design goal document does not >>> address solutions. It documents the discussions we had. >>> >>> >>> Ciao >>> Hannes >>> >>>> >>>> On May 13, 2008, at 8:08 AM, Brian Rosen wrote: >>>> >>>>> It's a requirement peculiar to emergency services. Location must >>> be >>>>> provided (typically by regulation) for emergency calls, >> but not for >>>>> other uses. We need a mechanism to restrict handing out of >>> location >>>>> to only the emergency case. >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>> On Behalf >>>>> Of James M. Polk >>>>> Sent: Tuesday, May 13, 2008 10:39 AM >>>>> To: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] ECRIT: Next Steps >>>>> >>>>> At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >>>>>> Hi all, >>>>>> >>>>>> The chairs had a chat with our AD regarding the next steps with >>> the >>>>>> working group. Here is a short summary. >>>>>> >>>>>> It is OK for Jon to add the following documents to the >>>> charter of the >>>>>> group: >>>>>> * Location Hiding PS and Requirements >>>>> >>>>> What does Location Hiding really have to do with ECRIT when >>>> "Location" >>>>> is Geopriv's charter? >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 18:16:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBCD93A699E; Tue, 13 May 2008 18:16:15 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD173A6870 for ; Tue, 13 May 2008 18:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK-vUfzUNQ60 for ; Tue, 13 May 2008 18:16:12 -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 B0C623A6975 for ; Tue, 13 May 2008 18:16:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,482,1204520400"; d="scan'208";a="8130807" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 May 2008 21:16:12 -0400 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 m4E1GCQN011487; Tue, 13 May 2008 21:16:12 -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.13.8) with ESMTP id m4E1GC4Z012429; Wed, 14 May 2008 01:16:12 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 21:16:12 -0400 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 21:16:11 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" , "'ECRIT'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com> Date: Tue, 13 May 2008 21:16:10 -0400 Message-ID: <00e701c8b560$18a00fd0$250d0d0a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoAAAz7mrAAH4ynQAAPH2mAAAcgrVA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: X-OriginalArrivalTime: 14 May 2008 01:16:12.0068 (UTC) FILETIME=[18FB7640:01C8B560] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1443; t=1210727772; x=1211591772; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20[Fwd=3A=203GPP2=20TSG-X=20Cor r=20to=20IETF=20re=20ECRIT/WGLC] |Sender:=20 |To:=20=22'Winterbottom,=20James'=22=20,=0A=20=20=20=20=20=20=20=20=22'ECRIT'=22=20; bh=MZ6z6iRDucXq4m3s4suoF8+9aqnF+EP2BfcHnrGKGD0=; b=owhylzyG+cjcNFJZ/8pT++GyJsQkUFLAITGGBGKhlwO1OXZxvXD4Eh9u+n lLF7JeGx45uMsmdoPv0syi9FUOFhiBR/kXQkyG8Xk1Ye7jL50WBdF6QSOkH7 DATH612Sza; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, > > > [AJW] Seriously, our entire ECRIT, i2 and i3 architectures > are fundamentally different to the way in which GSM and UMTS > networks operate. In the latter two, call service functions, > all of them, are handled in the visited network, the ECRIT, > i2 and i3 architectures don't. In the NENA and ECRIT > architectures only the local access and location services are > immediately used, call handling as it were, is handled by a > home VSP, call-server, proxy, call it what you will. That > home service then either routes, or determines the route to > the PSAP. It is totally unclear to me how the dial-string > even enters into this as long as the correct service URN is > present, and that mapping doesn't need to be managed by an > end-point. Since the home VSP knows its home dial string it > can map that to the appropriate service URN when making a > LoST request, it just works. > > I don't think that the current network analogies hold up > under scrutiny, can you please provide reasonable rationale > given that the routing trombones through a home service? Proxies/call agents are not a required element in the SIP model, hence, no guarantee of 'trombones through a home service'. Knowing local emergency dial strings solve the UI issue (the sign on the passing bus that says 'in case of emergency, dial 1234'), regardless of where the mapping is done. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 18:35:42 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF92C28C2DF; Tue, 13 May 2008 18:35:42 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3349B28C2CE for ; Tue, 13 May 2008 18:35:41 -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_46=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 Zz-Alln-TBBo for ; Tue, 13 May 2008 18:35:40 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 22D4228C2A6 for ; Tue, 13 May 2008 18:35:40 -0700 (PDT) Received: from [128.89.252.48] (helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jw5u6-0000xo-67; Tue, 13 May 2008 21:35:39 -0400 Message-ID: <482A41E7.6020202@bbn.com> Date: Tue, 13 May 2008 21:35:35 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: hannes.tschofenig@nsn.com References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net> <4829D1AD.1070905@bbn.com> In-Reply-To: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Certainly. I wasn't claiming that that was the recommendation of the IETF in any way, just that it was allowed. Using signed location in that way is not inconsistent with either location-conveyance or framework/phonebcp; it's one option that a jurisdiction could employ to assure the validity of static civic location information. --RLB hannes.tschofenig@nsn.com wrote: > We did not agree todo anything close to (2). > >> -----Original Message----- >> From: ext Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: 13 May, 2008 20:37 >> To: fmenard@xittelecom.com >> Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >> >> Francois, >> >> Let me answer your question in three parts: >> >> 1. The spec allows the LbyV to be digitally signed. The >> location is carried as a MIME body in the SIP message, and >> thus can also be included in S/MIME form, signed, encrypted, >> or both. See Appendix B of >> draft-ietf-sip-location-conveyance-10 for an example. >> > 10#appendix-B> >> >> 2. The signer does not necessarily have to be the PSAP (though >> this is definitely allowed). In the model described in >> framework/phonebcp, the endpoint gets its location from a >> server in the access network to which it's connected, so when >> we talk about location signing, I usually imagine that it's >> signed by the access network's location server. >> However, if a PSAP wanted to, it could provide signed location >> objects to access networks in its jurisdiction that could then >> be handed out to endpoints, who would then send them back to the PSAP: >> >> +------------+ >> | PSAP |<------(3)--------+ >> +------------+ | >> | | >> (1) | >> | | >> V | >> +------------+ +----------+ >> | Access Net |----(2)----->| Endpoint | >> +------------+ +----------+ >> >> 3. The IETF has not defined anything directly analogous to the >> MSAG, in the sense of a consolidated database (in fact, I >> believe that the NENA >> i3 architecture does away with the MSAG entirely). However, >> there is a location validation function provided by the LoST protocol: >> >> There is no current standard way for a location to be marked >> as valid (this could be hard, since notions of validity vary >>from place to place), but a PSAP could easily verify that a >> location is valid using LoST. >> >> Cheers, >> --Richard >> >> >> >> >> >> >> >> Francois Menard wrote: >>> Does the spec calls for digitally signing the LbyV by the PSAP, such >>> that the PSAP can recognize an LbyV as being signed by itself as >>> dispatch-able (i.e. MSAG-VALID), msag=master street address guide. >>> >>> F. >>> >>> -----Original Message----- >>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: 13 mai 2008 07:39 >>> To: Francois Menard >>> Cc: ; ecrit@ietf.org >>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>> >>> Francois, >>> >>> I don't have a complete list, but to answer your specific question, >>> location is transmitted by value from the endpoint to the >> PSAP in the >>> SIP INVITE message using the mechanism described in >>> draft-ietf-sip-location-conveyance. >>> >>> --Richard >>> >>> >>> >>> Francois Menard wrote: >>>> So that we may come prepared to this meeting, could you >> provide links >>>> to the latest specs, particularly the transmission of location by >>>> value from the end-point to the PSAP. >>>> >>>> F. >>>> >>>> >>>> On 13-May-08, at 2:58 AM, >>> >>> > wrote: >>>> >>>>> Hi all, >>>>> >>>>> We would like to inform you that we are currently planning to >>>>> organize a meeting with the 3GPP around August 2008. The >> main topic >>>>> for our discussion is the harmonization of the 3GPP and the IETF >>>>> emergency services architecture. >>>>> >>>>> We will distribute more details as soon as they are available. >>>>> >>>>> Ciao >>>>> Hannes & Marc >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> -- >>>> Francois Menard >>>> fmenard@xittelecom.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 ecrit-bounces@ietf.org Tue May 13 19:04:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75D293A699B; Tue, 13 May 2008 19:04:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32F43A699B for ; Tue, 13 May 2008 19:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, 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 TqcmPRwQCGNY for ; Tue, 13 May 2008 19:04:34 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6251A3A67A7 for ; Tue, 13 May 2008 19:04:33 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_13_21_00_16 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 13 May 2008 21:00:16 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 20:46:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 20:46:15 -0500 Message-ID: In-Reply-To: <482A41E7.6020202@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Joint Meeting with the 3GPP Thread-Index: Aci1YtRRu0N3/42LRne+jFieEDyX2AAACdVA References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net><4829D1AD.1070905@bbn.com> <482A41E7.6020202@bbn.com> From: "Dawson, Martin" To: "Richard Barnes" , X-OriginalArrivalTime: 14 May 2008 01:46:17.0284 (UTC) FILETIME=[4CF99040:01C8B564] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Though - to be clear - "validity" of the address is ultimately confirmed by a successful LoST lookup. The purpose of "validation" is to pre-ensure that the lookup will succeed. Having the PSAP sign the location isn't necessary for this - and it's not obvious to me that it actually helps. The LIS operator has the same onus to ensure valid locations are provided either way. Once a location object is "validated", there's no control over what real location that object actually gets used from. In terms of "location integrity" - i.e. ensuring that the caller isn't lying about their location - is a different issue. I don't think having location signed by the PSAP helps with this either. It's the access network operator that can evaluate the correlation between the point of connection used by the caller and the provided location. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Wednesday, 14 May 2008 11:36 AM To: hannes.tschofenig@nsn.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP Certainly. I wasn't claiming that that was the recommendation of the IETF in any way, just that it was allowed. Using signed location in that way is not inconsistent with either location-conveyance or framework/phonebcp; it's one option that a jurisdiction could employ to assure the validity of static civic location information. --RLB hannes.tschofenig@nsn.com wrote: > We did not agree todo anything close to (2). > >> -----Original Message----- >> From: ext Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: 13 May, 2008 20:37 >> To: fmenard@xittelecom.com >> Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >> >> Francois, >> >> Let me answer your question in three parts: >> >> 1. The spec allows the LbyV to be digitally signed. The >> location is carried as a MIME body in the SIP message, and >> thus can also be included in S/MIME form, signed, encrypted, >> or both. See Appendix B of >> draft-ietf-sip-location-conveyance-10 for an example. >> > 10#appendix-B> >> >> 2. The signer does not necessarily have to be the PSAP (though >> this is definitely allowed). In the model described in >> framework/phonebcp, the endpoint gets its location from a >> server in the access network to which it's connected, so when >> we talk about location signing, I usually imagine that it's >> signed by the access network's location server. >> However, if a PSAP wanted to, it could provide signed location >> objects to access networks in its jurisdiction that could then >> be handed out to endpoints, who would then send them back to the PSAP: >> >> +------------+ >> | PSAP |<------(3)--------+ >> +------------+ | >> | | >> (1) | >> | | >> V | >> +------------+ +----------+ >> | Access Net |----(2)----->| Endpoint | >> +------------+ +----------+ >> >> 3. The IETF has not defined anything directly analogous to the >> MSAG, in the sense of a consolidated database (in fact, I >> believe that the NENA >> i3 architecture does away with the MSAG entirely). However, >> there is a location validation function provided by the LoST protocol: >> >> There is no current standard way for a location to be marked >> as valid (this could be hard, since notions of validity vary >>from place to place), but a PSAP could easily verify that a >> location is valid using LoST. >> >> Cheers, >> --Richard >> >> >> >> >> >> >> >> Francois Menard wrote: >>> Does the spec calls for digitally signing the LbyV by the PSAP, such >>> that the PSAP can recognize an LbyV as being signed by itself as >>> dispatch-able (i.e. MSAG-VALID), msag=master street address guide. >>> >>> F. >>> >>> -----Original Message----- >>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: 13 mai 2008 07:39 >>> To: Francois Menard >>> Cc: ; ecrit@ietf.org >>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>> >>> Francois, >>> >>> I don't have a complete list, but to answer your specific question, >>> location is transmitted by value from the endpoint to the >> PSAP in the >>> SIP INVITE message using the mechanism described in >>> draft-ietf-sip-location-conveyance. >>> >>> --Richard >>> >>> >>> >>> Francois Menard wrote: >>>> So that we may come prepared to this meeting, could you >> provide links >>>> to the latest specs, particularly the transmission of location by >>>> value from the end-point to the PSAP. >>>> >>>> F. >>>> >>>> >>>> On 13-May-08, at 2:58 AM, >>> >>> > wrote: >>>> >>>>> Hi all, >>>>> >>>>> We would like to inform you that we are currently planning to >>>>> organize a meeting with the 3GPP around August 2008. The >> main topic >>>>> for our discussion is the harmonization of the 3GPP and the IETF >>>>> emergency services architecture. >>>>> >>>>> We will distribute more details as soon as they are available. >>>>> >>>>> Ciao >>>>> Hannes & Marc >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> -- >>>> Francois Menard >>>> fmenard@xittelecom.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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 19:05:26 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0698D3A69A0; Tue, 13 May 2008 19:05:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804C53A69A0 for ; Tue, 13 May 2008 19:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 wHWzcPOSlfgQ for ; Tue, 13 May 2008 19:05:19 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 733093A67A7 for ; Tue, 13 May 2008 19:05:19 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_13_21_18_37 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 13 May 2008 21:18:36 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 May 2008 21:04:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 May 2008 21:01:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoAAAz7mrAAH4ynQAAPH2mAAAcgrVAAAgzZiA== References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com> <00e701c8b560$18a00fd0$250d0d0a@cisco.com> From: "Winterbottom, James" To: "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 14 May 2008 02:04:37.0625 (UTC) FILETIME=[DCD44690:01C8B566] Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ummm perhaps I am misunderstanding what has been said then. I was under the impression that somebody vehemently objected to the notion of a call going directly to a PSAP URI. I will be watching very carefully to the answer to this one. I will also point out that dial string are only of importance when: 1) The service local to the user to user is handling the actual service determination 2) A service URN isn't already known. I think at best it is a should, is probably only a may. Cheers James -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Tue 5/13/2008 8:16 PM To: Winterbottom, James; 'ECRIT' Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] James, > > > [AJW] Seriously, our entire ECRIT, i2 and i3 architectures > are fundamentally different to the way in which GSM and UMTS > networks operate. In the latter two, call service functions, > all of them, are handled in the visited network, the ECRIT, > i2 and i3 architectures don't. In the NENA and ECRIT > architectures only the local access and location services are > immediately used, call handling as it were, is handled by a > home VSP, call-server, proxy, call it what you will. That > home service then either routes, or determines the route to > the PSAP. It is totally unclear to me how the dial-string > even enters into this as long as the correct service URN is > present, and that mapping doesn't need to be managed by an > end-point. Since the home VSP knows its home dial string it > can map that to the appropriate service URN when making a > LoST request, it just works. > > I don't think that the current network analogies hold up > under scrutiny, can you please provide reasonable rationale > given that the routing trombones through a home service? Proxies/call agents are not a required element in the SIP model, hence, no guarantee of 'trombones through a home service'. Knowing local emergency dial strings solve the UI issue (the sign on the passing bus that says 'in case of emergency, dial 1234'), regardless of where the mapping is done. -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] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 20:13:21 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9A63A68CD; Tue, 13 May 2008 20:13:21 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0AD13A67D5 for ; Tue, 13 May 2008 20:13:18 -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_46=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 QVHil7MDPlrD for ; Tue, 13 May 2008 20:13:17 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id A24463A68CD for ; Tue, 13 May 2008 20:13:17 -0700 (PDT) Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.44) id 1Jw7QJ-0003vT-9c; Tue, 13 May 2008 23:13:00 -0400 Received: from [207.96.236.134] (helo=[192.168.3.100]) by relay2.infoteck.qc.ca with esmtp (Exim 4.43) id 1Jw7QH-0007oq-UX; Tue, 13 May 2008 23:12:59 -0400 Message-Id: <2F4E9540-623B-494B-9BFC-CC482A72B7FF@xittelecom.com> From: Francois Menard To: "Dawson, Martin" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 13 May 2008 23:12:57 -0400 References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net><4829D1AD.1070905@bbn.com> <482A41E7.6020202@bbn.com> X-Mailer: Apple Mail (2.919.2) Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Let's assume the most pragmatic manual provisioning model, where I get a DHCP Option 82 with a MAC address tied to another MAC address that is tied to a given Civic. I configure my DHCP server to relay a PSAP- digitally-signed LbyV to an IP Phone. If the IP Phone dials SOS, he regurgitates a signed LbyV it has learned via DHCP LOC. No LIS, A Happy PSAP assigning MSAG valid entries to the service provider Low cost Privately negotiatable between a municipality an a VoIP service provider No ILEC in the picture. No LIS No LIS No LoST No Server that can fail What's the problem in this architecture? F. On 13-May-08, at 9:46 PM, Dawson, Martin wrote: > Though - to be clear - "validity" of the address is ultimately > confirmed > by a successful LoST lookup. The purpose of "validation" is to > pre-ensure that the lookup will succeed. Having the PSAP sign the > location isn't necessary for this - and it's not obvious to me that it > actually helps. The LIS operator has the same onus to ensure valid > locations are provided either way. Once a location object is > "validated", there's no control over what real location that object > actually gets used from. > > In terms of "location integrity" - i.e. ensuring that the caller isn't > lying about their location - is a different issue. I don't think > having > location signed by the PSAP helps with this either. It's the access > network operator that can evaluate the correlation between the point > of > connection used by the caller and the provided location. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Wednesday, 14 May 2008 11:36 AM > To: hannes.tschofenig@nsn.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Joint Meeting with the 3GPP > > Certainly. I wasn't claiming that that was the recommendation of the > IETF in any way, just that it was allowed. Using signed location in > that way is not inconsistent with either location-conveyance or > framework/phonebcp; it's one option that a jurisdiction could employ > to > assure the validity of static civic location information. > > --RLB > > > > hannes.tschofenig@nsn.com wrote: >> We did not agree todo anything close to (2). >> >>> -----Original Message----- >>> From: ext Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: 13 May, 2008 20:37 >>> To: fmenard@xittelecom.com >>> Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>> >>> Francois, >>> >>> Let me answer your question in three parts: >>> >>> 1. The spec allows the LbyV to be digitally signed. The >>> location is carried as a MIME body in the SIP message, and >>> thus can also be included in S/MIME form, signed, encrypted, >>> or both. See Appendix B of >>> draft-ietf-sip-location-conveyance-10 for an example. >>> >> 10#appendix-B> >>> >>> 2. The signer does not necessarily have to be the PSAP (though >>> this is definitely allowed). In the model described in >>> framework/phonebcp, the endpoint gets its location from a >>> server in the access network to which it's connected, so when >>> we talk about location signing, I usually imagine that it's >>> signed by the access network's location server. >>> However, if a PSAP wanted to, it could provide signed location >>> objects to access networks in its jurisdiction that could then >>> be handed out to endpoints, who would then send them back to the > PSAP: >>> >>> +------------+ >>> | PSAP |<------(3)--------+ >>> +------------+ | >>> | | >>> (1) | >>> | | >>> V | >>> +------------+ +----------+ >>> | Access Net |----(2)----->| Endpoint | >>> +------------+ +----------+ >>> >>> 3. The IETF has not defined anything directly analogous to the >>> MSAG, in the sense of a consolidated database (in fact, I >>> believe that the NENA >>> i3 architecture does away with the MSAG entirely). However, >>> there is a location validation function provided by the LoST > protocol: >>> >>> There is no current standard way for a location to be marked >>> as valid (this could be hard, since notions of validity vary >>> from place to place), but a PSAP could easily verify that a >>> location is valid using LoST. >>> >>> Cheers, >>> --Richard >>> >>> >>> >>> >>> >>> >>> >>> Francois Menard wrote: >>>> Does the spec calls for digitally signing the LbyV by the PSAP, >>>> such > >>>> that the PSAP can recognize an LbyV as being signed by itself as >>>> dispatch-able (i.e. MSAG-VALID), msag=master street address guide. >>>> >>>> F. >>>> >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: 13 mai 2008 07:39 >>>> To: Francois Menard >>>> Cc: ; ecrit@ietf.org >>>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>>> >>>> Francois, >>>> >>>> I don't have a complete list, but to answer your specific question, >>>> location is transmitted by value from the endpoint to the >>> PSAP in the >>>> SIP INVITE message using the mechanism described in >>>> draft-ietf-sip-location-conveyance. >>>> >>>> --Richard >>>> >>>> >>>> >>>> Francois Menard wrote: >>>>> So that we may come prepared to this meeting, could you >>> provide links >>>>> to the latest specs, particularly the transmission of location by >>>>> value from the end-point to the PSAP. >>>>> >>>>> F. >>>>> >>>>> >>>>> On 13-May-08, at 2:58 AM, >>>> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> We would like to inform you that we are currently planning to >>>>>> organize a meeting with the 3GPP around August 2008. The >>> main topic >>>>>> for our discussion is the harmonization of the 3GPP and the IETF >>>>>> emergency services architecture. >>>>>> >>>>>> We will distribute more details as soon as they are available. >>>>>> >>>>>> Ciao >>>>>> Hannes & Marc >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> -- >>>>> Francois Menard >>>>> fmenard@xittelecom.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 > > ------------------------------------------------------------------------------------------------ > 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 -- Francois Menard fmenard@xittelecom.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue May 13 22:24:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651283A694B; Tue, 13 May 2008 22:24:51 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63DE53A694B for ; Tue, 13 May 2008 22:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, 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 B7wKdDABKQRT for ; Tue, 13 May 2008 22:24:47 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 04C923A685A for ; Tue, 13 May 2008 22:24:46 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_00_38_29 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, 14 May 2008 00:38:29 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 00:24:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 00:24:08 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Joint Meeting with the 3GPP Thread-Index: Aci1cHk4TZKoIhMhSM2R9et/o76sdwAEkLzE References: <48297DE7.5000107@bbn.com><008a01c8b4ff$4e149110$ea3db330$@net><4829D1AD.1070905@bbn.com><482A41E7.6020202@bbn.com> <2F4E9540-623B-494B-9BFC-CC482A72B7FF@xittelecom.com> From: "Winterbottom, James" To: "Francois Menard" , "Dawson, Martin" X-OriginalArrivalTime: 14 May 2008 05:24:29.0423 (UTC) FILETIME=[C87F6FF0:01C8B582] Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Not possible using anything I have seen to date! -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Francois Menard Sent: Tue 5/13/2008 10:12 PM To: Dawson, Martin Cc: hannes.tschofenig@nsn.com; ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP Let's assume the most pragmatic manual provisioning model, where I get a DHCP Option 82 with a MAC address tied to another MAC address that is tied to a given Civic. I configure my DHCP server to relay a PSAP- digitally-signed LbyV to an IP Phone. If the IP Phone dials SOS, he regurgitates a signed LbyV it has learned via DHCP LOC. No LIS, A Happy PSAP assigning MSAG valid entries to the service provider Low cost Privately negotiatable between a municipality an a VoIP service provider No ILEC in the picture. No LIS No LIS No LoST No Server that can fail What's the problem in this architecture? F. On 13-May-08, at 9:46 PM, Dawson, Martin wrote: > Though - to be clear - "validity" of the address is ultimately > confirmed > by a successful LoST lookup. The purpose of "validation" is to > pre-ensure that the lookup will succeed. Having the PSAP sign the > location isn't necessary for this - and it's not obvious to me that it > actually helps. The LIS operator has the same onus to ensure valid > locations are provided either way. Once a location object is > "validated", there's no control over what real location that object > actually gets used from. > > In terms of "location integrity" - i.e. ensuring that the caller isn't > lying about their location - is a different issue. I don't think > having > location signed by the PSAP helps with this either. It's the access > network operator that can evaluate the correlation between the point > of > connection used by the caller and the provided location. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Wednesday, 14 May 2008 11:36 AM > To: hannes.tschofenig@nsn.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Joint Meeting with the 3GPP > > Certainly. I wasn't claiming that that was the recommendation of the > IETF in any way, just that it was allowed. Using signed location in > that way is not inconsistent with either location-conveyance or > framework/phonebcp; it's one option that a jurisdiction could employ > to > assure the validity of static civic location information. > > --RLB > > > > hannes.tschofenig@nsn.com wrote: >> We did not agree todo anything close to (2). >> >>> -----Original Message----- >>> From: ext Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: 13 May, 2008 20:37 >>> To: fmenard@xittelecom.com >>> Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>> >>> Francois, >>> >>> Let me answer your question in three parts: >>> >>> 1. The spec allows the LbyV to be digitally signed. The >>> location is carried as a MIME body in the SIP message, and >>> thus can also be included in S/MIME form, signed, encrypted, >>> or both. See Appendix B of >>> draft-ietf-sip-location-conveyance-10 for an example. >>> >> 10#appendix-B> >>> >>> 2. The signer does not necessarily have to be the PSAP (though >>> this is definitely allowed). In the model described in >>> framework/phonebcp, the endpoint gets its location from a >>> server in the access network to which it's connected, so when >>> we talk about location signing, I usually imagine that it's >>> signed by the access network's location server. >>> However, if a PSAP wanted to, it could provide signed location >>> objects to access networks in its jurisdiction that could then >>> be handed out to endpoints, who would then send them back to the > PSAP: >>> >>> +------------+ >>> | PSAP |<------(3)--------+ >>> +------------+ | >>> | | >>> (1) | >>> | | >>> V | >>> +------------+ +----------+ >>> | Access Net |----(2)----->| Endpoint | >>> +------------+ +----------+ >>> >>> 3. The IETF has not defined anything directly analogous to the >>> MSAG, in the sense of a consolidated database (in fact, I >>> believe that the NENA >>> i3 architecture does away with the MSAG entirely). However, >>> there is a location validation function provided by the LoST > protocol: >>> >>> There is no current standard way for a location to be marked >>> as valid (this could be hard, since notions of validity vary >>> from place to place), but a PSAP could easily verify that a >>> location is valid using LoST. >>> >>> Cheers, >>> --Richard >>> >>> >>> >>> >>> >>> >>> >>> Francois Menard wrote: >>>> Does the spec calls for digitally signing the LbyV by the PSAP, >>>> such > >>>> that the PSAP can recognize an LbyV as being signed by itself as >>>> dispatch-able (i.e. MSAG-VALID), msag=master street address guide. >>>> >>>> F. >>>> >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: 13 mai 2008 07:39 >>>> To: Francois Menard >>>> Cc: ; ecrit@ietf.org >>>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>>> >>>> Francois, >>>> >>>> I don't have a complete list, but to answer your specific question, >>>> location is transmitted by value from the endpoint to the >>> PSAP in the >>>> SIP INVITE message using the mechanism described in >>>> draft-ietf-sip-location-conveyance. >>>> >>>> --Richard >>>> >>>> >>>> >>>> Francois Menard wrote: >>>>> So that we may come prepared to this meeting, could you >>> provide links >>>>> to the latest specs, particularly the transmission of location by >>>>> value from the end-point to the PSAP. >>>>> >>>>> F. >>>>> >>>>> >>>>> On 13-May-08, at 2:58 AM, >>>> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> We would like to inform you that we are currently planning to >>>>>> organize a meeting with the 3GPP around August 2008. The >>> main topic >>>>>> for our discussion is the harmonization of the 3GPP and the IETF >>>>>> emergency services architecture. >>>>>> >>>>>> We will distribute more details as soon as they are available. >>>>>> >>>>>> Ciao >>>>>> Hannes & Marc >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> -- >>>>> Francois Menard >>>>> fmenard@xittelecom.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 > > ------------------------------------------------------------------------------------------------ > 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 -- Francois Menard fmenard@xittelecom.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 00:00:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E3F28C0EE; Wed, 14 May 2008 00:00:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5779E3A6968 for ; Wed, 14 May 2008 00:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.875 X-Spam-Level: X-Spam-Status: No, score=-5.875 tagged_above=-999 required=5 tests=[AWL=0.724, 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 JGilEFJH2BiE for ; Wed, 14 May 2008 00:00:40 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D2F2228C0EE for ; Wed, 14 May 2008 00:00:39 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4E6xqdj027893; Wed, 14 May 2008 09:59:57 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 09:59:42 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 09:59:40 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 09:59:40 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT: Next Steps Thread-Index: Aci1B1WJ702KE9ZJQXGGti1lu3yHuwAPkhjgABKS4rA= References: From: To: , , X-OriginalArrivalTime: 14 May 2008 06:59:40.0842 (UTC) FILETIME=[14C4D0A0:01C8B590] X-Nokia-AV: Clean Subject: Re: [Ecrit] ECRIT: Next Steps X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, You are focusing on the solution aspects and you have a very specific solution in mind and hence you believe it belongs to GEOPRIV since you want to dump the LoST functionality in HELD. Here we focus on the Problem Statement and the Requirements document. We are not discussing the solutions. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Winterbottom, James >Sent: 14 May, 2008 01:07 >To: James M. Polk; ecrit@ietf.org >Subject: Re: [Ecrit] ECRIT: Next Steps > >Totally right James, I believe that I have been saying this >for the best part of a year now. > >Please may the record stand that James Polk and I agree on >this point also. >I think that is 3 things this year! > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >Of >> James M. Polk >> Sent: Wednesday, 14 May 2008 12:39 AM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] ECRIT: Next Steps >> >> At 01:54 AM 5/13/2008, hannes.tschofenig@nsn.com wrote: >> >Hi all, >> > >> >The chairs had a chat with our AD regarding the next steps with the >> >working group. Here is a short summary. >> > >> >It is OK for Jon to add the following documents to the >charter of the >> >group: >> >* Location Hiding PS and Requirements >> >> What does Location Hiding really have to do with ECRIT when >"Location" >> is Geopriv's charter? >> >> >Ciao >> >Hannes & Marc >> > >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > >--------------------------------------------------------------- >--------------------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >--------------------------------------------------------------- >--------------------------------- >[mf2] > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 00:03:31 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D413A688A; Wed, 14 May 2008 00:03:31 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD65A3A688A for ; Wed, 14 May 2008 00:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=0.683, 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 cEuRhPiSzrOc for ; Wed, 14 May 2008 00:03:10 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id BD79A3A69DE for ; Wed, 14 May 2008 00:01:53 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4E6xqe9027893; Wed, 14 May 2008 10:00:26 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 10:00:25 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 10:00:25 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 10:00:23 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req Thread-Index: Aci1IG7Esn+cFKp/Rt+Im/eixPQ00gALA8agABDqx4A= References: <4829D240.4020201@bbn.com> From: To: , X-OriginalArrivalTime: 14 May 2008 07:00:25.0138 (UTC) FILETIME=[2F2BD920:01C8B590] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org No solution discussions -- PLEASE! >-----Original Message----- >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] >Sent: 14 May, 2008 02:00 >To: Richard Barnes; Tschofenig Hannes (NSN - FI/Espoo) >Cc: ecrit@ietf.org >Subject: RE: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req > >Then I believe that two solutions have been provided > >One is a location "obscuring" solution where the end-point is >provided a location. > >The other, that has been discussed, hides location by >providing the end-point with a location URI, and a set of >service URNs and corresponding destination URIs. Only the >thing on the end of the destination URI is allowed to >dereference the location URI. > >I will state again, that how this is done is a Geopriv >problem, how it is used in emergency communications is an >ECRIT problem. > >Cheers >James > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >Of >> Richard Barnes >> Sent: Wednesday, 14 May 2008 3:39 AM >> To: hannes.tschofenig@nsn.com >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req >> >> I strongly support solving this problem. However I believe the >problem >> is well-enough understood at this point that we should be driving >toward >> solutions, not just documenting requirements. If we're going to add >> scope, that scope should include solutions in addition to >requirements. >> >> So I hum in favor, with additional support for pursuing solutions as >well. >> >> --Richard >> >> >> >> hannes.tschofenig@nsn.com wrote: >> > Hi all, >> > >> > Henning gave a presentation about this draft at previous IETF >meetings. >> > Although this is a controversal topic we believe it is >important to >> > capture the problem statement and the requirements. This >document is >NOT >> > meant to capture solutions -- this is something for future >work. We >> > would therefore like to confirm the hum on the mailing list. If you >have >> > not stated your opinion or if you object please let us know. >> > >> > Deadline for your response: 30 May 2008 >> > >> > Ciao >> > Hannes & Marc >> > >> > >> > >--------------------------------------------------------------- >--------- >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > >--------------------------------------------------------------- >--------------------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >--------------------------------------------------------------- >--------------------------------- >[mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 00:19:59 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2923C3A688A; Wed, 14 May 2008 00:19:59 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7513A688A for ; Wed, 14 May 2008 00:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=-1.653, BAYES_00=-2.599, J_CHICKENPOX_46=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 C18YSAQRPEG2 for ; Wed, 14 May 2008 00:19:56 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 4FC463A6830 for ; Wed, 14 May 2008 00:19:55 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4E7IaAH013010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 May 2008 10:18:38 +0300 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4E7DcsR007184; Wed, 14 May 2008 02:15:22 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 10:15:19 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 10:15:18 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 10:15:17 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Joint Meeting with the 3GPP Thread-Index: Aci1cHk4TZKoIhMhSM2R9et/o76sdwAEkLzEAAOEOmA= References: <48297DE7.5000107@bbn.com><008a01c8b4ff$4e149110$ea3db330$@net><4829D1AD.1070905@bbn.com><482A41E7.6020202@bbn.com> <2F4E9540-623B-494B-9BFC-CC482A72B7FF@xittelecom.com> From: "hannes.tschofenig@nsn.com" To: , , X-OriginalArrivalTime: 14 May 2008 07:15:18.0709 (UTC) FILETIME=[43C7F650:01C8B592] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Francois, I guess you have missed several years of discussion. You might want to take a brief look at my tutorial slide set: http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/EswAgenda2007/ IETF-Emergency-Services-Tutorial.ppt Ciao Hannes >-----Original Message----- >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] >Sent: 14 May, 2008 08:24 >To: Francois Menard; Dawson, Martin >Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >Subject: RE: [Ecrit] Joint Meeting with the 3GPP > > >Not possible using anything I have seen to date! > > > >-----Original Message----- >From: ecrit-bounces@ietf.org on behalf of Francois Menard >Sent: Tue 5/13/2008 10:12 PM >To: Dawson, Martin >Cc: hannes.tschofenig@nsn.com; ecrit@ietf.org >Subject: Re: [Ecrit] Joint Meeting with the 3GPP > > >Let's assume the most pragmatic manual provisioning model, >where I get a DHCP Option 82 with a MAC address tied to >another MAC address that is tied to a given Civic. I >configure my DHCP server to relay a PSAP- digitally-signed >LbyV to an IP Phone. If the IP Phone dials SOS, he >regurgitates a signed LbyV it has learned via DHCP LOC. > >No LIS, > >A Happy PSAP assigning MSAG valid entries to the service provider > >Low cost > >Privately negotiatable between a municipality an a VoIP >service provider > >No ILEC in the picture. > >No LIS > >No LIS > >No LoST > >No Server that can fail > >What's the problem in this architecture? > >F. > >On 13-May-08, at 9:46 PM, Dawson, Martin wrote: > >> Though - to be clear - "validity" of the address is ultimately >> confirmed by a successful LoST lookup. The purpose of >"validation" is >> to pre-ensure that the lookup will succeed. Having the PSAP sign the >> location isn't necessary for this - and it's not obvious to >me that it >> actually helps. The LIS operator has the same onus to ensure valid >> locations are provided either way. Once a location object is >> "validated", there's no control over what real location that object >> actually gets used from. >> >> In terms of "location integrity" - i.e. ensuring that the >caller isn't >> lying about their location - is a different issue. I don't think >> having location signed by the PSAP helps with this either. It's the >> access network operator that can evaluate the correlation >between the >> point of connection used by the caller and the provided location. >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf >> Of Richard Barnes >> Sent: Wednesday, 14 May 2008 11:36 AM >> To: hannes.tschofenig@nsn.com >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >> >> Certainly. I wasn't claiming that that was the >recommendation of the >> IETF in any way, just that it was allowed. Using signed location in >> that way is not inconsistent with either location-conveyance or >> framework/phonebcp; it's one option that a jurisdiction could employ >> to assure the validity of static civic location information. >> >> --RLB >> >> >> >> hannes.tschofenig@nsn.com wrote: >>> We did not agree todo anything close to (2). >>> >>>> -----Original Message----- >>>> From: ext Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: 13 May, 2008 20:37 >>>> To: fmenard@xittelecom.com >>>> Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >>>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>>> >>>> Francois, >>>> >>>> Let me answer your question in three parts: >>>> >>>> 1. The spec allows the LbyV to be digitally signed. The >location is >>>> carried as a MIME body in the SIP message, and thus can also be >>>> included in S/MIME form, signed, encrypted, or both. See >Appendix B >>>> of draft-ietf-sip-location-conveyance-10 for an example. >>>> >>> 10#appendix-B> >>>> >>>> 2. The signer does not necessarily have to be the PSAP >(though this >>>> is definitely allowed). In the model described in >>>> framework/phonebcp, the endpoint gets its location from a >server in >>>> the access network to which it's connected, so when we talk about >>>> location signing, I usually imagine that it's signed by the access >>>> network's location server. >>>> However, if a PSAP wanted to, it could provide signed location >>>> objects to access networks in its jurisdiction that could then be >>>> handed out to endpoints, who would then send them back to the >> PSAP: >>>> >>>> +------------+ >>>> | PSAP |<------(3)--------+ >>>> +------------+ | >>>> | | >>>> (1) | >>>> | | >>>> V | >>>> +------------+ +----------+ >>>> | Access Net |----(2)----->| Endpoint | >>>> +------------+ +----------+ >>>> >>>> 3. The IETF has not defined anything directly analogous to >the MSAG, >>>> in the sense of a consolidated database (in fact, I >believe that the >>>> NENA >>>> i3 architecture does away with the MSAG entirely). However, there >>>> is a location validation function provided by the LoST >> protocol: >>>> >>>> There is no current standard way for a location to be marked as >>>> valid (this could be hard, since notions of validity vary >from place >>>> to place), but a PSAP could easily verify that a location is valid >>>> using LoST. >>>> >>>> Cheers, >>>> --Richard >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Francois Menard wrote: >>>>> Does the spec calls for digitally signing the LbyV by the PSAP, >>>>> such >> >>>>> that the PSAP can recognize an LbyV as being signed by itself as >>>>> dispatch-able (i.e. MSAG-VALID), msag=master street address guide. >>>>> >>>>> F. >>>>> >>>>> -----Original Message----- >>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>> Sent: 13 mai 2008 07:39 >>>>> To: Francois Menard >>>>> Cc: ; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>>>> >>>>> Francois, >>>>> >>>>> I don't have a complete list, but to answer your specific >question, >>>>> location is transmitted by value from the endpoint to the >>>> PSAP in the >>>>> SIP INVITE message using the mechanism described in >>>>> draft-ietf-sip-location-conveyance. >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> Francois Menard wrote: >>>>>> So that we may come prepared to this meeting, could you >>>> provide links >>>>>> to the latest specs, particularly the transmission of >location by >>>>>> value from the end-point to the PSAP. >>>>>> >>>>>> F. >>>>>> >>>>>> >>>>>> On 13-May-08, at 2:58 AM, >>>>> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> We would like to inform you that we are currently planning to >>>>>>> organize a meeting with the 3GPP around August 2008. The >>>> main topic >>>>>>> for our discussion is the harmonization of the 3GPP and >the IETF >>>>>>> emergency services architecture. >>>>>>> >>>>>>> We will distribute more details as soon as they are available. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes & Marc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> -- >>>>>> Francois Menard >>>>>> fmenard@xittelecom.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 >> >> >---------------------------------------------------------------------- >> -------------------------- 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 > >-- >Francois Menard >fmenard@xittelecom.com > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > >--------------------------------------------------------------- >--------------------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >--------------------------------------------------------------- >--------------------------------- >[mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 00:27:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10DE23A682A; Wed, 14 May 2008 00:27:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BB33A682A for ; Wed, 14 May 2008 00:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, 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 eWkUp90EDjIc for ; Wed, 14 May 2008 00:27:41 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 085F93A67A2 for ; Wed, 14 May 2008 00:27:40 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_02_39_41 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, 14 May 2008 02:39:41 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 02:25:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 02:25:22 -0500 Message-ID: In-Reply-To: <2F4E9540-623B-494B-9BFC-CC482A72B7FF@xittelecom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Joint Meeting with the 3GPP Thread-Index: Aci1cHNk/ZZtXfYTSFqsJIZnI0u3EwAEi/sg References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net><4829D1AD.1070905@bbn.com> <482A41E7.6020202@bbn.com> <2F4E9540-623B-494B-9BFC-CC482A72B7FF@xittelecom.com> From: "Dawson, Martin" To: "Francois Menard" X-OriginalArrivalTime: 14 May 2008 07:25:41.0725 (UTC) FILETIME=[B720A8D0:01C8B593] Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Well - the "DHCP" operator (let's call it a location server; the label used isn't important and we can also ignore the question of how option 82 is "signed") is the one that knows the end point location - and is providing the infrastructure to deliver the end point location. The PSAP doesn't tell them what the end point location is. "No LoST"? So how does the IP phone know where to send the call? The location is that of the phone - and not the place to route the call after all. Are you suggesting that the PSAP route is also encoded in this "signature"? If so, it means the routing boundaries have to remain fixed - if they moved (as they do), the location in the location server would "encode" the wrong destination. Assuming LoST is part of the picture, the operator cares that the location information is "valid" in the sense that it will result in a correct LoST lookup. They need to ask the "PSAP" (the emergency network in some incarnation) whether the location they are provisioning is "valid". The "PSAP" can provide a validation service for that location without subsequently signing it. What is the value of the signature? Where would the signature be "checked"? What would be the result of the signature not verifying when it is checked? Cheers, Martin -----Original Message----- From: Francois Menard [mailto:fmenard@xittelecom.com] Sent: Wednesday, 14 May 2008 1:13 PM To: Dawson, Martin Cc: Richard Barnes; hannes.tschofenig@nsn.com; ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP Let's assume the most pragmatic manual provisioning model, where I get a DHCP Option 82 with a MAC address tied to another MAC address that is tied to a given Civic. I configure my DHCP server to relay a PSAP- digitally-signed LbyV to an IP Phone. If the IP Phone dials SOS, he regurgitates a signed LbyV it has learned via DHCP LOC. No LIS, A Happy PSAP assigning MSAG valid entries to the service provider Low cost Privately negotiatable between a municipality an a VoIP service provider No ILEC in the picture. No LIS No LIS No LoST No Server that can fail What's the problem in this architecture? F. On 13-May-08, at 9:46 PM, Dawson, Martin wrote: > Though - to be clear - "validity" of the address is ultimately > confirmed > by a successful LoST lookup. The purpose of "validation" is to > pre-ensure that the lookup will succeed. Having the PSAP sign the > location isn't necessary for this - and it's not obvious to me that it > actually helps. The LIS operator has the same onus to ensure valid > locations are provided either way. Once a location object is > "validated", there's no control over what real location that object > actually gets used from. > > In terms of "location integrity" - i.e. ensuring that the caller isn't > lying about their location - is a different issue. I don't think > having > location signed by the PSAP helps with this either. It's the access > network operator that can evaluate the correlation between the point > of > connection used by the caller and the provided location. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Wednesday, 14 May 2008 11:36 AM > To: hannes.tschofenig@nsn.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Joint Meeting with the 3GPP > > Certainly. I wasn't claiming that that was the recommendation of the > IETF in any way, just that it was allowed. Using signed location in > that way is not inconsistent with either location-conveyance or > framework/phonebcp; it's one option that a jurisdiction could employ > to > assure the validity of static civic location information. > > --RLB > > > > hannes.tschofenig@nsn.com wrote: >> We did not agree todo anything close to (2). >> >>> -----Original Message----- >>> From: ext Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: 13 May, 2008 20:37 >>> To: fmenard@xittelecom.com >>> Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>> >>> Francois, >>> >>> Let me answer your question in three parts: >>> >>> 1. The spec allows the LbyV to be digitally signed. The >>> location is carried as a MIME body in the SIP message, and >>> thus can also be included in S/MIME form, signed, encrypted, >>> or both. See Appendix B of >>> draft-ietf-sip-location-conveyance-10 for an example. >>> >> 10#appendix-B> >>> >>> 2. The signer does not necessarily have to be the PSAP (though >>> this is definitely allowed). In the model described in >>> framework/phonebcp, the endpoint gets its location from a >>> server in the access network to which it's connected, so when >>> we talk about location signing, I usually imagine that it's >>> signed by the access network's location server. >>> However, if a PSAP wanted to, it could provide signed location >>> objects to access networks in its jurisdiction that could then >>> be handed out to endpoints, who would then send them back to the > PSAP: >>> >>> +------------+ >>> | PSAP |<------(3)--------+ >>> +------------+ | >>> | | >>> (1) | >>> | | >>> V | >>> +------------+ +----------+ >>> | Access Net |----(2)----->| Endpoint | >>> +------------+ +----------+ >>> >>> 3. The IETF has not defined anything directly analogous to the >>> MSAG, in the sense of a consolidated database (in fact, I >>> believe that the NENA >>> i3 architecture does away with the MSAG entirely). However, >>> there is a location validation function provided by the LoST > protocol: >>> >>> There is no current standard way for a location to be marked >>> as valid (this could be hard, since notions of validity vary >>> from place to place), but a PSAP could easily verify that a >>> location is valid using LoST. >>> >>> Cheers, >>> --Richard >>> >>> >>> >>> >>> >>> >>> >>> Francois Menard wrote: >>>> Does the spec calls for digitally signing the LbyV by the PSAP, >>>> such > >>>> that the PSAP can recognize an LbyV as being signed by itself as >>>> dispatch-able (i.e. MSAG-VALID), msag=master street address guide. >>>> >>>> F. >>>> >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: 13 mai 2008 07:39 >>>> To: Francois Menard >>>> Cc: ; ecrit@ietf.org >>>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>>> >>>> Francois, >>>> >>>> I don't have a complete list, but to answer your specific question, >>>> location is transmitted by value from the endpoint to the >>> PSAP in the >>>> SIP INVITE message using the mechanism described in >>>> draft-ietf-sip-location-conveyance. >>>> >>>> --Richard >>>> >>>> >>>> >>>> Francois Menard wrote: >>>>> So that we may come prepared to this meeting, could you >>> provide links >>>>> to the latest specs, particularly the transmission of location by >>>>> value from the end-point to the PSAP. >>>>> >>>>> F. >>>>> >>>>> >>>>> On 13-May-08, at 2:58 AM, >>>> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> We would like to inform you that we are currently planning to >>>>>> organize a meeting with the 3GPP around August 2008. The >>> main topic >>>>>> for our discussion is the harmonization of the 3GPP and the IETF >>>>>> emergency services architecture. >>>>>> >>>>>> We will distribute more details as soon as they are available. >>>>>> >>>>>> Ciao >>>>>> Hannes & Marc >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> -- >>>>> Francois Menard >>>>> fmenard@xittelecom.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 > > ------------------------------------------------------------------------ ------------------------ > 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 -- Francois Menard fmenard@xittelecom.com ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 06:00:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69BBB3A6989; Wed, 14 May 2008 06:00:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72A73A6989 for ; Wed, 14 May 2008 06:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 tgddPyRrDjOI for ; Wed, 14 May 2008 06:00:20 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id BA97C3A6985 for ; Wed, 14 May 2008 06:00:20 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JwGYZ-00014a-3Q; Wed, 14 May 2008 07:58:07 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Marc Linsner'" , "'ECRIT'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com> Date: Wed, 14 May 2008 08:58:08 -0400 Message-ID: <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoAAAz7mrAAH4ynQAAPH2mAAAcgrVAAAgzZiAAWs2lw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have no idea where the "objected to the notion of a call going directly to a PSAP URI" comes from. I want the call sent on the normal call path. If that is direct to the R-URI/Route header, then do that. If you normally send all outbound calls to an outbound proxy, do that. The item under discussion is ED-5, devices must recognize local dial strings. In that situation, the normal way to invoke an emergency call is a dial string (special buttons are discouraged). You want home strings to be recognized. I claim that is a nice to have, not a requirement, where local strings are a clear requirement (it's regulated in some countries). In that circumstance the service URN isn't already known. I don't know what "service local to the user" means. The service that usually handles calls is handling the call, one way or another. That might be the visited network in 3GPP wireless, or the home network for most other systems. If there is no service provider (Marc's self installed home proxy is handling the call), then there is no local service other than that. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Tuesday, May 13, 2008 10:01 PM To: Marc Linsner; ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Ummm perhaps I am misunderstanding what has been said then. I was under the impression that somebody vehemently objected to the notion of a call going directly to a PSAP URI. I will be watching very carefully to the answer to this one. I will also point out that dial string are only of importance when: 1) The service local to the user to user is handling the actual service determination 2) A service URN isn't already known. I think at best it is a should, is probably only a may. Cheers James -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Tue 5/13/2008 8:16 PM To: Winterbottom, James; 'ECRIT' Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] James, > > > [AJW] Seriously, our entire ECRIT, i2 and i3 architectures > are fundamentally different to the way in which GSM and UMTS > networks operate. In the latter two, call service functions, > all of them, are handled in the visited network, the ECRIT, > i2 and i3 architectures don't. In the NENA and ECRIT > architectures only the local access and location services are > immediately used, call handling as it were, is handled by a > home VSP, call-server, proxy, call it what you will. That > home service then either routes, or determines the route to > the PSAP. It is totally unclear to me how the dial-string > even enters into this as long as the correct service URN is > present, and that mapping doesn't need to be managed by an > end-point. Since the home VSP knows its home dial string it > can map that to the appropriate service URN when making a > LoST request, it just works. > > I don't think that the current network analogies hold up > under scrutiny, can you please provide reasonable rationale > given that the routing trombones through a home service? Proxies/call agents are not a required element in the SIP model, hence, no guarantee of 'trombones through a home service'. Knowing local emergency dial strings solve the UI issue (the sign on the passing bus that says 'in case of emergency, dial 1234'), regardless of where the mapping is done. -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] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 06:56:04 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D013A69B1; Wed, 14 May 2008 06:56:04 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35FF3A69B1 for ; Wed, 14 May 2008 06:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 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 Rqj4jPwaRZye for ; Wed, 14 May 2008 06:56:00 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 706473A698D for ; Wed, 14 May 2008 06:56:00 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JwHQt-0005YD-OC; Wed, 14 May 2008 08:54:16 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Winterbottom, James'" , "'Marc Linsner'" , "'ECRIT'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com> <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> Date: Wed, 14 May 2008 09:54:17 -0400 Message-ID: <0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoAAAz7mrAAH4ynQAAPH2mAAAcgrVAAAgzZiAAWs2lwAAEfVSAAAMjygA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Well, ED-5/SP-4, which is where the comments came from, is "Local dialstrings must be recognized". In the corresponding section of -framework it says: .... Users are not expected to "dial" an emergency URN. Rather, appropriate emergency dial strings are translated to corresponding service URNs, carried in the Request- URI of the INVITE request. Such translation is best done by the endpoint, among other reasons, because emergency calls convey location in the signaling, but non emergency calls do not normally do that. If the device recognizes the emergency call, it can include location. Dial string recognition could be performed in a signaling intermediary (proxy server) if for some reason the endpoint does not recognize it. To me, this is all clear. Best to do it at the endpoint. If you don't, you could do it at a proxy. The requirement is on both to get it done. Brian -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Wednesday, May 14, 2008 9:33 AM To: Brian Rosen; Winterbottom, James; Marc Linsner; ECRIT Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] I think the clarification - for me anyway - is that this is about the *device* recognizing that the user wants to invoke an emergency call. That is, the device, on initialization and however frequently periodically, learns the local emergency code(s) from the LoST server and "programs" itself to recognize the number sequence(s) as an emergency call invocation (even if the user previously understood that code to mean something else). I'm OK with that - I'd previously understood that there was some sort of a requirement on the proxy/home-service/VSP to recognize the local dial string(s) as an emergency call invocation. This had a problematic catch-22 aspect that bothered me - and I didn't even see why it was necessary. Dial strings should only be relevant to the VSP for an i2-style invocation and then it's really only reasonable to expect the VSP to recognize home emergency dial strings - plus whatever quasi-universal (e.g. 112) strings that it might also choose to observe. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, 14 May 2008 10:58 PM To: Winterbottom, James; 'Marc Linsner'; 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] I have no idea where the "objected to the notion of a call going directly to a PSAP URI" comes from. I want the call sent on the normal call path. If that is direct to the R-URI/Route header, then do that. If you normally send all outbound calls to an outbound proxy, do that. The item under discussion is ED-5, devices must recognize local dial strings. In that situation, the normal way to invoke an emergency call is a dial string (special buttons are discouraged). You want home strings to be recognized. I claim that is a nice to have, not a requirement, where local strings are a clear requirement (it's regulated in some countries). In that circumstance the service URN isn't already known. I don't know what "service local to the user" means. The service that usually handles calls is handling the call, one way or another. That might be the visited network in 3GPP wireless, or the home network for most other systems. If there is no service provider (Marc's self installed home proxy is handling the call), then there is no local service other than that. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Tuesday, May 13, 2008 10:01 PM To: Marc Linsner; ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Ummm perhaps I am misunderstanding what has been said then. I was under the impression that somebody vehemently objected to the notion of a call going directly to a PSAP URI. I will be watching very carefully to the answer to this one. I will also point out that dial string are only of importance when: 1) The service local to the user to user is handling the actual service determination 2) A service URN isn't already known. I think at best it is a should, is probably only a may. Cheers James -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Tue 5/13/2008 8:16 PM To: Winterbottom, James; 'ECRIT' Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] James, > > > [AJW] Seriously, our entire ECRIT, i2 and i3 architectures > are fundamentally different to the way in which GSM and UMTS > networks operate. In the latter two, call service functions, > all of them, are handled in the visited network, the ECRIT, > i2 and i3 architectures don't. In the NENA and ECRIT > architectures only the local access and location services are > immediately used, call handling as it were, is handled by a > home VSP, call-server, proxy, call it what you will. That > home service then either routes, or determines the route to > the PSAP. It is totally unclear to me how the dial-string > even enters into this as long as the correct service URN is > present, and that mapping doesn't need to be managed by an > end-point. Since the home VSP knows its home dial string it > can map that to the appropriate service URN when making a > LoST request, it just works. > > I don't think that the current network analogies hold up > under scrutiny, can you please provide reasonable rationale > given that the routing trombones through a home service? Proxies/call agents are not a required element in the SIP model, hence, no guarantee of 'trombones through a home service'. Knowing local emergency dial strings solve the UI issue (the sign on the passing bus that says 'in case of emergency, dial 1234'), regardless of where the mapping is done. -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] _______________________________________________ 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 ecrit-bounces@ietf.org Wed May 14 07:04:51 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D56213A6836; Wed, 14 May 2008 07:04:51 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAA3F3A6836 for ; Wed, 14 May 2008 07:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBKD4EAwi6q2 for ; Wed, 14 May 2008 07:04:43 -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 CF7783A67D0 for ; Wed, 14 May 2008 07:04:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,486,1204520400"; d="scan'208";a="8173822" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 May 2008 10:03:25 -0400 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 m4EE3PmA010117; Wed, 14 May 2008 10:03:25 -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.13.8) with ESMTP id m4EE3Pqi028205; Wed, 14 May 2008 14:03:25 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 10:03:25 -0400 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 10:03:24 -0400 From: "Marc Linsner" To: "'Brian Rosen'" , "'ECRIT'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com> <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> <0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com> Date: Wed, 14 May 2008 10:03:23 -0400 Message-ID: <008d01c8b5cb$4698b2a0$250d0d0a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoAAAz7mrAAH4ynQAAPH2mAAAcgrVAAAgzZiAAWs2lwAAEfVSAAAMjygAAAceAA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 14 May 2008 14:03:24.0849 (UTC) FILETIME=[46A86A10:01C8B5CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1302; t=1210773805; x=1211637805; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20[Fwd=3A=203GPP2=20TSG-X=20Cor r=20to=20IETF=20re=20ECRIT/WGLC] |Sender:=20 |To:=20=22'Brian=20Rosen'=22=20,=20=22'E CRIT'=22=20; bh=4G/jEqzHKs0KDT8cPsG/O/r9Noa9GfT74EB4kkUbysU=; b=ns+PJpuVqDcVVv13mR4ybf3bl2aMjml1KFBQP9vymZCEe5Ey7cX+B+9SCW l1eGoCLfCKDLpO3cydjKJE2M15SHQF/9UkVpx0m/7uUOjUBzww+QSNCh6EiY 5Zck/5WFMR; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Brian, Just to state the obvious..... > > Well, ED-5/SP-4, which is where the comments came from, is > "Local dialstrings must be recognized". In the corresponding > section of -framework it says: > .... Users are not expected to > "dial" an emergency URN. Rather, appropriate emergency > dial strings > are translated to corresponding service URNs, carried in > the Request- > URI of the INVITE request. Such translation is best done by the > endpoint, among other reasons, because emergency calls convey > location in the signaling, but non emergency calls do not > normally do > that. If the device recognizes the emergency call, it can include > location. Dial string recognition could be performed in a > signaling > intermediary (proxy server) if for some reason the > endpoint does not > recognize it. > > To me, this is all clear. Best to do it at the endpoint. If > you don't, you could do it at a proxy. The requirement is on > both to get it done. > If the UA is emergency call illiterate, which implies the UA *may* also be location illiterate, then it's inconceivable how the proxy can be emergency call literate such that it recognizes local dial strings. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 07:05:58 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C513A698D; Wed, 14 May 2008 07:05:58 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760743A69C9 for ; Wed, 14 May 2008 07:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Tz2lB7N9iHZS for ; Wed, 14 May 2008 07:05:49 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 02B0F3A67D0 for ; Wed, 14 May 2008 07:05:48 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_08_46_54 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, 14 May 2008 08:46:53 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 08:32:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 08:32:42 -0500 Message-ID: In-Reply-To: <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoAAAz7mrAAH4ynQAAPH2mAAAcgrVAAAgzZiAAWs2lwAAEfVSA= References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com> <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Winterbottom, James" , "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 14 May 2008 13:32:53.0764 (UTC) FILETIME=[033F0440:01C8B5C7] Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think the clarification - for me anyway - is that this is about the *device* recognizing that the user wants to invoke an emergency call. That is, the device, on initialization and however frequently periodically, learns the local emergency code(s) from the LoST server and "programs" itself to recognize the number sequence(s) as an emergency call invocation (even if the user previously understood that code to mean something else). I'm OK with that - I'd previously understood that there was some sort of a requirement on the proxy/home-service/VSP to recognize the local dial string(s) as an emergency call invocation. This had a problematic catch-22 aspect that bothered me - and I didn't even see why it was necessary. Dial strings should only be relevant to the VSP for an i2-style invocation and then it's really only reasonable to expect the VSP to recognize home emergency dial strings - plus whatever quasi-universal (e.g. 112) strings that it might also choose to observe. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, 14 May 2008 10:58 PM To: Winterbottom, James; 'Marc Linsner'; 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] I have no idea where the "objected to the notion of a call going directly to a PSAP URI" comes from. I want the call sent on the normal call path. If that is direct to the R-URI/Route header, then do that. If you normally send all outbound calls to an outbound proxy, do that. The item under discussion is ED-5, devices must recognize local dial strings. In that situation, the normal way to invoke an emergency call is a dial string (special buttons are discouraged). You want home strings to be recognized. I claim that is a nice to have, not a requirement, where local strings are a clear requirement (it's regulated in some countries). In that circumstance the service URN isn't already known. I don't know what "service local to the user" means. The service that usually handles calls is handling the call, one way or another. That might be the visited network in 3GPP wireless, or the home network for most other systems. If there is no service provider (Marc's self installed home proxy is handling the call), then there is no local service other than that. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Tuesday, May 13, 2008 10:01 PM To: Marc Linsner; ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Ummm perhaps I am misunderstanding what has been said then. I was under the impression that somebody vehemently objected to the notion of a call going directly to a PSAP URI. I will be watching very carefully to the answer to this one. I will also point out that dial string are only of importance when: 1) The service local to the user to user is handling the actual service determination 2) A service URN isn't already known. I think at best it is a should, is probably only a may. Cheers James -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Tue 5/13/2008 8:16 PM To: Winterbottom, James; 'ECRIT' Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] James, > > > [AJW] Seriously, our entire ECRIT, i2 and i3 architectures > are fundamentally different to the way in which GSM and UMTS > networks operate. In the latter two, call service functions, > all of them, are handled in the visited network, the ECRIT, > i2 and i3 architectures don't. In the NENA and ECRIT > architectures only the local access and location services are > immediately used, call handling as it were, is handled by a > home VSP, call-server, proxy, call it what you will. That > home service then either routes, or determines the route to > the PSAP. It is totally unclear to me how the dial-string > even enters into this as long as the correct service URN is > present, and that mapping doesn't need to be managed by an > end-point. Since the home VSP knows its home dial string it > can map that to the appropriate service URN when making a > LoST request, it just works. > > I don't think that the current network analogies hold up > under scrutiny, can you please provide reasonable rationale > given that the routing trombones through a home service? Proxies/call agents are not a required element in the SIP model, hence, no guarantee of 'trombones through a home service'. Knowing local emergency dial strings solve the UI issue (the sign on the passing bus that says 'in case of emergency, dial 1234'), regardless of where the mapping is done. -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] _______________________________________________ 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 ecrit-bounces@ietf.org Wed May 14 07:13:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E9E3A6837; Wed, 14 May 2008 07:13:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274593A6837 for ; Wed, 14 May 2008 07:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 onWD+UlE+mxB for ; Wed, 14 May 2008 07:13:15 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 461143A6836 for ; Wed, 14 May 2008 07:13:15 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JwHhs-00078n-V9; Wed, 14 May 2008 09:11:49 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'ECRIT'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com> <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> <0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com> <008d01c8b5cb$4698b2a0$250d0d0a@cisco.com> Date: Wed, 14 May 2008 10:11:50 -0400 Message-ID: <0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aci0TviFOQNnj9RdQpaz+Od3ghOqBQABByoAAAz7mrAAH4ynQAAPH2mAAAcgrVAAAgzZiAAWs2lwAAEfVSAAAMjygAAAceAAAABksZA= In-Reply-To: <008d01c8b5cb$4698b2a0$250d0d0a@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Well, yes. It's actually very hard for a proxy to recognize local dial strings, because, in general, it doesn't know where the device is, so it can't determine what the local dial strings are, whether the device is location literate or not. Brian -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Wednesday, May 14, 2008 10:03 AM To: 'Brian Rosen'; 'ECRIT' Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Brian, Just to state the obvious..... > > Well, ED-5/SP-4, which is where the comments came from, is > "Local dialstrings must be recognized". In the corresponding > section of -framework it says: > .... Users are not expected to > "dial" an emergency URN. Rather, appropriate emergency > dial strings > are translated to corresponding service URNs, carried in > the Request- > URI of the INVITE request. Such translation is best done by the > endpoint, among other reasons, because emergency calls convey > location in the signaling, but non emergency calls do not > normally do > that. If the device recognizes the emergency call, it can include > location. Dial string recognition could be performed in a > signaling > intermediary (proxy server) if for some reason the > endpoint does not > recognize it. > > To me, this is all clear. Best to do it at the endpoint. If > you don't, you could do it at a proxy. The requirement is on > both to get it done. > If the UA is emergency call illiterate, which implies the UA *may* also be location illiterate, then it's inconceivable how the proxy can be emergency call literate such that it recognizes local dial strings. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 07:56:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 712C13A6837; Wed, 14 May 2008 07:56:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287563A6854 for ; Wed, 14 May 2008 07:56:37 -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 PH+ua0QbLRfM for ; Wed, 14 May 2008 07:56:36 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 553453A6837 for ; Wed, 14 May 2008 07:56:36 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m4EEsxpm004462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 May 2008 10:55:00 -0400 (EDT) Message-Id: <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 14 May 2008 10:55:00 -0400 References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com> <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> <0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com> <008d01c8b5cb$4698b2a0$250d0d0a@cisco.com> <0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I'm guessing you are assuming that the proxy is somehow configured with the devices home location. (We probably don't want the proxy to recognize dial strings local to its physical location, unless it knows that all of its customers reside in the same area. In some cases, that may be true, e.g., because the VSP only serves customers in one country.) On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > Well, yes. It's actually very hard for a proxy to recognize local > dial > strings, because, in general, it doesn't know where the device is, > so it > can't determine what the local dial strings are, whether the device is > location literate or not. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 07:56:48 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC693A696A; Wed, 14 May 2008 07:56:48 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE823A696A for ; Wed, 14 May 2008 07:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13, 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 r4jo78Lv9p0Y for ; Wed, 14 May 2008 07:56:45 -0700 (PDT) Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by core3.amsl.com (Postfix) with ESMTP id D7EBC3A6933 for ; Wed, 14 May 2008 07:56:40 -0700 (PDT) Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.201830004; Wed, 14 May 2008 10:49:18 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 May 2008 10:49:19 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 May 2008 10:49:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 10:49:17 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA08CB6BFA@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req Thread-Index: Aci0yFKCAdMTvHCNQROxAcz1h6h62gBAAJ6g References: From: "Stark, Barbara" To: , X-OriginalArrivalTime: 14 May 2008 14:49:19.0432 (UTC) FILETIME=[B0846C80:01C8B5D1] Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1885423532==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1885423532== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B5D1.B071FE0F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B5D1.B071FE0F Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I think this is an important ecrit effort. ecrit needs to make sure its architecture (defined through framework, phonebcp, LoST, and LoST-related docs) meets the needs of all stakeholders. The service provider community has stated that "location hiding" is a requirement, to provide buy-in to the ecrit architecture. =20 Once the requirements have been defined, this may drive solutions that impact geopriv and ecrit efforts. I've heard potential solutions that impact location configuration protocols (geopriv) and some that impact LoST or even phonebcp / framework. Once we have agreed on the requirements (which hopefully can be done quickly, given how few requirements there appear to be), we should be able to come up with potential solutions that are backward compatible with work done to date. This may mean enhancements to geopriv and/or ecrit RFCs. =20 If James P thinks there needs to be a requirement that "location hiding" mechanisms are allowed to obscure location (by specifying a large area and saying the target is somewhere in that area), but not provide a false location (by specifying some other specific point within the same emergency service area), I'm ok with that. That's reasonable. =20 Backward compatibility is probably also a requirement. That is, if devices, access networks, and services provider networks are built to existing phonebcp requirements, the introduction of new location hiding capabilities shouldn't cause these to break. =20 Anyway, I hum in favor of this "location hiding" requirements documenting effort. Barbara ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of hannes.tschofenig@nsn.com Sent: Tuesday, May 13, 2008 3:10 AM To: ecrit@ietf.org Subject: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req Hi all,=20 Henning gave a presentation about this draft at previous IETF meetings. Although this is a controversal topic we believe it is important to capture the problem statement and the requirements. This document is NOT meant to capture solutions -- this is something for future work. We would therefore like to confirm the hum on the mailing list. If you have not stated your opinion or if you object please let us know.=20 Deadline for your response: 30 May 2008=20 Ciao=20 Hannes & Marc=20 ------_=_NextPart_001_01C8B5D1.B071FE0F Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hum: = draft-schulzrinne-ecrit-location-hiding-req
I think=20 this is an important ecrit effort.
ecrit=20 needs to make sure its architecture (defined through framework, = phonebcp, LoST,=20 and LoST-related docs) meets the needs of all = stakeholders.
The=20 service provider community has stated that "location hiding" is a = requirement,=20 to provide buy-in to the ecrit architecture.
 
Once the=20 requirements have been defined, this may drive solutions that impact = geopriv and=20 ecrit efforts. I've heard potential solutions that impact location = configuration=20 protocols (geopriv) and some that impact LoST or even phonebcp / = framework.=20 Once we have agreed on the requirements (which hopefully can be done = quickly,=20 given how few requirements there appear to be), we should be able=20 to come up with potential solutions that are backward compatible = with work=20 done to date. This may mean enhancements to geopriv and/or ecrit=20 RFCs.
 
If James=20 P thinks there needs to be a requirement that "location hiding" = mechanisms are=20 allowed to obscure location (by specifying a large area and saying the = target is=20 somewhere in that area), but not provide a false location (by specifying = some=20 other specific point within the same emergency service area), I'm ok = with that.=20 That's reasonable.
 
Backward=20 compatibility is probably also a requirement. That is, if devices, = access=20 networks, and services provider networks are built to existing = phonebcp=20 requirements, the introduction of new location hiding capabilities = shouldn't=20 cause these to break.
 
Anyway,=20 I hum in favor of this "location hiding" requirements documenting=20 effort.
Barbara

From: ecrit-bounces@ietf.org=20 [mailto:ecrit-bounces@ietf.org] On Behalf Of=20 hannes.tschofenig@nsn.com
Sent: Tuesday, May 13, 2008 3:10 = AM
To: ecrit@ietf.org
Subject: [Ecrit] Hum:=20 draft-schulzrinne-ecrit-location-hiding-req

Hi all,

Henning gave a presentation about = this draft=20 at previous IETF meetings. Although this is a controversal topic we = believe it=20 is important to capture the problem statement and the requirements. This = document is NOT meant to capture solutions -- this is something for = future work.=20 We would therefore like to confirm the hum on the mailing list. If you = have not=20 stated your opinion or if you object please let us know.

Deadline for your response: 30 = May=20 2008

Ciao
Hannes & Marc

------_=_NextPart_001_01C8B5D1.B071FE0F-- --===============1885423532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1885423532==-- From ecrit-bounces@ietf.org Wed May 14 08:34:55 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED23A3A697C; Wed, 14 May 2008 08:34:55 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993EA3A6949 for ; Wed, 14 May 2008 08:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[AWL=-0.304, 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 r3uZkNh9MXCU for ; Wed, 14 May 2008 08:34:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A044A3A697E for ; Wed, 14 May 2008 08:34:38 -0700 (PDT) Received: (qmail invoked by alias); 14 May 2008 15:12:59 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp048) with SMTP; 14 May 2008 17:12:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+R51hO1oeRe3AoWIiBrt1y9gkSGzuiU7nFHa/7RQ IffnfZ8xhcOGob Message-ID: <482B017A.9020205@gmx.net> Date: Wed, 14 May 2008 18:12:58 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Brian Rosen References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com> <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> <0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com> <008d01c8b5cb$4698b2a0$250d0d0a@cisco.com> <0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> In-Reply-To: <0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> X-Y-GMX-Trusted: 0 Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Unless it is a proxy that has a relationship with the access networks, as envisioned by the 3GPP with their P-CSCF... Brian Rosen wrote: > Well, yes. It's actually very hard for a proxy to recognize local dial > strings, because, in general, it doesn't know where the device is, so it > can't determine what the local dial strings are, whether the device is > location literate or not. > > Brian > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, May 14, 2008 10:03 AM > To: 'Brian Rosen'; 'ECRIT' > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > Brian, > > Just to state the obvious..... > > >> Well, ED-5/SP-4, which is where the comments came from, is >> "Local dialstrings must be recognized". In the corresponding >> section of -framework it says: >> .... Users are not expected to >> "dial" an emergency URN. Rather, appropriate emergency >> dial strings >> are translated to corresponding service URNs, carried in >> the Request- >> URI of the INVITE request. Such translation is best done by the >> endpoint, among other reasons, because emergency calls convey >> location in the signaling, but non emergency calls do not >> normally do >> that. If the device recognizes the emergency call, it can include >> location. Dial string recognition could be performed in a >> signaling >> intermediary (proxy server) if for some reason the >> endpoint does not >> recognize it. >> >> To me, this is all clear. Best to do it at the endpoint. If >> you don't, you could do it at a proxy. The requirement is on >> both to get it done. >> >> > > If the UA is emergency call illiterate, which implies the UA *may* also be > location illiterate, then it's inconceivable how the proxy can be emergency > call literate such that it recognizes local dial strings. > > -Marc- > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 11:33:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7CC3A6940; Wed, 14 May 2008 11:33:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82D43A6947 for ; Wed, 14 May 2008 11:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 eOCL1TlO8M+2 for ; Wed, 14 May 2008 11:33:20 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9CCC63A6887 for ; Wed, 14 May 2008 11:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1210790002; x=1242326002; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<17AD9E1F-6FB5-4A2D-9BBC- EE2306C271DE@cs.columbia.edu>|References:=20<48287315.508 0100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar. com=0D=0A=20><0c8701c8b513=0D=0A=20$85091470$640fa8c0@ cis.neustar.com><00e701c8b560$18a00fd0$250d 0d0a@cisco.com>=0D=0A=20<0da001c8b5c2$2a0b0fb0$ 640fa8c0@cis.neustar.com>=0D=0A=20=0D=0A=20<0dad01c8b5 ca$021a5300$640fa8c0@cis.neustar.com>=0D=0A=20<008d01c8b5 cb$4698b2a0$250d0d0a@cisco.com>=0D=0A=20<0dae01c8b5cc$75f 18ee0$640fa8c0@cis.neustar.com>=0D=0A=20<17AD9E1F-6FB5-4A 2D-9BBC-EE2306C271DE@cs.columbia.edu>|Date:=20Wed,=2014 =20May=202008=2011:32:24=20-0700|To:=20Henning=20Schulzri nne=20,=20Brian=20Rosen=20|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20[Fwd:=203GPP2=20TSG-X=20Corr =20to=20IETF=20re=20ECRIT/WGLC]|CC:=20"'ECRIT'"=20|Content-Type:=20text/plain=3B=20charset=3D"us-a scii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5200,2160,5295" =3B=20a=3D"3127621"; bh=tY444drB450V0DW7yGaU907KnVt5AHEfDNgZjk3RdkI=; b=s7/A/7FwtUyGfhA3MhiTiWIwBTRyvp4uUKvO5Aky1oRT3zyYn9rolrlA IO0Q/pMeJiTl0qiviJ5xXvhCJm2XntlE8wS/+ZcU+l3PRu7pQUDq69UTL ppGpP3wWisDd0/KWTsZhiPLGiw/o4L+bpYO2xVnHhxQBkHKhqKA4QHkY8 w=; X-IronPort-AV: E=McAfee;i="5200,2160,5295"; a="3127621" 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; 14 May 2008 11:32:29 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4EIWTfh000554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 May 2008 11:32:29 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4EIWSq0011879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 May 2008 11:32:28 -0700 Received: from [24.4.239.115] (10.50.16.67) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.263.0; Wed, 14 May 2008 11:32:28 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com ><0c8701c8b513 $85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com> <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> <0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com> <008d01c8b5cb$4698b2a0$250d0d0a@cisco.com> <0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> Date: Wed, 14 May 2008 11:32:24 -0700 To: Henning Schulzrinne , Brian Rosen From: Ted Hardie Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 7:55 AM -0700 5/14/08, Henning Schulzrinne wrote: >I'm guessing you are assuming that the proxy is somehow configured >with the devices home location. (We probably don't want the proxy to >recognize dial strings local to its physical location, unless it knows >that all of its customers reside in the same area. In some cases, that >may be true, e.g., because the VSP only serves customers in one >country.) I had been thinking that would be the case for many enterprise-as-VSP cases, since they would know whether or not mobile devices could be connected to the network or not (for example, enterprises with no VPN connecitivity or which did not permit VPN devices to use the telephony service). Would that fit with your thinking? Ted > >On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > >> Well, yes. It's actually very hard for a proxy to recognize local >> dial >> strings, because, in general, it doesn't know where the device is, >> so it >> can't determine what the local dial strings are, whether the device is >> location literate or not. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 12:13:46 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A163A6813; Wed, 14 May 2008 12:13:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01F9D3A681F for ; Wed, 14 May 2008 12:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=0.730, 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 Q2z0MxqK46bZ for ; Wed, 14 May 2008 12:13:38 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 2A9203A6781 for ; Wed, 14 May 2008 12:13:31 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4EJBOQY027203; Wed, 14 May 2008 14:12:04 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 22:10:14 +0300 Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 22:10:14 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 22:07:11 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci18QUcKYWmaHwgQEGAMWqH9hQRrAABH9vA References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com><17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> From: To: , , X-OriginalArrivalTime: 14 May 2008 19:10:14.0077 (UTC) FILETIME=[2369AED0:01C8B5F6] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yep. The enterprise case is a more restrictive case than the 3GPP IMS scenario since in IMS one would talk to a proxy associated with the access even when you are roaming. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Ted Hardie >Sent: 14 May, 2008 21:32 >To: Henning Schulzrinne; Brian Rosen >Cc: 'ECRIT' >Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > >At 7:55 AM -0700 5/14/08, Henning Schulzrinne wrote: >>I'm guessing you are assuming that the proxy is somehow >configured with >>the devices home location. (We probably don't want the proxy to >>recognize dial strings local to its physical location, unless >it knows >>that all of its customers reside in the same area. In some >cases, that >>may be true, e.g., because the VSP only serves customers in one >>country.) > >I had been thinking that would be the case for many >enterprise-as-VSP cases, since they would know whether or not >mobile devices could be connected to the network or not (for >example, enterprises with no VPN connecitivity or which did >not permit VPN devices to use the telephony service). Would >that fit with your thinking? > > Ted > > > > >> >>On May 14, 2008, at 10:11 AM, Brian Rosen wrote: >> >>> Well, yes. It's actually very hard for a proxy to recognize local >>> dial strings, because, in general, it doesn't know where the device >>> is, so it can't determine what the local dial strings are, whether >>> the device is location literate or not. >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 14:40:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 991323A6819; Wed, 14 May 2008 14:40:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A73D3A67F7 for ; Wed, 14 May 2008 14:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.291 X-Spam-Level: X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 e+j4FFgWu+4j for ; Wed, 14 May 2008 14:40:12 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8508C3A6780 for ; Wed, 14 May 2008 14:40:11 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_16_54_13 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, 14 May 2008 16:54:13 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 16:40:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 16:40:12 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4I References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> From: "Winterbottom, James" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 14 May 2008 21:40:12.0722 (UTC) FILETIME=[1705F120:01C8B60B] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org *BUZZZ** Okay let me try again! I think you are making a leap here which isn't required. Let me try and describe the scenario and configuration first, and then you can try and tell me why I need local dial strings. Andy is caller. Andy uses a VSP called Veronica Veronica is based in Vermont Veronica recognizes the emergency dial string 911. For the point of the argument, let's say that that is all that Veronica recognizes. Veronica has a pet LoST server Lucy Veronica will send any mapping requests to Lucy Lucy is responsible to find the correct mapping. Andy travels Sierra-Leone Andy Connects to the local access network Andy gets a location Andy's room gets broken into, and he calls Veronica! Andy is in a panic, so he calls 911 (which is a good thing since that is all that Veronica understands) I expect this just to work, and this is why. Veronica has a simple trigger looking for 911 Veronica can then have a standard query set to send to Lucy Location (from call) + fixed service URN (sos.. etc) Lucy manages the mapping to destination URI Andy's call gets directed to the local emergency centre Here is where it breaks down The local emergency centre doesn't understand a word of english In this scenario I don't need local dial-string, at all ever. I believe that for quite some time this will be a very common configuration. Hence local dial strings are a may, not a must from an end-point needing to understand them point of view. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne Sent: Wed 5/14/2008 9:55 AM To: Brian Rosen Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] I'm guessing you are assuming that the proxy is somehow configured with the devices home location. (We probably don't want the proxy to recognize dial strings local to its physical location, unless it knows that all of its customers reside in the same area. In some cases, that may be true, e.g., because the VSP only serves customers in one country.) On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > Well, yes. It's actually very hard for a proxy to recognize local > dial > strings, because, in general, it doesn't know where the device is, > so it > can't determine what the local dial strings are, whether the device is > location literate or not. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 15:15:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8751C3A68A2; Wed, 14 May 2008 15:15:19 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166C03A67DD for ; Wed, 14 May 2008 15:15:10 -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 P21Ho2XLH1Yk for ; Wed, 14 May 2008 15:14:58 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BD34E3A6876 for ; Wed, 14 May 2008 15:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1210803299; x=1242339299; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20<4828731 5.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neu star.com=0D=0A=20><0c8701c8b513=0D=0A=20$85091470$640f a8c0@cis.neustar.com><00e701c8b560$18a00fd0$2 50d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640f =0D=0A=20a8c0@cis.neustar.com><0dad01c8b5ca$0 21a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b=0D =0A=202a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa 8c0@cis.neustar.com>=0D=0A=20<17AD9E1F-6FB5-4A2D-9BBC-EE2 306C271DE@cs.columbia.edu>=0D=0A=20|Date:=20Wed,=2014=20 May=202008=2015:13:51=20-0700|To:=20"Winterbottom,=20Jame s"=20,=0D=0A=20=20=20=20 =20=20=20=20Henning=20Schulzrinne=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Brian=20Rosen=20|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20[Fwd:=203GPP2=20TSG-X=20Co rr=20to=20IETF=20re=20ECRIT/WGLC]|CC:=20ECRIT=20|Content-Type:=20text/plain=3B=20charset=3D"us-asc ii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5295"=3B =20a=3D"2957475"; bh=gdagBUWAK8g/PutSO2igOyrFwfBSATvRPx4pLyjSG/g=; b=uvCmyZYtg7EsPuzkhy7JxekQg5e6IGlT70ZE8H3l1wR34jMY+rhiwz3o DYJUk52u96hHfJajtErBZqxggqhSW9JWhutbh/M7BWjtFRv6B9ZSBur2s pQJQArEb974TBw7+u48gX4b0SIacVMD5wF5pL/4h57yqErkPck58CPfF7 o=; X-IronPort-AV: E=McAfee;i="5100,188,5295"; a="2957475" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 May 2008 15:14:02 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4EME1vn032617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 May 2008 15:14:02 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4EME1EM003752 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 May 2008 15:14:01 -0700 Received: from [192.168.0.119] (10.50.16.115) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.263.0; Wed, 14 May 2008 15:13:59 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com ><0c8701c8b513 $85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640f a8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b 2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> Date: Wed, 14 May 2008 15:13:51 -0700 To: "Winterbottom, James" , Henning Schulzrinne , Brian Rosen From: Ted Hardie Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 2:40 PM -0700 5/14/08, Winterbottom, James wrote: >* >Andy travels Sierra-Leone >Andy Connects to the local access network >Andy gets a location >Andy's room gets broken into, and he calls Veronica! >Andy is in a panic, so he calls 911 (which is a good thing since that is all that Veronica understands) > >I expect this just to work, and this is why. >Veronica has a simple trigger looking for 911 >Veronica can then have a standard query set to send to Lucy >Location (from call) + fixed service URN (sos.. etc) >Lucy manages the mapping to destination URI >Andy's call gets directed to the local emergency centre > >Here is where it breaks down > >The local emergency centre doesn't understand a word of english > English is the official language of Sierra Leone, so this seems unlikely. On another note, would you mind relating this interesting tale of Andy, Veronic, and Lucy back to 3GPP2's liaison statement? Just to help those of us having trouble keeping up. thanks, Ted >In this scenario I don't need local dial-string, at all ever. >I believe that for quite some time this will be a very common configuration. >Hence local dial strings are a may, not a must from an end-point needing to understand them point of view. > >Cheers >James > > > >-----Original Message----- >From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne >Sent: Wed 5/14/2008 9:55 AM >To: Brian Rosen >Cc: 'ECRIT' >Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > >I'm guessing you are assuming that the proxy is somehow configured >with the devices home location. (We probably don't want the proxy to >recognize dial strings local to its physical location, unless it knows >that all of its customers reside in the same area. In some cases, that >may be true, e.g., because the VSP only serves customers in one >country.) > >On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > >> Well, yes. It's actually very hard for a proxy to recognize local >> dial >> strings, because, in general, it doesn't know where the device is, >> so it >> can't determine what the local dial strings are, whether the device is >> location literate or not. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 15:23:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95533A6896; Wed, 14 May 2008 15:23:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758C03A6780 for ; Wed, 14 May 2008 15:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.003 X-Spam-Level: X-Spam-Status: No, score=-1.003 tagged_above=-999 required=5 tests=[AWL=0.200, 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 DkXlSrdJ8DU4 for ; Wed, 14 May 2008 15:23:35 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 7B5E13A686A for ; Wed, 14 May 2008 15:23:35 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_17_37_36 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, 14 May 2008 17:37:36 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 17:23:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 17:23:34 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci18QUcKYWmaHwgQEGAMWqH9hQRrAABH9vAAAaK1HA= References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com><17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> From: "Dawson, Martin" To: , , , X-OriginalArrivalTime: 14 May 2008 22:23:35.0533 (UTC) FILETIME=[266B61D0:01C8B611] Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Sure - but either the enterprise is small/constrained as Ted describes - and the home dial strings correspond with the local dial strings anyway - or it supports use cases where the users could be dialing from arbitrary global jurisdictions in which case it's not really any different to a VSP. Either the device has explicitly indicated to the proxy that it's requesting an emergency call (in which case, the proxy will want to go straight to LoST for the destination URI - and not care about dial strings) or there is nothing in the call signalling indicating that it's an emergency call and the proxy will have to decide based on the dial strings. In the latter case, unless LoST is going to be queried for every call (even leaving aside the question of whether location might be in every call), the proxy isn't in a position to recognize anything but its preconfigured emergency codes. That's the catch-22 I referred to. I don't think the intent is for proxies to query LoST on every call is it? Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of hannes.tschofenig@nsn.com Sent: Thursday, 15 May 2008 5:07 AM To: hardie@qualcomm.com; hgs@cs.columbia.edu; br@brianrosen.net Cc: ecrit@ietf.org Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Yep. The enterprise case is a more restrictive case than the 3GPP IMS scenario since in IMS one would talk to a proxy associated with the access even when you are roaming. Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of ext Ted Hardie >Sent: 14 May, 2008 21:32 >To: Henning Schulzrinne; Brian Rosen >Cc: 'ECRIT' >Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > >At 7:55 AM -0700 5/14/08, Henning Schulzrinne wrote: >>I'm guessing you are assuming that the proxy is somehow >configured with >>the devices home location. (We probably don't want the proxy to >>recognize dial strings local to its physical location, unless >it knows >>that all of its customers reside in the same area. In some >cases, that >>may be true, e.g., because the VSP only serves customers in one >>country.) > >I had been thinking that would be the case for many >enterprise-as-VSP cases, since they would know whether or not >mobile devices could be connected to the network or not (for >example, enterprises with no VPN connecitivity or which did >not permit VPN devices to use the telephony service). Would >that fit with your thinking? > > Ted > > > > >> >>On May 14, 2008, at 10:11 AM, Brian Rosen wrote: >> >>> Well, yes. It's actually very hard for a proxy to recognize local >>> dial strings, because, in general, it doesn't know where the device >>> is, so it can't determine what the local dial strings are, whether >>> the device is location literate or not. >> >>_______________________________________________ >>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 ecrit-bounces@ietf.org Wed May 14 15:33:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51703A6780; Wed, 14 May 2008 15:33:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BD253A6812 for ; Wed, 14 May 2008 15:33:44 -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 6ZrI5RcXiObe for ; Wed, 14 May 2008 15:33:43 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 380F53A63D3 for ; Wed, 14 May 2008 15:33:43 -0700 (PDT) Received: from dyn-209-2-214-54.dyn.columbia.edu (dyn-209-2-214-54.dyn.columbia.edu [209.2.214.54]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m4EMWvDj028504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 May 2008 18:32:57 -0400 (EDT) Message-Id: <93ADC004-771E-41A2-B8F1-09086D405D29@cs.columbia.edu> From: Henning Schulzrinne To: Ted Hardie In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 14 May 2008 18:32:57 -0400 References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com ><0c8701c8b513 $85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com> <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> <0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com> <008d01c8b5cb$4698b2a0$250d0d0a@cisco.com> <0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, it would work for the enterprise case you mention. In other cases, a proxy would have to detect the presence of location information and then do dial string detection via LoST, under the assumption that emergency calls have location information and "normal" calls do not. Not a particularly pleasant thought. Henning On May 14, 2008, at 2:32 PM, Ted Hardie wrote: > At 7:55 AM -0700 5/14/08, Henning Schulzrinne wrote: >> I'm guessing you are assuming that the proxy is somehow configured >> with the devices home location. (We probably don't want the proxy to >> recognize dial strings local to its physical location, unless it >> knows >> that all of its customers reside in the same area. In some cases, >> that >> may be true, e.g., because the VSP only serves customers in one >> country.) > > I had been thinking that would be the case for many enterprise-as-VSP > cases, since they would know whether or not mobile devices could be > connected to the network or not (for example, enterprises with no > VPN connecitivity or which did not permit VPN devices to use the > telephony > service). Would that fit with your thinking? > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:17:25 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5443A6A1E; Wed, 14 May 2008 16:17:25 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 368353A6811 for ; Wed, 14 May 2008 16:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 gUQlsx6+aNi3 for ; Wed, 14 May 2008 16:17:19 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 2F0663A6991 for ; Wed, 14 May 2008 16:17:19 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_18_31_06 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, 14 May 2008 18:31:06 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 18:17:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 18:17:02 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci2D9HIRzXtLGaYQs+hLHazR7oGXgABkwUg References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com ><0c8701c8b513 $85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640f a8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b 2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> From: "Winterbottom, James" To: "Ted Hardie" , "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 14 May 2008 23:17:05.0787 (UTC) FILETIME=[9FE144B0:01C8B618] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Ted, My point is that this doesn't work in a 3GPP case at all. In the 3GPP case you need to have local dial strings. To change the setting a little for 3GPP(2): Veronica only handles calls made in Vermont. Veronica has special relationships with VSPs in other places. These relationships allow Veronica's customers to make calls using different VSPs when the customer is near that VSP. Similarly, Veronica may allow customers of a different VSP to make calls through her equipment if they are making a call while visiting Vermont. The classic roaming agreement. Veronica has a roaming agreement with Sandy in Sierra Leone. Andy's softphone doesn't register with Veronica, it registers instead with Sandy. Andy's call therefore goes to Sandy. If 911 in Sierra Leone means directory assistance, then Andy is getting to get a bit of shock when he is calling for emergency assistance. Sandy was expecting 655 for emergency calls. Factual calling codes aside for a minute, my points are these: Dial strings are used to map to service URNs. The dial string used needs to be consistent with where that mapping happens. If the mapping happens in Vermont, then the dial string needs to be a Vermont recognized dial string. If the mapping happens in Sierra Leone, then the dial string needs to be a Sierra Leone recognized dial string. This is the case regardless of where the call is ultimately terminated. If the calling device is doing the mapping, then why does it care what the local dial string is at all? Ultimately, the only case where local dial strings matter is where the service mapping is performed in the network local to the caller. 3GPP(2) are the largest users of this type of deployment, local dial strings are large irrelevant in the home network mapping and device mapping scenarios. Cheers James > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Thursday, 15 May 2008 8:14 AM > To: Winterbottom, James; Henning Schulzrinne; Brian Rosen > Cc: ECRIT > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > At 2:40 PM -0700 5/14/08, Winterbottom, James wrote: > >* > >Andy travels Sierra-Leone > >Andy Connects to the local access network > >Andy gets a location > >Andy's room gets broken into, and he calls Veronica! > >Andy is in a panic, so he calls 911 (which is a good thing since that is > all that Veronica understands) > > > >I expect this just to work, and this is why. > >Veronica has a simple trigger looking for 911 > >Veronica can then have a standard query set to send to Lucy > >Location (from call) + fixed service URN (sos.. etc) > >Lucy manages the mapping to destination URI > >Andy's call gets directed to the local emergency centre > > > >Here is where it breaks down > > > >The local emergency centre doesn't understand a word of english > > > > English is the official language of Sierra Leone, so this seems unlikely. > > On another note, would you mind relating this interesting tale of Andy, > Veronic, and Lucy back to 3GPP2's liaison statement? Just to help those > of us having trouble keeping up. > > thanks, > Ted > > > > > > > > >In this scenario I don't need local dial-string, at all ever. > >I believe that for quite some time this will be a very common > configuration. > >Hence local dial strings are a may, not a must from an end-point needing > to understand them point of view. > > > >Cheers > >James > > > > > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > >Sent: Wed 5/14/2008 9:55 AM > >To: Brian Rosen > >Cc: 'ECRIT' > >Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > >I'm guessing you are assuming that the proxy is somehow configured > >with the devices home location. (We probably don't want the proxy to > >recognize dial strings local to its physical location, unless it knows > >that all of its customers reside in the same area. In some cases, that > >may be true, e.g., because the VSP only serves customers in one > >country.) > > > >On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > >> Well, yes. It's actually very hard for a proxy to recognize local > >> dial > >> strings, because, in general, it doesn't know where the device is, > >> so it > >> can't determine what the local dial strings are, whether the device is > >> location literate or not. > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[mf2] > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:19:07 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8AC73A6891; Wed, 14 May 2008 16:19:07 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1961F3A6823 for ; Wed, 14 May 2008 16:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=-0.130, 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 ePTQ07c2Nghb for ; Wed, 14 May 2008 16:19:05 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id E95AC3A6891 for ; Wed, 14 May 2008 16:19:04 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JwQEr-0007Cb-Kt; Wed, 14 May 2008 18:18:25 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Henning Schulzrinne'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> Date: Wed, 14 May 2008 19:18:31 -0400 Message-ID: <001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4IAAOh9SA= In-Reply-To: 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Police in Sierra Leone is 999. If Andy calls 999, it MUST be an emergency call. The fact that 9-1-1 worked may be a good thing, but it's not required to work. 9-9-9 is. I have no problem if Veronica implements 9-1-1 as an emergency call for Andy while he is traveling to Sierra Leone. I require, somehow, between Andy and Veronica, that 9-9-9 work. I recommend that Andy's device do a LoST query with the location it got, find out that 999 (and 019, for fire) is the dial string, and recognize it as such. Brian -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Wednesday, May 14, 2008 5:40 PM To: Henning Schulzrinne; Brian Rosen Cc: ECRIT Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] *BUZZZ** Okay let me try again! I think you are making a leap here which isn't required. Let me try and describe the scenario and configuration first, and then you can try and tell me why I need local dial strings. Andy is caller. Andy uses a VSP called Veronica Veronica is based in Vermont Veronica recognizes the emergency dial string 911. For the point of the argument, let's say that that is all that Veronica recognizes. Veronica has a pet LoST server Lucy Veronica will send any mapping requests to Lucy Lucy is responsible to find the correct mapping. Andy travels Sierra-Leone Andy Connects to the local access network Andy gets a location Andy's room gets broken into, and he calls Veronica! Andy is in a panic, so he calls 911 (which is a good thing since that is all that Veronica understands) I expect this just to work, and this is why. Veronica has a simple trigger looking for 911 Veronica can then have a standard query set to send to Lucy Location (from call) + fixed service URN (sos.. etc) Lucy manages the mapping to destination URI Andy's call gets directed to the local emergency centre Here is where it breaks down The local emergency centre doesn't understand a word of english In this scenario I don't need local dial-string, at all ever. I believe that for quite some time this will be a very common configuration. Hence local dial strings are a may, not a must from an end-point needing to understand them point of view. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne Sent: Wed 5/14/2008 9:55 AM To: Brian Rosen Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] I'm guessing you are assuming that the proxy is somehow configured with the devices home location. (We probably don't want the proxy to recognize dial strings local to its physical location, unless it knows that all of its customers reside in the same area. In some cases, that may be true, e.g., because the VSP only serves customers in one country.) On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > Well, yes. It's actually very hard for a proxy to recognize local > dial > strings, because, in general, it doesn't know where the device is, > so it > can't determine what the local dial strings are, whether the device is > location literate or not. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:20:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ECEA3A69C5; Wed, 14 May 2008 16:20:36 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2AF3A69C5 for ; Wed, 14 May 2008 16:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=-0.122, 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 8ntdJ-NElCbN for ; Wed, 14 May 2008 16:20:31 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id DEDDC3A69BA for ; Wed, 14 May 2008 16:20:30 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JwQGF-0007KJ-QX; Wed, 14 May 2008 18:19:52 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Winterbottom, James'" , "'Henning Schulzrinne'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com ><0c8701c8b513 $85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640f a8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b 2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> Date: Wed, 14 May 2008 19:19:57 -0400 Message-ID: <001b01c8b619$080fccf0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci2D9VVqyjNWRDlQTqUPdxeOMkgMQACQNsA In-Reply-To: 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The liaison statement claims that ED-5/SP-4 (which is "Local dial strings MUST be recognized") is not a requirement. Brian -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Wednesday, May 14, 2008 6:14 PM To: Winterbottom, James; Henning Schulzrinne; Brian Rosen Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] At 2:40 PM -0700 5/14/08, Winterbottom, James wrote: >* >Andy travels Sierra-Leone >Andy Connects to the local access network >Andy gets a location >Andy's room gets broken into, and he calls Veronica! >Andy is in a panic, so he calls 911 (which is a good thing since that is all that Veronica understands) > >I expect this just to work, and this is why. >Veronica has a simple trigger looking for 911 >Veronica can then have a standard query set to send to Lucy >Location (from call) + fixed service URN (sos.. etc) >Lucy manages the mapping to destination URI >Andy's call gets directed to the local emergency centre > >Here is where it breaks down > >The local emergency centre doesn't understand a word of english > English is the official language of Sierra Leone, so this seems unlikely. On another note, would you mind relating this interesting tale of Andy, Veronic, and Lucy back to 3GPP2's liaison statement? Just to help those of us having trouble keeping up. thanks, Ted >In this scenario I don't need local dial-string, at all ever. >I believe that for quite some time this will be a very common configuration. >Hence local dial strings are a may, not a must from an end-point needing to understand them point of view. > >Cheers >James > > > >-----Original Message----- >From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne >Sent: Wed 5/14/2008 9:55 AM >To: Brian Rosen >Cc: 'ECRIT' >Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > >I'm guessing you are assuming that the proxy is somehow configured >with the devices home location. (We probably don't want the proxy to >recognize dial strings local to its physical location, unless it knows >that all of its customers reside in the same area. In some cases, that >may be true, e.g., because the VSP only serves customers in one >country.) > >On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > >> Well, yes. It's actually very hard for a proxy to recognize local >> dial >> strings, because, in general, it doesn't know where the device is, >> so it >> can't determine what the local dial strings are, whether the device is >> location literate or not. > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > >--------------------------------------------------------------------------- --------------------- >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >--------------------------------------------------------------------------- --------------------- >[mf2] > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:22:38 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7386A3A6823; Wed, 14 May 2008 16:22:38 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9413A6811 for ; Wed, 14 May 2008 16:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.273 X-Spam-Level: X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 IakGXKFfy60W for ; Wed, 14 May 2008 16:22:35 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id C869F3A67FF for ; Wed, 14 May 2008 16:22:35 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_18_36_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); Wed, 14 May 2008 18:36:30 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 18:22:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 18:22:28 -0500 Message-ID: In-Reply-To: <001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4IAAOh9SAAADyXgA== References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> <001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 14 May 2008 23:22:30.0202 (UTC) FILETIME=[613F11A0:01C8B619] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Why? The solution I have describe is: 1) more simple 2) Works every time 3) Only requires Andy to remember things that are close to home in a stressful situation when try to remember something different is hard. Personally I see the solution being described below as providing complexity for complexities sake. Yes, it is a solution, and yes it should be catered, but that only makes the requirement a MAY and not a MUST. Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 15 May 2008 9:19 AM > To: Winterbottom, James; 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > Police in Sierra Leone is 999. If Andy calls 999, it MUST be an > emergency > call. The fact that 9-1-1 worked may be a good thing, but it's not > required > to work. 9-9-9 is. > > I have no problem if Veronica implements 9-1-1 as an emergency call for > Andy > while he is traveling to Sierra Leone. I require, somehow, between Andy > and > Veronica, that 9-9-9 work. I recommend that Andy's device do a LoST query > with the location it got, find out that 999 (and 019, for fire) is the > dial > string, and recognize it as such. > > Brian > > > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, May 14, 2008 5:40 PM > To: Henning Schulzrinne; Brian Rosen > Cc: ECRIT > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > *BUZZZ** Okay let me try again! > > I think you are making a leap here which isn't required. > Let me try and describe the scenario and configuration first, and then you > can try and tell me why I need local dial strings. > > > Andy is caller. > Andy uses a VSP called Veronica > Veronica is based in Vermont > Veronica recognizes the emergency dial string 911. For the point of the > argument, let's say that that is all that Veronica recognizes. > Veronica has a pet LoST server Lucy > Veronica will send any mapping requests to Lucy > Lucy is responsible to find the correct mapping. > > Andy travels Sierra-Leone > Andy Connects to the local access network > Andy gets a location > Andy's room gets broken into, and he calls Veronica! > Andy is in a panic, so he calls 911 (which is a good thing since that is > all > that Veronica understands) > > I expect this just to work, and this is why. > Veronica has a simple trigger looking for 911 > Veronica can then have a standard query set to send to Lucy > Location (from call) + fixed service URN (sos.. etc) > Lucy manages the mapping to destination URI > Andy's call gets directed to the local emergency centre > > Here is where it breaks down > > The local emergency centre doesn't understand a word of english > > > In this scenario I don't need local dial-string, at all ever. > I believe that for quite some time this will be a very common > configuration. > Hence local dial strings are a may, not a must from an end-point needing > to > understand them point of view. > > Cheers > James > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > Sent: Wed 5/14/2008 9:55 AM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > I'm guessing you are assuming that the proxy is somehow configured > with the devices home location. (We probably don't want the proxy to > recognize dial strings local to its physical location, unless it knows > that all of its customers reside in the same area. In some cases, that > may be true, e.g., because the VSP only serves customers in one > country.) > > On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > Well, yes. It's actually very hard for a proxy to recognize local > > dial > > strings, because, in general, it doesn't know where the device is, > > so it > > can't determine what the local dial strings are, whether the device is > > location literate or not. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:25:12 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9251D3A6931; Wed, 14 May 2008 16:25:12 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F78B3A6A24 for ; Wed, 14 May 2008 16:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 prQN6fiukDIE for ; Wed, 14 May 2008 16:25:09 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 15BEE3A6931 for ; Wed, 14 May 2008 16:25:09 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_18_39_06 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, 14 May 2008 18:39:06 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 18:25:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 18:25:02 -0500 Message-ID: In-Reply-To: <001b01c8b619$080fccf0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci2D9VVqyjNWRDlQTqUPdxeOMkgMQACQNsAAAAjlOA= References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com ><0c8701c8b513 $85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640f a8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b 2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> <001b01c8b619$080fccf0$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Ted Hardie" , "Henning Schulzrinne" X-OriginalArrivalTime: 14 May 2008 23:25:05.0425 (UTC) FILETIME=[BDC43810:01C8B619] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I agree, and I think I said that it was totally absurd for 3GPP(2) to say this. I don't however agree that the ECRIT requirement is a MUST, unless by local you mean local to the location of the VSP handling the call. I think you mean local to the call originator and in this case I cannot agree with the requirement as written. Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 15 May 2008 9:20 AM > To: 'Ted Hardie'; Winterbottom, James; 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > The liaison statement claims that ED-5/SP-4 (which is "Local dial strings > MUST be recognized") is not a requirement. > > Brian > > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, May 14, 2008 6:14 PM > To: Winterbottom, James; Henning Schulzrinne; Brian Rosen > Cc: ECRIT > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > At 2:40 PM -0700 5/14/08, Winterbottom, James wrote: > >* > >Andy travels Sierra-Leone > >Andy Connects to the local access network > >Andy gets a location > >Andy's room gets broken into, and he calls Veronica! > >Andy is in a panic, so he calls 911 (which is a good thing since that is > all that Veronica understands) > > > >I expect this just to work, and this is why. > >Veronica has a simple trigger looking for 911 > >Veronica can then have a standard query set to send to Lucy > >Location (from call) + fixed service URN (sos.. etc) > >Lucy manages the mapping to destination URI > >Andy's call gets directed to the local emergency centre > > > >Here is where it breaks down > > > >The local emergency centre doesn't understand a word of english > > > > English is the official language of Sierra Leone, so this seems unlikely. > > On another note, would you mind relating this interesting tale of Andy, > Veronic, and Lucy back to 3GPP2's liaison statement? Just to help those > of us having trouble keeping up. > > thanks, > Ted > > > > > > > > >In this scenario I don't need local dial-string, at all ever. > >I believe that for quite some time this will be a very common > configuration. > >Hence local dial strings are a may, not a must from an end-point needing > to > understand them point of view. > > > >Cheers > >James > > > > > > > >-----Original Message----- > >From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > >Sent: Wed 5/14/2008 9:55 AM > >To: Brian Rosen > >Cc: 'ECRIT' > >Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > >I'm guessing you are assuming that the proxy is somehow configured > >with the devices home location. (We probably don't want the proxy to > >recognize dial strings local to its physical location, unless it knows > >that all of its customers reside in the same area. In some cases, that > >may be true, e.g., because the VSP only serves customers in one > >country.) > > > >On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > >> Well, yes. It's actually very hard for a proxy to recognize local > >> dial > >> strings, because, in general, it doesn't know where the device is, > >> so it > >> can't determine what the local dial strings are, whether the device is > >> location literate or not. > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > > > > >----------------------------------------------------------------------- -- > -- > --------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >----------------------------------------------------------------------- -- > -- > --------------------- > >[mf2] > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:32:01 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342C03A6823; Wed, 14 May 2008 16:32:01 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70643A6830 for ; Wed, 14 May 2008 16:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFudRu-p1aOn for ; Wed, 14 May 2008 16:31:57 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id AA12C3A67FF for ; Wed, 14 May 2008 16:31:57 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JwQRq-000897-Rr; Wed, 14 May 2008 18:31:51 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Henning Schulzrinne'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> <001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com> Date: Wed, 14 May 2008 19:31:56 -0400 Message-ID: <001c01c8b61a$b4a0c860$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4IAAOh9SAAADyXgAAAN1/g In-Reply-To: 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Because the PSAPs, and in some cases, regulation, requires it. It's that simple. It doesn't really matter if you think, or even if I think, it makes more sense to require home dial strings work. Local dial strings MUST work. We could have a discussion of whether home dial strings MUST work. We could decide that they should. The PSAPs, and the regulators, wouldn't care. However, we can't decide that local dial string support is optional. It's not, it's required. When you are in the U.S., 9-1-1 MUST work. When you are in Sierra Leone, 9-9-9 MUST work. Among other things, if Jasmine, a native Sierra Leonian, picks up Andy's phone while he is in Sierra Leone and dials 9-9-9 for him, it has to work. Brian -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Wednesday, May 14, 2008 7:22 PM To: Brian Rosen; Henning Schulzrinne Cc: ECRIT Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Why? The solution I have describe is: 1) more simple 2) Works every time 3) Only requires Andy to remember things that are close to home in a stressful situation when try to remember something different is hard. Personally I see the solution being described below as providing complexity for complexities sake. Yes, it is a solution, and yes it should be catered, but that only makes the requirement a MAY and not a MUST. Cheers James > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 15 May 2008 9:19 AM > To: Winterbottom, James; 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > Police in Sierra Leone is 999. If Andy calls 999, it MUST be an > emergency > call. The fact that 9-1-1 worked may be a good thing, but it's not > required > to work. 9-9-9 is. > > I have no problem if Veronica implements 9-1-1 as an emergency call for > Andy > while he is traveling to Sierra Leone. I require, somehow, between Andy > and > Veronica, that 9-9-9 work. I recommend that Andy's device do a LoST query > with the location it got, find out that 999 (and 019, for fire) is the > dial > string, and recognize it as such. > > Brian > > > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, May 14, 2008 5:40 PM > To: Henning Schulzrinne; Brian Rosen > Cc: ECRIT > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > *BUZZZ** Okay let me try again! > > I think you are making a leap here which isn't required. > Let me try and describe the scenario and configuration first, and then you > can try and tell me why I need local dial strings. > > > Andy is caller. > Andy uses a VSP called Veronica > Veronica is based in Vermont > Veronica recognizes the emergency dial string 911. For the point of the > argument, let's say that that is all that Veronica recognizes. > Veronica has a pet LoST server Lucy > Veronica will send any mapping requests to Lucy > Lucy is responsible to find the correct mapping. > > Andy travels Sierra-Leone > Andy Connects to the local access network > Andy gets a location > Andy's room gets broken into, and he calls Veronica! > Andy is in a panic, so he calls 911 (which is a good thing since that is > all > that Veronica understands) > > I expect this just to work, and this is why. > Veronica has a simple trigger looking for 911 > Veronica can then have a standard query set to send to Lucy > Location (from call) + fixed service URN (sos.. etc) > Lucy manages the mapping to destination URI > Andy's call gets directed to the local emergency centre > > Here is where it breaks down > > The local emergency centre doesn't understand a word of english > > > In this scenario I don't need local dial-string, at all ever. > I believe that for quite some time this will be a very common > configuration. > Hence local dial strings are a may, not a must from an end-point needing > to > understand them point of view. > > Cheers > James > > > > -----Original Message----- > From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > Sent: Wed 5/14/2008 9:55 AM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > I'm guessing you are assuming that the proxy is somehow configured > with the devices home location. (We probably don't want the proxy to > recognize dial strings local to its physical location, unless it knows > that all of its customers reside in the same area. In some cases, that > may be true, e.g., because the VSP only serves customers in one > country.) > > On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > Well, yes. It's actually very hard for a proxy to recognize local > > dial > > strings, because, in general, it doesn't know where the device is, > > so it > > can't determine what the local dial strings are, whether the device is > > location literate or not. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:36:41 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E2D3A6830; Wed, 14 May 2008 16:36:41 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5048F3A6830 for ; Wed, 14 May 2008 16:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDSd-y-pJ73r for ; Wed, 14 May 2008 16:36:38 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 0FC3E3A6811 for ; Wed, 14 May 2008 16:36:38 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_18_50_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); Wed, 14 May 2008 18:50:35 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 18:36:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 18:36:32 -0500 Message-ID: In-Reply-To: <001c01c8b61a$b4a0c860$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4IAAOh9SAAADyXgAAAN1/gAABRnNA= References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> <001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com> <001c01c8b61a$b4a0c860$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 14 May 2008 23:36:34.0708 (UTC) FILETIME=[589C7540:01C8B61B] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am sorry but this work for me because I may not use a dial string at all, I may just use the service URN. This requirement is a may. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 15 May 2008 9:32 AM > To: Winterbottom, James; 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > Because the PSAPs, and in some cases, regulation, requires it. > > It's that simple. > > It doesn't really matter if you think, or even if I think, it makes more > sense to require home dial strings work. Local dial strings MUST work. > > We could have a discussion of whether home dial strings MUST work. We > could > decide that they should. The PSAPs, and the regulators, wouldn't care. > However, we can't decide that local dial string support is optional. It's > not, it's required. > > When you are in the U.S., 9-1-1 MUST work. > When you are in Sierra Leone, 9-9-9 MUST work. > > Among other things, if Jasmine, a native Sierra Leonian, picks up Andy's > phone while he is in Sierra Leone and dials 9-9-9 for him, it has to work. > > Brian > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, May 14, 2008 7:22 PM > To: Brian Rosen; Henning Schulzrinne > Cc: ECRIT > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > Why? > > The solution I have describe is: > 1) more simple > 2) Works every time > 3) Only requires Andy to remember things that are close to home in a > stressful situation when try to remember something different is hard. > > Personally I see the solution being described below as providing > complexity for complexities sake. Yes, it is a solution, and yes it > should be catered, but that only makes the requirement a MAY and not a > MUST. > > Cheers > James > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 15 May 2008 9:19 AM > > To: Winterbottom, James; 'Henning Schulzrinne' > > Cc: 'ECRIT' > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > Police in Sierra Leone is 999. If Andy calls 999, it MUST be an > > emergency > > call. The fact that 9-1-1 worked may be a good thing, but it's not > > required > > to work. 9-9-9 is. > > > > I have no problem if Veronica implements 9-1-1 as an emergency call > for > > Andy > > while he is traveling to Sierra Leone. I require, somehow, between > Andy > > and > > Veronica, that 9-9-9 work. I recommend that Andy's device do a LoST > query > > with the location it got, find out that 999 (and 019, for fire) is the > > dial > > string, and recognize it as such. > > > > Brian > > > > > > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Wednesday, May 14, 2008 5:40 PM > > To: Henning Schulzrinne; Brian Rosen > > Cc: ECRIT > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > *BUZZZ** Okay let me try again! > > > > I think you are making a leap here which isn't required. > > Let me try and describe the scenario and configuration first, and then > you > > can try and tell me why I need local dial strings. > > > > > > Andy is caller. > > Andy uses a VSP called Veronica > > Veronica is based in Vermont > > Veronica recognizes the emergency dial string 911. For the point of > the > > argument, let's say that that is all that Veronica recognizes. > > Veronica has a pet LoST server Lucy > > Veronica will send any mapping requests to Lucy > > Lucy is responsible to find the correct mapping. > > > > Andy travels Sierra-Leone > > Andy Connects to the local access network > > Andy gets a location > > Andy's room gets broken into, and he calls Veronica! > > Andy is in a panic, so he calls 911 (which is a good thing since that > is > > all > > that Veronica understands) > > > > I expect this just to work, and this is why. > > Veronica has a simple trigger looking for 911 > > Veronica can then have a standard query set to send to Lucy > > Location (from call) + fixed service URN (sos.. etc) > > Lucy manages the mapping to destination URI > > Andy's call gets directed to the local emergency centre > > > > Here is where it breaks down > > > > The local emergency centre doesn't understand a word of english > > > > > > In this scenario I don't need local dial-string, at all ever. > > I believe that for quite some time this will be a very common > > configuration. > > Hence local dial strings are a may, not a must from an end-point > needing > > to > > understand them point of view. > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > > Sent: Wed 5/14/2008 9:55 AM > > To: Brian Rosen > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > I'm guessing you are assuming that the proxy is somehow configured > > with the devices home location. (We probably don't want the proxy to > > recognize dial strings local to its physical location, unless it knows > > that all of its customers reside in the same area. In some cases, that > > may be true, e.g., because the VSP only serves customers in one > > country.) > > > > On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > > > Well, yes. It's actually very hard for a proxy to recognize local > > > dial > > > strings, because, in general, it doesn't know where the device is, > > > so it > > > can't determine what the local dial strings are, whether the device > is > > > location literate or not. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > [mf2] > > > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:43:32 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48483A6A28; Wed, 14 May 2008 16:43:32 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD69E3A6A2A for ; Wed, 14 May 2008 16:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWGgrcWzUQSS for ; Wed, 14 May 2008 16:43:29 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 460463A6781 for ; Wed, 14 May 2008 16:43:29 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_18_57_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); Wed, 14 May 2008 18:57:30 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 18:43:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 18:43:27 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4IAAOh9SAAADyXgAAAN1/gAABRnNAAAC3qoA== References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com><17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu><001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com><001c01c8b61a$b4a0c860$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Winterbottom, James" , "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 14 May 2008 23:43:29.0843 (UTC) FILETIME=[500D0830:01C8B61C] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org And to further add to this. What you are saying below is that in some national variants, the local emergency dial string is required by the PSAP. What do you expect to be the behaviour if this is not provided, will you simply not accept the call? I believe that this requirement is a MAY, but I would settle for a SHOULD. Under no circumstance is it a MUST as it is not enforceable or required in the majority of cases. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: Thursday, 15 May 2008 9:37 AM > To: Brian Rosen; Henning Schulzrinne > Cc: ECRIT > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > I am sorry but this work for me because I may not use a dial string at > all, I may just use the service URN. This requirement is a may. > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 15 May 2008 9:32 AM > > To: Winterbottom, James; 'Henning Schulzrinne' > > Cc: 'ECRIT' > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > Because the PSAPs, and in some cases, regulation, requires it. > > > > It's that simple. > > > > It doesn't really matter if you think, or even if I think, it makes > more > > sense to require home dial strings work. Local dial strings MUST > work. > > > > We could have a discussion of whether home dial strings MUST work. We > > could > > decide that they should. The PSAPs, and the regulators, wouldn't > care. > > However, we can't decide that local dial string support is optional. > It's > > not, it's required. > > > > When you are in the U.S., 9-1-1 MUST work. > > When you are in Sierra Leone, 9-9-9 MUST work. > > > > Among other things, if Jasmine, a native Sierra Leonian, picks up > Andy's > > phone while he is in Sierra Leone and dials 9-9-9 for him, it has to > work. > > > > Brian > > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Wednesday, May 14, 2008 7:22 PM > > To: Brian Rosen; Henning Schulzrinne > > Cc: ECRIT > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > Why? > > > > The solution I have describe is: > > 1) more simple > > 2) Works every time > > 3) Only requires Andy to remember things that are close to home in a > > stressful situation when try to remember something different is hard. > > > > Personally I see the solution being described below as providing > > complexity for complexities sake. Yes, it is a solution, and yes it > > should be catered, but that only makes the requirement a MAY and not a > > MUST. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, 15 May 2008 9:19 AM > > > To: Winterbottom, James; 'Henning Schulzrinne' > > > Cc: 'ECRIT' > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > Police in Sierra Leone is 999. If Andy calls 999, it MUST be an > > > emergency > > > call. The fact that 9-1-1 worked may be a good thing, but it's not > > > required > > > to work. 9-9-9 is. > > > > > > I have no problem if Veronica implements 9-1-1 as an emergency call > > for > > > Andy > > > while he is traveling to Sierra Leone. I require, somehow, between > > Andy > > > and > > > Veronica, that 9-9-9 work. I recommend that Andy's device do a LoST > > query > > > with the location it got, find out that 999 (and 019, for fire) is > the > > > dial > > > string, and recognize it as such. > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Wednesday, May 14, 2008 5:40 PM > > > To: Henning Schulzrinne; Brian Rosen > > > Cc: ECRIT > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > *BUZZZ** Okay let me try again! > > > > > > I think you are making a leap here which isn't required. > > > Let me try and describe the scenario and configuration first, and > then > > you > > > can try and tell me why I need local dial strings. > > > > > > > > > Andy is caller. > > > Andy uses a VSP called Veronica > > > Veronica is based in Vermont > > > Veronica recognizes the emergency dial string 911. For the point of > > the > > > argument, let's say that that is all that Veronica recognizes. > > > Veronica has a pet LoST server Lucy > > > Veronica will send any mapping requests to Lucy > > > Lucy is responsible to find the correct mapping. > > > > > > Andy travels Sierra-Leone > > > Andy Connects to the local access network > > > Andy gets a location > > > Andy's room gets broken into, and he calls Veronica! > > > Andy is in a panic, so he calls 911 (which is a good thing since > that > > is > > > all > > > that Veronica understands) > > > > > > I expect this just to work, and this is why. > > > Veronica has a simple trigger looking for 911 > > > Veronica can then have a standard query set to send to Lucy > > > Location (from call) + fixed service URN (sos.. etc) > > > Lucy manages the mapping to destination URI > > > Andy's call gets directed to the local emergency centre > > > > > > Here is where it breaks down > > > > > > The local emergency centre doesn't understand a word of english > > > > > > > > > In this scenario I don't need local dial-string, at all ever. > > > I believe that for quite some time this will be a very common > > > configuration. > > > Hence local dial strings are a may, not a must from an end-point > > needing > > > to > > > understand them point of view. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > > > Sent: Wed 5/14/2008 9:55 AM > > > To: Brian Rosen > > > Cc: 'ECRIT' > > > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > I'm guessing you are assuming that the proxy is somehow configured > > > with the devices home location. (We probably don't want the proxy to > > > recognize dial strings local to its physical location, unless it > knows > > > that all of its customers reside in the same area. In some cases, > that > > > may be true, e.g., because the VSP only serves customers in one > > > country.) > > > > > > On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > > > > > Well, yes. It's actually very hard for a proxy to recognize local > > > > dial > > > > strings, because, in general, it doesn't know where the device is, > > > > so it > > > > can't determine what the local dial strings are, whether the > device > > is > > > > location literate or not. > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > -- > > > -------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > -- > > > -------------------- > > > [mf2] > > > > > > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > [mf2] > > > > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:50:49 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C973A69BA; Wed, 14 May 2008 16:50:49 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2063A6823 for ; Wed, 14 May 2008 16:50:48 -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 oK+TjixHHn5k for ; Wed, 14 May 2008 16:50:47 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BF38B3A688A for ; Wed, 14 May 2008 16:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1210809050; x=1242345050; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20<48287 315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.n eustar.com=0D=0A=20><0c8701c8b513=0D=0A=20$85091470$64 0fa8c0@cis.neustar.com><00e701c8b560$18a00fd0 $250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640f =0D=0A=20a8c0@cis.neustar.com><0dad01c8b5ca$0 21a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b=0D =0A=202a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa 8c0@cis.neustar.com>=0D=0A=20<17AD9E1F-6FB5-4A2D-9BBC-EE2 306C271DE@cs.columbia.edu>=0D=0A=20=0D=0A=20=0D=0A=20|Date:=20Wed,=2014 =20May=202008=2016:50:43=20-0700|To:=20"Winterbottom,=20J ames"=20,=0D=0A=20=20=20 =20=20=20=20=20Henning=20Schulzrinne=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Brian=20Rosen=20< br@brianrosen.net>|From:=20Ted=20Hardie=20|Subject:=20RE:=20[Ecrit]=20[Fwd:=203GPP2=20TSG-X =20Corr=20to=20IETF=20re=20ECRIT/WGLC]|CC:=20ECRIT=20|Content-Type:=20text/plain=3B=20charset=3D"u s-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188,5295 "=3B=20a=3D"2960252"; bh=2eh5XEq06qefUewV17hqksRCJqZ0s3+KSv4OCexHRtY=; b=vnfnz1hAKoW5DPI+iE4Qo3Lf7RGahkpv3F2u3RfDOz+Spf3InNR3rtk0 HPwvULd/qmOx/lZ00y3MsIg92fbQ63gg6snWHg0lSkW5NA1jFT5FivGRz zgPbZDyvYRc3xwZzEeHtosWVdaj/Xv3q0SlhijXCDDbYRaVfxLuSXinL0 8=; X-IronPort-AV: E=McAfee;i="5100,188,5295"; a="2960252" 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; 14 May 2008 16:50:50 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4ENonTm030139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 May 2008 16:50:49 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4ENokGx021487 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 May 2008 16:50:47 -0700 Received: from [192.168.0.119] (10.50.16.105) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.263.0; Wed, 14 May 2008 16:50:46 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com ><0c8701c8b513 $85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640f a8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b 2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> Date: Wed, 14 May 2008 16:50:43 -0700 To: "Winterbottom, James" , Henning Schulzrinne , Brian Rosen From: Ted Hardie Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 4:17 PM -0700 5/14/08, Winterbottom, James wrote: > >Ultimately, the only case where local dial strings matter is where the >service mapping is performed in the network local to the caller. 3GPP(2) >are the largest users of this type of deployment, local dial strings are >large irrelevant in the home network mapping and device mapping >scenarios. But this is an ED requirement, right? It says: "Local dial strings MUST be recognized" but the ED marker makes that mean "by the edge device". In a network where the service mapping is performed in the network local to the caller, why does the edge device have to know it is a local dial string for an emergency service? Won't the network note that, and go forward from there (in a 3gpp2 network, doesn't it even determine the location for the terminal?) ? Sure, it is great if the edge device does realize that, and I'm happy LoST will provide that data. But it seems like the 999 call will go through in Sierra Leone if the local network does the mapping, whether the edge device recognizes it is a local emergency dial string or not. What am I missing? Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:54:22 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD4F3A686E; Wed, 14 May 2008 16:54:21 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8CD3A686E for ; Wed, 14 May 2008 16:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIcErQscSMu6 for ; Wed, 14 May 2008 16:54:17 -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 66D143A6823 for ; Wed, 14 May 2008 16:54:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,489,1204520400"; d="scan'208";a="8252751" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 May 2008 19:54:19 -0400 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 m4ENsJ0e004528; Wed, 14 May 2008 19:54:19 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4ENsJ5X000187; Wed, 14 May 2008 23:54:19 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 19:54:18 -0400 Received: from MLINSNER ([10.82.170.69]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 19:54:18 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com><17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu><001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com><001c01c8b61a$b4a0c860$640fa8c0@cis.neustar.com> Date: Wed, 14 May 2008 19:54:17 -0400 Message-ID: <001501c8b61d$d279bec0$45aa520a@MLINSNER> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4IAAOh9SAAADyXgAAAN1/gAABRnNAAAIgmIA== In-Reply-To: X-OriginalArrivalTime: 14 May 2008 23:54:18.0541 (UTC) FILETIME=[D2B47DD0:01C8B61D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8164; t=1210809259; x=1211673259; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20[Fwd=3A=203GPP2=20TSG-X=20Cor r=20to=20IETF=20re=20ECRIT/WGLC] |Sender:=20 |To:=20=22'Winterbottom,=20James'=22=20; bh=63CpSWqrm9bP/PoW8jdc4EWXkfB+1b9oxgPsC23Kb3Y=; b=PzWVqL5y5E/OsJrzpCtbPPIdV2Ls16pME+FiLP7RDTF2dAkA/wkw+9mYF1 GvLdwDankCRmpS61jmT8PC5Frmyk6qghZ2tA1De5oh6umDJsnBwjfJonVhuu 1kBauHCG60; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, You are comfortable denying Andy emergency care because he performed per the instructions on the back of his hotel room door that states: "In case of emergency, dial 9-9-9." ?? -Marc- -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Wednesday, May 14, 2008 7:37 PM To: Brian Rosen; Henning Schulzrinne Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] I am sorry but this work for me because I may not use a dial string at all, I may just use the service URN. This requirement is a may. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 15 May 2008 9:32 AM > To: Winterbottom, James; 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > Because the PSAPs, and in some cases, regulation, requires it. > > It's that simple. > > It doesn't really matter if you think, or even if I think, it makes more > sense to require home dial strings work. Local dial strings MUST work. > > We could have a discussion of whether home dial strings MUST work. We > could decide that they should. The PSAPs, and the regulators, > wouldn't care. > However, we can't decide that local dial string support is optional. It's > not, it's required. > > When you are in the U.S., 9-1-1 MUST work. > When you are in Sierra Leone, 9-9-9 MUST work. > > Among other things, if Jasmine, a native Sierra Leonian, picks up Andy's > phone while he is in Sierra Leone and dials 9-9-9 for him, it has to work. > > Brian > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, May 14, 2008 7:22 PM > To: Brian Rosen; Henning Schulzrinne > Cc: ECRIT > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > Why? > > The solution I have describe is: > 1) more simple > 2) Works every time > 3) Only requires Andy to remember things that are close to home in a > stressful situation when try to remember something different is hard. > > Personally I see the solution being described below as providing > complexity for complexities sake. Yes, it is a solution, and yes it > should be catered, but that only makes the requirement a MAY and not a > MUST. > > Cheers > James > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 15 May 2008 9:19 AM > > To: Winterbottom, James; 'Henning Schulzrinne' > > Cc: 'ECRIT' > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > Police in Sierra Leone is 999. If Andy calls 999, it MUST be an > > emergency > > call. The fact that 9-1-1 worked may be a good thing, but it's not > > required to work. 9-9-9 is. > > > > I have no problem if Veronica implements 9-1-1 as an emergency call > for > > Andy > > while he is traveling to Sierra Leone. I require, somehow, between > Andy > > and > > Veronica, that 9-9-9 work. I recommend that Andy's device do a LoST > query > > with the location it got, find out that 999 (and 019, for fire) is the > > dial > > string, and recognize it as such. > > > > Brian > > > > > > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Wednesday, May 14, 2008 5:40 PM > > To: Henning Schulzrinne; Brian Rosen > > Cc: ECRIT > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > *BUZZZ** Okay let me try again! > > > > I think you are making a leap here which isn't required. > > Let me try and describe the scenario and configuration first, and then > you > > can try and tell me why I need local dial strings. > > > > > > Andy is caller. > > Andy uses a VSP called Veronica > > Veronica is based in Vermont > > Veronica recognizes the emergency dial string 911. For the point of > the > > argument, let's say that that is all that Veronica recognizes. > > Veronica has a pet LoST server Lucy > > Veronica will send any mapping requests to Lucy Lucy is responsible > > to find the correct mapping. > > > > Andy travels Sierra-Leone > > Andy Connects to the local access network Andy gets a location > > Andy's room gets broken into, and he calls Veronica! > > Andy is in a panic, so he calls 911 (which is a good thing since that > is > > all > > that Veronica understands) > > > > I expect this just to work, and this is why. > > Veronica has a simple trigger looking for 911 Veronica can then have > > a standard query set to send to Lucy Location (from call) + fixed > > service URN (sos.. etc) Lucy manages the mapping to destination URI > > Andy's call gets directed to the local emergency centre > > > > Here is where it breaks down > > > > The local emergency centre doesn't understand a word of english > > > > > > In this scenario I don't need local dial-string, at all ever. > > I believe that for quite some time this will be a very common > > configuration. > > Hence local dial strings are a may, not a must from an end-point > needing > > to > > understand them point of view. > > > > Cheers > > James > > > > > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > > Sent: Wed 5/14/2008 9:55 AM > > To: Brian Rosen > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > I'm guessing you are assuming that the proxy is somehow configured > > with the devices home location. (We probably don't want the proxy to > > recognize dial strings local to its physical location, unless it knows > > that all of its customers reside in the same area. In some cases, that > > may be true, e.g., because the VSP only serves customers in one > > country.) > > > > On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > > > Well, yes. It's actually very hard for a proxy to recognize local > > > dial strings, because, in general, it doesn't know where the > > > device is, so it can't determine what the local dial strings are, > > > whether the device > is > > > location literate or not. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of this > > email is prohibited. > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > [mf2] > > > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original. Any unauthorized use of this email is > prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:58:54 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5AB3A67FF; Wed, 14 May 2008 16:58:54 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E863A67FF for ; Wed, 14 May 2008 16:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd2B0tJOpEvC for ; Wed, 14 May 2008 16:58:51 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id A3EC83A67C0 for ; Wed, 14 May 2008 16:58:51 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_19_12_48 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, 14 May 2008 19:12:48 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 18:58:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 18:58:46 -0500 Message-ID: In-Reply-To: <001501c8b61d$d279bec0$45aa520a@MLINSNER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4IAAOh9SAAADyXgAAAN1/gAABRnNAAAIgmIAAAJl2Q References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com><17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu><001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com><001c01c8b61a$b4a0c860$640fa8c0@cis.neustar.com> <001501c8b61d$d279bec0$45aa520a@MLINSNER> From: "Winterbottom, James" To: "Marc Linsner" X-OriginalArrivalTime: 14 May 2008 23:58:48.0039 (UTC) FILETIME=[73569F70:01C8B61E] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I am uncomfortable with expecting Veronica to know all codes for every service on Earth, which is what the extension to what is being requested. I expect Andy to use codes he knows and is familiar with when he is in a real pickle and doesn't want to have to think. I think that this is a may not a must, but I am offering a compromise of should. Cheers James > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, 15 May 2008 9:54 AM > To: Winterbottom, James > Cc: 'ECRIT' > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > James, > > You are comfortable denying Andy emergency care because he performed per > the > instructions on the back of his hotel room door that states: "In case of > emergency, dial 9-9-9." ?? > > -Marc- > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: Wednesday, May 14, 2008 7:37 PM > To: Brian Rosen; Henning Schulzrinne > Cc: ECRIT > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > I am sorry but this work for me because I may not use a dial string at > all, > I may just use the service URN. This requirement is a may. > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 15 May 2008 9:32 AM > > To: Winterbottom, James; 'Henning Schulzrinne' > > Cc: 'ECRIT' > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > Because the PSAPs, and in some cases, regulation, requires it. > > > > It's that simple. > > > > It doesn't really matter if you think, or even if I think, it makes > more > > sense to require home dial strings work. Local dial strings MUST > work. > > > > We could have a discussion of whether home dial strings MUST work. We > > could decide that they should. The PSAPs, and the regulators, > > wouldn't > care. > > However, we can't decide that local dial string support is optional. > It's > > not, it's required. > > > > When you are in the U.S., 9-1-1 MUST work. > > When you are in Sierra Leone, 9-9-9 MUST work. > > > > Among other things, if Jasmine, a native Sierra Leonian, picks up > Andy's > > phone while he is in Sierra Leone and dials 9-9-9 for him, it has to > work. > > > > Brian > > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Wednesday, May 14, 2008 7:22 PM > > To: Brian Rosen; Henning Schulzrinne > > Cc: ECRIT > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > Why? > > > > The solution I have describe is: > > 1) more simple > > 2) Works every time > > 3) Only requires Andy to remember things that are close to home in a > > stressful situation when try to remember something different is hard. > > > > Personally I see the solution being described below as providing > > complexity for complexities sake. Yes, it is a solution, and yes it > > should be catered, but that only makes the requirement a MAY and not a > > MUST. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, 15 May 2008 9:19 AM > > > To: Winterbottom, James; 'Henning Schulzrinne' > > > Cc: 'ECRIT' > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > Police in Sierra Leone is 999. If Andy calls 999, it MUST be an > > > emergency > > > call. The fact that 9-1-1 worked may be a good thing, but it's not > > > required to work. 9-9-9 is. > > > > > > I have no problem if Veronica implements 9-1-1 as an emergency call > > for > > > Andy > > > while he is traveling to Sierra Leone. I require, somehow, between > > Andy > > > and > > > Veronica, that 9-9-9 work. I recommend that Andy's device do a LoST > > query > > > with the location it got, find out that 999 (and 019, for fire) is > the > > > dial > > > string, and recognize it as such. > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Wednesday, May 14, 2008 5:40 PM > > > To: Henning Schulzrinne; Brian Rosen > > > Cc: ECRIT > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > *BUZZZ** Okay let me try again! > > > > > > I think you are making a leap here which isn't required. > > > Let me try and describe the scenario and configuration first, and > then > > you > > > can try and tell me why I need local dial strings. > > > > > > > > > Andy is caller. > > > Andy uses a VSP called Veronica > > > Veronica is based in Vermont > > > Veronica recognizes the emergency dial string 911. For the point of > > the > > > argument, let's say that that is all that Veronica recognizes. > > > Veronica has a pet LoST server Lucy > > > Veronica will send any mapping requests to Lucy Lucy is responsible > > > to find the correct mapping. > > > > > > Andy travels Sierra-Leone > > > Andy Connects to the local access network Andy gets a location > > > Andy's room gets broken into, and he calls Veronica! > > > Andy is in a panic, so he calls 911 (which is a good thing since > that > > is > > > all > > > that Veronica understands) > > > > > > I expect this just to work, and this is why. > > > Veronica has a simple trigger looking for 911 Veronica can then have > > > a standard query set to send to Lucy Location (from call) + fixed > > > service URN (sos.. etc) Lucy manages the mapping to destination URI > > > Andy's call gets directed to the local emergency centre > > > > > > Here is where it breaks down > > > > > > The local emergency centre doesn't understand a word of english > > > > > > > > > In this scenario I don't need local dial-string, at all ever. > > > I believe that for quite some time this will be a very common > > > configuration. > > > Hence local dial strings are a may, not a must from an end-point > > needing > > > to > > > understand them point of view. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > > > Sent: Wed 5/14/2008 9:55 AM > > > To: Brian Rosen > > > Cc: 'ECRIT' > > > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > I'm guessing you are assuming that the proxy is somehow configured > > > with the devices home location. (We probably don't want the proxy to > > > recognize dial strings local to its physical location, unless it > knows > > > that all of its customers reside in the same area. In some cases, > that > > > may be true, e.g., because the VSP only serves customers in one > > > country.) > > > > > > On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > > > > > Well, yes. It's actually very hard for a proxy to recognize local > > > > dial strings, because, in general, it doesn't know where the > > > > device is, so it can't determine what the local dial strings are, > > > > whether the > device > > is > > > > location literate or not. > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > -- > > > -------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of this > > > email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > -- > > > -------------------- > > > [mf2] > > > > > > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender immediately > > and delete the original. Any unauthorized use of this email is > > prohibited. > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > [mf2] > > > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately and > delete the original. Any unauthorized use of this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 16:59:11 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F293A686E; Wed, 14 May 2008 16:59:11 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC4C3A683C for ; Wed, 14 May 2008 16:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 AYB6fSV2Z2HD for ; Wed, 14 May 2008 16:59:09 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6847C3A67C0 for ; Wed, 14 May 2008 16:59:09 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_19_13_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, 14 May 2008 19:13:10 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 18:59:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 18:59:07 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci2HVhEq1xm4XSpQjKquFHIXuK/EQAAGfBQ References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com ><0c8701c8b513 $85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640f a8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b 2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com> <17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu> From: "Winterbottom, James" To: "Ted Hardie" , "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 14 May 2008 23:59:09.0633 (UTC) FILETIME=[80359B10:01C8B61E] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think what you are saying is fine. All I am saying is that that edge-devices don't always need to understand local dial strings, and that the requirement says that they have to. Cheers James > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Thursday, 15 May 2008 9:51 AM > To: Winterbottom, James; Henning Schulzrinne; Brian Rosen > Cc: ECRIT > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > At 4:17 PM -0700 5/14/08, Winterbottom, James wrote: > > > >Ultimately, the only case where local dial strings matter is where the > >service mapping is performed in the network local to the caller. 3GPP(2) > >are the largest users of this type of deployment, local dial strings are > >large irrelevant in the home network mapping and device mapping > >scenarios. > > > But this is an ED requirement, right? It says: > > "Local dial strings MUST be recognized" but the ED marker makes that > mean "by the edge device". In a network where the service mapping is > performed in the network local to the caller, why does the edge device > have to know it is a local dial string for an emergency service? Won't > the network note that, and go forward from there (in a 3gpp2 network, > doesn't it even determine the location for the terminal?) ? Sure, it is > great if > the edge device does realize that, and I'm happy LoST will provide that > data. > But it seems like the 999 call will go through in Sierra Leone if the > local > network does the mapping, whether the edge device recognizes it is a > local emergency dial string or not. > > What am I missing? > > Ted ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 17:03:28 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6159B3A686E; Wed, 14 May 2008 17:03:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E2883A6811 for ; Wed, 14 May 2008 17:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 CvQSHxDhUMF4 for ; Wed, 14 May 2008 17:02:49 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id C91683A686E for ; Wed, 14 May 2008 17:02:25 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JwQvJ-0001mS-TB; Wed, 14 May 2008 19:02:18 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Henning Schulzrinne'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com><17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu><001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com><001c01c8b61a$b4a0c860$640fa8c0@cis.neustar.com> Date: Wed, 14 May 2008 20:02:23 -0400 Message-ID: <001e01c8b61e$f5a05a20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4IAAOh9SAAADyXgAAAN1/gAABRnNAAAC3qoAAAsorg In-Reply-To: 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org There are no protocol police. There is no way for the PSAP to know what invoked the call. I think it has to be a MUST. Brian -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Wednesday, May 14, 2008 7:43 PM To: Winterbottom, James; Brian Rosen; Henning Schulzrinne Cc: ECRIT Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] And to further add to this. What you are saying below is that in some national variants, the local emergency dial string is required by the PSAP. What do you expect to be the behaviour if this is not provided, will you simply not accept the call? I believe that this requirement is a MAY, but I would settle for a SHOULD. Under no circumstance is it a MUST as it is not enforceable or required in the majority of cases. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: Thursday, 15 May 2008 9:37 AM > To: Brian Rosen; Henning Schulzrinne > Cc: ECRIT > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > I am sorry but this work for me because I may not use a dial string at > all, I may just use the service URN. This requirement is a may. > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 15 May 2008 9:32 AM > > To: Winterbottom, James; 'Henning Schulzrinne' > > Cc: 'ECRIT' > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > Because the PSAPs, and in some cases, regulation, requires it. > > > > It's that simple. > > > > It doesn't really matter if you think, or even if I think, it makes > more > > sense to require home dial strings work. Local dial strings MUST > work. > > > > We could have a discussion of whether home dial strings MUST work. We > > could > > decide that they should. The PSAPs, and the regulators, wouldn't > care. > > However, we can't decide that local dial string support is optional. > It's > > not, it's required. > > > > When you are in the U.S., 9-1-1 MUST work. > > When you are in Sierra Leone, 9-9-9 MUST work. > > > > Among other things, if Jasmine, a native Sierra Leonian, picks up > Andy's > > phone while he is in Sierra Leone and dials 9-9-9 for him, it has to > work. > > > > Brian > > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Wednesday, May 14, 2008 7:22 PM > > To: Brian Rosen; Henning Schulzrinne > > Cc: ECRIT > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > Why? > > > > The solution I have describe is: > > 1) more simple > > 2) Works every time > > 3) Only requires Andy to remember things that are close to home in a > > stressful situation when try to remember something different is hard. > > > > Personally I see the solution being described below as providing > > complexity for complexities sake. Yes, it is a solution, and yes it > > should be catered, but that only makes the requirement a MAY and not a > > MUST. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, 15 May 2008 9:19 AM > > > To: Winterbottom, James; 'Henning Schulzrinne' > > > Cc: 'ECRIT' > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > Police in Sierra Leone is 999. If Andy calls 999, it MUST be an > > > emergency > > > call. The fact that 9-1-1 worked may be a good thing, but it's not > > > required > > > to work. 9-9-9 is. > > > > > > I have no problem if Veronica implements 9-1-1 as an emergency call > > for > > > Andy > > > while he is traveling to Sierra Leone. I require, somehow, between > > Andy > > > and > > > Veronica, that 9-9-9 work. I recommend that Andy's device do a LoST > > query > > > with the location it got, find out that 999 (and 019, for fire) is > the > > > dial > > > string, and recognize it as such. > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Wednesday, May 14, 2008 5:40 PM > > > To: Henning Schulzrinne; Brian Rosen > > > Cc: ECRIT > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > *BUZZZ** Okay let me try again! > > > > > > I think you are making a leap here which isn't required. > > > Let me try and describe the scenario and configuration first, and > then > > you > > > can try and tell me why I need local dial strings. > > > > > > > > > Andy is caller. > > > Andy uses a VSP called Veronica > > > Veronica is based in Vermont > > > Veronica recognizes the emergency dial string 911. For the point of > > the > > > argument, let's say that that is all that Veronica recognizes. > > > Veronica has a pet LoST server Lucy > > > Veronica will send any mapping requests to Lucy > > > Lucy is responsible to find the correct mapping. > > > > > > Andy travels Sierra-Leone > > > Andy Connects to the local access network > > > Andy gets a location > > > Andy's room gets broken into, and he calls Veronica! > > > Andy is in a panic, so he calls 911 (which is a good thing since > that > > is > > > all > > > that Veronica understands) > > > > > > I expect this just to work, and this is why. > > > Veronica has a simple trigger looking for 911 > > > Veronica can then have a standard query set to send to Lucy > > > Location (from call) + fixed service URN (sos.. etc) > > > Lucy manages the mapping to destination URI > > > Andy's call gets directed to the local emergency centre > > > > > > Here is where it breaks down > > > > > > The local emergency centre doesn't understand a word of english > > > > > > > > > In this scenario I don't need local dial-string, at all ever. > > > I believe that for quite some time this will be a very common > > > configuration. > > > Hence local dial strings are a may, not a must from an end-point > > needing > > > to > > > understand them point of view. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > > > Sent: Wed 5/14/2008 9:55 AM > > > To: Brian Rosen > > > Cc: 'ECRIT' > > > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > I'm guessing you are assuming that the proxy is somehow configured > > > with the devices home location. (We probably don't want the proxy to > > > recognize dial strings local to its physical location, unless it > knows > > > that all of its customers reside in the same area. In some cases, > that > > > may be true, e.g., because the VSP only serves customers in one > > > country.) > > > > > > On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > > > > > Well, yes. It's actually very hard for a proxy to recognize local > > > > dial > > > > strings, because, in general, it doesn't know where the device is, > > > > so it > > > > can't determine what the local dial strings are, whether the > device > > is > > > > location literate or not. > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > -- > > > -------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > -- > > > -------------------- > > > [mf2] > > > > > > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > [mf2] > > > > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 17:06:19 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417CF3A68D3; Wed, 14 May 2008 17:06:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3101F3A68D3 for ; Wed, 14 May 2008 17:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_46=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 DVOsx1HyI0cT for ; Wed, 14 May 2008 17:04:51 -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 133DD3A683C for ; Wed, 14 May 2008 17:04:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,489,1204531200"; d="scan'208";a="33710624" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 14 May 2008 17:04:39 -0700 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 m4F04dDS010886 for ; Wed, 14 May 2008 17:04:39 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4F04dAR025527 for ; Thu, 15 May 2008 00:04:39 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 17:04:38 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.125.129]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 17:04:38 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 May 2008 19:04:37 -0500 To: ecrit@ietf.org From: "James M. Polk" In-Reply-To: <482A41E7.6020202@bbn.com> References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net> <4829D1AD.1070905@bbn.com> <482A41E7.6020202@bbn.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 15 May 2008 00:04:38.0801 (UTC) FILETIME=[4468A810:01C8B61F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6119; t=1210809879; x=1211673879; 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]=20Joint=20Meeting=20with=20the= 203GPP |Sender:=20; bh=wRROGR9RjoJv79RDclZUCZz/aRVgHi9/reCwr2A994w=; b=Z+1oGz/3mpPR6G4p9ARuBHBee7y4LppYwytBVTvhjoHD4FnlEXAJRtXHXM Y6P935iW7wQv4QZ2VbWrj/ihCqSnuJKBOzk3b7SnYNbpNQqSWB3RbkmL/ikf MfH+OXgitN; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:35 PM 5/13/2008, Richard Barnes wrote: >Certainly. I wasn't claiming that that was the recommendation of the >IETF in any way, just that it was allowed. Using signed location in >that way is not inconsistent with either location-conveyance or >framework/phonebcp; it's one option that a jurisdiction could employ to >assure the validity of static civic location information. I believe you are advocating (explicit) in your solution here to only that which disallows the UAC to modify a single XML element within the PIDF-LO message body. Though, at the moment I don't believe location-conveyance says this must be possible, I believe this is likely mandatory (at least in spirit of Geopriv docs) but for the mere fact that the owner of the UAC (i.e., the target) needs to be a rulemaker (but not necessarily the only one) and set/enter/include some of the elements (at least) such as , , and - each of which wouldn't be allowed if the whole PIDF-LO had a signature covering it. Yet, these are not necessarily, and often cannot be known to the LIS or PSAP at the time of the LCP response initially sending the PIDF-LO to the UAC (DHCP client in this case). What am I missing? >--RLB > > > >hannes.tschofenig@nsn.com wrote: > > We did not agree todo anything close to (2). > > > >> -----Original Message----- > >> From: ext Richard Barnes [mailto:rbarnes@bbn.com] > >> Sent: 13 May, 2008 20:37 > >> To: fmenard@xittelecom.com > >> Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org > >> Subject: Re: [Ecrit] Joint Meeting with the 3GPP > >> > >> Francois, > >> > >> Let me answer your question in three parts: > >> > >> 1. The spec allows the LbyV to be digitally signed. The > >> location is carried as a MIME body in the SIP message, and > >> thus can also be included in S/MIME form, signed, encrypted, > >> or both. See Appendix B of > >> draft-ietf-sip-location-conveyance-10 for an example. > >> > > > 10#appendix-B> > >> > >> 2. The signer does not necessarily have to be the PSAP (though > >> this is definitely allowed). In the model described in > >> framework/phonebcp, the endpoint gets its location from a > >> server in the access network to which it's connected, so when > >> we talk about location signing, I usually imagine that it's > >> signed by the access network's location server. > >> However, if a PSAP wanted to, it could provide signed location > >> objects to access networks in its jurisdiction that could then > >> be handed out to endpoints, who would then send them back to the PSAP: > >> > >> +------------+ > >> | PSAP |<------(3)--------+ > >> +------------+ | > >> | | > >> (1) | > >> | | > >> V | > >> +------------+ +----------+ > >> | Access Net |----(2)----->| Endpoint | > >> +------------+ +----------+ > >> > >> 3. The IETF has not defined anything directly analogous to the > >> MSAG, in the sense of a consolidated database (in fact, I > >> believe that the NENA > >> i3 architecture does away with the MSAG entirely). However, > >> there is a location validation function provided by the LoST protocol: > >> > >> There is no current standard way for a location to be marked > >> as valid (this could be hard, since notions of validity vary > >>from place to place), but a PSAP could easily verify that a > >> location is valid using LoST. > >> > >> Cheers, > >> --Richard > >> > >> > >> > >> > >> > >> > >> > >> Francois Menard wrote: > >>> Does the spec calls for digitally signing the LbyV by the PSAP, such > >>> that the PSAP can recognize an LbyV as being signed by itself as > >>> dispatch-able (i.e. MSAG-VALID), msag=master street address guide. > >>> > >>> F. > >>> > >>> -----Original Message----- > >>> From: Richard Barnes [mailto:rbarnes@bbn.com] > >>> Sent: 13 mai 2008 07:39 > >>> To: Francois Menard > >>> Cc: ; ecrit@ietf.org > >>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP > >>> > >>> Francois, > >>> > >>> I don't have a complete list, but to answer your specific question, > >>> location is transmitted by value from the endpoint to the > >> PSAP in the > >>> SIP INVITE message using the mechanism described in > >>> draft-ietf-sip-location-conveyance. > >>> > >>> --Richard > >>> > >>> > >>> > >>> Francois Menard wrote: > >>>> So that we may come prepared to this meeting, could you > >> provide links > >>>> to the latest specs, particularly the transmission of location by > >>>> value from the end-point to the PSAP. > >>>> > >>>> F. > >>>> > >>>> > >>>> On 13-May-08, at 2:58 AM, > >>> >>>> > wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> We would like to inform you that we are currently planning to > >>>>> organize a meeting with the 3GPP around August 2008. The > >> main topic > >>>>> for our discussion is the harmonization of the 3GPP and the IETF > >>>>> emergency services architecture. > >>>>> > >>>>> We will distribute more details as soon as they are available. > >>>>> > >>>>> Ciao > >>>>> Hannes & Marc > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> -- > >>>> Francois Menard > >>>> fmenard@xittelecom.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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 17:06:26 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB183A689F; Wed, 14 May 2008 17:06:26 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF323A6781 for ; Wed, 14 May 2008 17:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 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 LxWaHMjbqXod for ; Wed, 14 May 2008 17:05:55 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9C2683A6948 for ; Wed, 14 May 2008 17:05:27 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_19_19_24 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, 14 May 2008 19:19:24 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 19:05:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 19:05:21 -0500 Message-ID: In-Reply-To: <001e01c8b61e$f5a05a20$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4IAAOh9SAAADyXgAAAN1/gAABRnNAAAC3qoAAAsorgAAAia/A= References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com><17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu><001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com><001c01c8b61a$b4a0c860$640fa8c0@cis.neustar.com> <001e01 c8b61e$f5a05a20$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 15 May 2008 00:05:23.0699 (UTC) FILETIME=[5F2B8C30:01C8B61F] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org If there is no way for the PSAP to know There is no way to enforce it It is not required in all cases How can it be anything other than a SHOULD? > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 15 May 2008 10:02 AM > To: Winterbottom, James; 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > There are no protocol police. > > There is no way for the PSAP to know what invoked the call. > > I think it has to be a MUST. > > Brian > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, May 14, 2008 7:43 PM > To: Winterbottom, James; Brian Rosen; Henning Schulzrinne > Cc: ECRIT > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > And to further add to this. > What you are saying below is that in some national variants, the local > emergency dial string is required by the PSAP. What do you expect to be > the behaviour if this is not provided, will you simply not accept the > call? > > I believe that this requirement is a MAY, but I would settle for a > SHOULD. Under no circumstance is it a MUST as it is not enforceable or > required in the majority of cases. > > Cheers > James > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Winterbottom, James > > Sent: Thursday, 15 May 2008 9:37 AM > > To: Brian Rosen; Henning Schulzrinne > > Cc: ECRIT > > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > I am sorry but this work for me because I may not use a dial string at > > all, I may just use the service URN. This requirement is a may. > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, 15 May 2008 9:32 AM > > > To: Winterbottom, James; 'Henning Schulzrinne' > > > Cc: 'ECRIT' > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > Because the PSAPs, and in some cases, regulation, requires it. > > > > > > It's that simple. > > > > > > It doesn't really matter if you think, or even if I think, it makes > > more > > > sense to require home dial strings work. Local dial strings MUST > > work. > > > > > > We could have a discussion of whether home dial strings MUST work. > We > > > could > > > decide that they should. The PSAPs, and the regulators, wouldn't > > care. > > > However, we can't decide that local dial string support is optional. > > It's > > > not, it's required. > > > > > > When you are in the U.S., 9-1-1 MUST work. > > > When you are in Sierra Leone, 9-9-9 MUST work. > > > > > > Among other things, if Jasmine, a native Sierra Leonian, picks up > > Andy's > > > phone while he is in Sierra Leone and dials 9-9-9 for him, it has to > > work. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Wednesday, May 14, 2008 7:22 PM > > > To: Brian Rosen; Henning Schulzrinne > > > Cc: ECRIT > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > Why? > > > > > > The solution I have describe is: > > > 1) more simple > > > 2) Works every time > > > 3) Only requires Andy to remember things that are close to home in a > > > stressful situation when try to remember something different is > hard. > > > > > > Personally I see the solution being described below as providing > > > complexity for complexities sake. Yes, it is a solution, and yes it > > > should be catered, but that only makes the requirement a MAY and not > a > > > MUST. > > > > > > Cheers > > > James > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, 15 May 2008 9:19 AM > > > > To: Winterbottom, James; 'Henning Schulzrinne' > > > > Cc: 'ECRIT' > > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > > > Police in Sierra Leone is 999. If Andy calls 999, it MUST be an > > > > emergency > > > > call. The fact that 9-1-1 worked may be a good thing, but it's > not > > > > required > > > > to work. 9-9-9 is. > > > > > > > > I have no problem if Veronica implements 9-1-1 as an emergency > call > > > for > > > > Andy > > > > while he is traveling to Sierra Leone. I require, somehow, > between > > > Andy > > > > and > > > > Veronica, that 9-9-9 work. I recommend that Andy's device do a > LoST > > > query > > > > with the location it got, find out that 999 (and 019, for fire) is > > the > > > > dial > > > > string, and recognize it as such. > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Wednesday, May 14, 2008 5:40 PM > > > > To: Henning Schulzrinne; Brian Rosen > > > > Cc: ECRIT > > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > > > *BUZZZ** Okay let me try again! > > > > > > > > I think you are making a leap here which isn't required. > > > > Let me try and describe the scenario and configuration first, and > > then > > > you > > > > can try and tell me why I need local dial strings. > > > > > > > > > > > > Andy is caller. > > > > Andy uses a VSP called Veronica > > > > Veronica is based in Vermont > > > > Veronica recognizes the emergency dial string 911. For the point > of > > > the > > > > argument, let's say that that is all that Veronica recognizes. > > > > Veronica has a pet LoST server Lucy > > > > Veronica will send any mapping requests to Lucy > > > > Lucy is responsible to find the correct mapping. > > > > > > > > Andy travels Sierra-Leone > > > > Andy Connects to the local access network > > > > Andy gets a location > > > > Andy's room gets broken into, and he calls Veronica! > > > > Andy is in a panic, so he calls 911 (which is a good thing since > > that > > > is > > > > all > > > > that Veronica understands) > > > > > > > > I expect this just to work, and this is why. > > > > Veronica has a simple trigger looking for 911 > > > > Veronica can then have a standard query set to send to Lucy > > > > Location (from call) + fixed service URN (sos.. etc) > > > > Lucy manages the mapping to destination URI > > > > Andy's call gets directed to the local emergency centre > > > > > > > > Here is where it breaks down > > > > > > > > The local emergency centre doesn't understand a word of english > > > > > > > > > > > > In this scenario I don't need local dial-string, at all ever. > > > > I believe that for quite some time this will be a very common > > > > configuration. > > > > Hence local dial strings are a may, not a must from an end-point > > > needing > > > > to > > > > understand them point of view. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > > > > Sent: Wed 5/14/2008 9:55 AM > > > > To: Brian Rosen > > > > Cc: 'ECRIT' > > > > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > > > I'm guessing you are assuming that the proxy is somehow configured > > > > with the devices home location. (We probably don't want the proxy > to > > > > recognize dial strings local to its physical location, unless it > > knows > > > > that all of its customers reside in the same area. In some cases, > > that > > > > may be true, e.g., because the VSP only serves customers in one > > > > country.) > > > > > > > > On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > > > > > > > Well, yes. It's actually very hard for a proxy to recognize > local > > > > > dial > > > > > strings, because, in general, it doesn't know where the device > is, > > > > > so it > > > > > can't determine what the local dial strings are, whether the > > device > > > is > > > > > location literate or not. > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > -- > > > > -------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > -- > > > > -------------------- > > > > [mf2] > > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > -- > > > -------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > -- > > > -------------------- > > > [mf2] > > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 17:06:45 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696323A689F; Wed, 14 May 2008 17:06:45 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA023A6823 for ; Wed, 14 May 2008 17:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=-0.101, 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 4ZjsKGp8bU87 for ; Wed, 14 May 2008 17:06:35 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id B1CF13A6921 for ; Wed, 14 May 2008 17:06:27 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JwQys-00024L-5R; Wed, 14 May 2008 19:05:58 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Marc Linsner'" References: <48287315.5080100@gmx.net><0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com><0c8701c8b513$85091470$640fa8c0@cis.neustar.com><00e701c8b560$18a00fd0$250d0d0a@cisco.com><0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com><0dad01c8b5ca$021a5300$640fa8c0@cis.neustar.com><008d01c8b5cb$4698b2a0$250d0d0a@cisco.com><0dae01c8b5cc$75f18ee0$640fa8c0@cis.neustar.com><17AD9E1F-6FB5-4A2D-9BBC-EE2306C271DE@cs.columbia.edu><001a01c8b618$d4afa3d0$640fa8c0@cis.neustar.com><001c01c8b61a$b4a0c860$640fa8c0@cis.neustar.com><001501c8b61d$d279bec0$45aa520a@MLINSNER> Date: Wed, 14 May 2008 20:06:03 -0400 Message-ID: <001f01c8b61f$78e8e730$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aci10r+ZrgZSNlfmRfq2ncb56xf28QANt/4IAAOh9SAAADyXgAAAN1/gAABRnNAAAIgmIAAAJl2QAABCU3A= In-Reply-To: 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andy's device knows where it is. It uses LoST to find the local dial string. Veronica doesn't need to do anything if the device does the right thing. Location aware, emergency unaware devices are possible I suppose, but I don't see any reason to bend the system to make that work. If Andy's device can find out where it is, it can query LoST to get the local dialstring and recognize it. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James Sent: Wednesday, May 14, 2008 7:59 PM To: Marc Linsner Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] I am uncomfortable with expecting Veronica to know all codes for every service on Earth, which is what the extension to what is being requested. I expect Andy to use codes he knows and is familiar with when he is in a real pickle and doesn't want to have to think. I think that this is a may not a must, but I am offering a compromise of should. Cheers James > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, 15 May 2008 9:54 AM > To: Winterbottom, James > Cc: 'ECRIT' > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > James, > > You are comfortable denying Andy emergency care because he performed per > the > instructions on the back of his hotel room door that states: "In case of > emergency, dial 9-9-9." ?? > > -Marc- > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: Wednesday, May 14, 2008 7:37 PM > To: Brian Rosen; Henning Schulzrinne > Cc: ECRIT > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > I am sorry but this work for me because I may not use a dial string at > all, > I may just use the service URN. This requirement is a may. > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 15 May 2008 9:32 AM > > To: Winterbottom, James; 'Henning Schulzrinne' > > Cc: 'ECRIT' > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > Because the PSAPs, and in some cases, regulation, requires it. > > > > It's that simple. > > > > It doesn't really matter if you think, or even if I think, it makes > more > > sense to require home dial strings work. Local dial strings MUST > work. > > > > We could have a discussion of whether home dial strings MUST work. We > > could decide that they should. The PSAPs, and the regulators, > > wouldn't > care. > > However, we can't decide that local dial string support is optional. > It's > > not, it's required. > > > > When you are in the U.S., 9-1-1 MUST work. > > When you are in Sierra Leone, 9-9-9 MUST work. > > > > Among other things, if Jasmine, a native Sierra Leonian, picks up > Andy's > > phone while he is in Sierra Leone and dials 9-9-9 for him, it has to > work. > > > > Brian > > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Wednesday, May 14, 2008 7:22 PM > > To: Brian Rosen; Henning Schulzrinne > > Cc: ECRIT > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > Why? > > > > The solution I have describe is: > > 1) more simple > > 2) Works every time > > 3) Only requires Andy to remember things that are close to home in a > > stressful situation when try to remember something different is hard. > > > > Personally I see the solution being described below as providing > > complexity for complexities sake. Yes, it is a solution, and yes it > > should be catered, but that only makes the requirement a MAY and not a > > MUST. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, 15 May 2008 9:19 AM > > > To: Winterbottom, James; 'Henning Schulzrinne' > > > Cc: 'ECRIT' > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > Police in Sierra Leone is 999. If Andy calls 999, it MUST be an > > > emergency > > > call. The fact that 9-1-1 worked may be a good thing, but it's not > > > required to work. 9-9-9 is. > > > > > > I have no problem if Veronica implements 9-1-1 as an emergency call > > for > > > Andy > > > while he is traveling to Sierra Leone. I require, somehow, between > > Andy > > > and > > > Veronica, that 9-9-9 work. I recommend that Andy's device do a LoST > > query > > > with the location it got, find out that 999 (and 019, for fire) is > the > > > dial > > > string, and recognize it as such. > > > > > > Brian > > > > > > > > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Wednesday, May 14, 2008 5:40 PM > > > To: Henning Schulzrinne; Brian Rosen > > > Cc: ECRIT > > > Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > *BUZZZ** Okay let me try again! > > > > > > I think you are making a leap here which isn't required. > > > Let me try and describe the scenario and configuration first, and > then > > you > > > can try and tell me why I need local dial strings. > > > > > > > > > Andy is caller. > > > Andy uses a VSP called Veronica > > > Veronica is based in Vermont > > > Veronica recognizes the emergency dial string 911. For the point of > > the > > > argument, let's say that that is all that Veronica recognizes. > > > Veronica has a pet LoST server Lucy > > > Veronica will send any mapping requests to Lucy Lucy is responsible > > > to find the correct mapping. > > > > > > Andy travels Sierra-Leone > > > Andy Connects to the local access network Andy gets a location > > > Andy's room gets broken into, and he calls Veronica! > > > Andy is in a panic, so he calls 911 (which is a good thing since > that > > is > > > all > > > that Veronica understands) > > > > > > I expect this just to work, and this is why. > > > Veronica has a simple trigger looking for 911 Veronica can then have > > > a standard query set to send to Lucy Location (from call) + fixed > > > service URN (sos.. etc) Lucy manages the mapping to destination URI > > > Andy's call gets directed to the local emergency centre > > > > > > Here is where it breaks down > > > > > > The local emergency centre doesn't understand a word of english > > > > > > > > > In this scenario I don't need local dial-string, at all ever. > > > I believe that for quite some time this will be a very common > > > configuration. > > > Hence local dial strings are a may, not a must from an end-point > > needing > > > to > > > understand them point of view. > > > > > > Cheers > > > James > > > > > > > > > > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org on behalf of Henning Schulzrinne > > > Sent: Wed 5/14/2008 9:55 AM > > > To: Brian Rosen > > > Cc: 'ECRIT' > > > Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > > > > > I'm guessing you are assuming that the proxy is somehow configured > > > with the devices home location. (We probably don't want the proxy to > > > recognize dial strings local to its physical location, unless it > knows > > > that all of its customers reside in the same area. In some cases, > that > > > may be true, e.g., because the VSP only serves customers in one > > > country.) > > > > > > On May 14, 2008, at 10:11 AM, Brian Rosen wrote: > > > > > > > Well, yes. It's actually very hard for a proxy to recognize local > > > > dial strings, because, in general, it doesn't know where the > > > > device is, so it can't determine what the local dial strings are, > > > > whether the > device > > is > > > > location literate or not. > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > -- > > > -------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of this > > > email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > -- > > > -------------------- > > > [mf2] > > > > > > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > This message is for the designated recipient only and may contain > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender immediately > > and delete the original. Any unauthorized use of this email is > > prohibited. > > > ------------------------------------------------------------------------ > -- > > -- > > -------------------- > > [mf2] > > > > ------------------------------------------------------------------------ -- > -- > -------------------- > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately and > delete the original. Any unauthorized use of this email is prohibited. > ------------------------------------------------------------------------ -- > -- > -------------------- > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 17:15:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A05AA3A68C0; Wed, 14 May 2008 17:15:57 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7943A68C0 for ; Wed, 14 May 2008 17:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIUyDFCE29ns for ; Wed, 14 May 2008 17:15:53 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E76463A683C for ; Wed, 14 May 2008 17:15:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,489,1204531200"; d="scan'208";a="68127268" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 14 May 2008 17:15:49 -0700 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 m4F0Fnqg030600 for ; Wed, 14 May 2008 17:15:49 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4F0Fn1r009596 for ; Thu, 15 May 2008 00:15:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 17:15:49 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.125.129]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 May 2008 17:15:48 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 14 May 2008 19:15:46 -0500 To: "ECRIT" From: "James M. Polk" In-Reply-To: References: <48287315.5080100@gmx.net> <0b5901c8b460$ffb87d40$640fa8c0@cis.neustar.com> <0c8701c8b513$85091470$640fa8c0@cis.neustar.com> <00e701c8b560$18a00fd0$250d0d0a@cisco.com> <0da001c8b5c2$2a0b0fb0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 15 May 2008 00:15:49.0050 (UTC) FILETIME=[D3E889A0:01C8B620] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6915; t=1210810549; x=1211674549; 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]=20[Fwd=3A=203GPP2=20TSG-X=20Cor r=20to=20IETF=20re=20ECRIT/WGLC] |Sender:=20; bh=FPsWyqnlDUK23PFCKHi+gH29dj82sL3Qqco3gUyLf6Q=; b=VDYJ4dCsAn8XdKjYktHfqik7ab1MaaM4fjdXYi/M6sOtJaxjQf3qBRFhu8 X8YRUMAl0HnNnE9afcSFOXTCL4RFmock7r7RyKaPLv8hnifyGdCqGnMnkmPZ wALz/PgUg6; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 08:32 AM 5/14/2008, Dawson, Martin wrote: >I think the clarification - for me anyway - is that this is about the >*device* recognizing that the user wants to invoke an emergency call. >That is, the device, on initialization and however frequently >periodically, learns the local emergency code(s) from the LoST server >and "programs" itself to recognize the number sequence(s) as an >emergency call invocation (even if the user previously understood that >code to mean something else). Martin -- playing catch on this thread. What you say above is what was thought by at least some of us from the beginning. The UAC needs to be the one that recognizes the visited string to know this is an emergency call (to include location and do all the other things in the phonebcp). I do think that sometimes, we get caught up (i.e., talking past each other without realizing it) in what's meant by "local" vs. "visited" vs. "home" string/address. >I'm OK with that - I'd previously understood that there was some sort of >a requirement on the proxy/home-service/VSP to recognize the local dial >string(s) as an emergency call invocation. This had a problematic >catch-22 aspect that bothered me - and I didn't even see why it was >necessary. Dial strings should only be relevant to the VSP for an >i2-style invocation and then it's really only reasonable to expect the >VSP to recognize home emergency dial strings - plus whatever >quasi-universal (e.g. 112) strings that it might also choose to observe. > >Cheers, >Martin > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of Brian Rosen >Sent: Wednesday, 14 May 2008 10:58 PM >To: Winterbottom, James; 'Marc Linsner'; 'ECRIT' >Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > >I have no idea where the "objected to the notion of a call going >directly to >a PSAP URI" comes from. I want the call sent on the normal call path. >If >that is direct to the R-URI/Route header, then do that. If you normally >send all outbound calls to an outbound proxy, do that. > >The item under discussion is ED-5, devices must recognize local dial >strings. In that situation, the normal way to invoke an emergency call >is a >dial string (special buttons are discouraged). You want home strings to >be >recognized. I claim that is a nice to have, not a requirement, where >local >strings are a clear requirement (it's regulated in some countries). In >that >circumstance the service URN isn't already known. I don't know what >"service local to the user" means. The service that usually handles >calls >is handling the call, one way or another. That might be the visited >network >in 3GPP wireless, or the home network for most other systems. If there >is >no service provider (Marc's self installed home proxy is handling the >call), >then there is no local service other than that. > >Brian > > > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of >Winterbottom, James >Sent: Tuesday, May 13, 2008 10:01 PM >To: Marc Linsner; ECRIT >Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > > >Ummm perhaps I am misunderstanding what has been said then. >I was under the impression that somebody vehemently objected to the >notion >of a call going directly to a PSAP URI. >I will be watching very carefully to the answer to this one. > >I will also point out that dial string are only of importance when: >1) The service local to the user to user is handling the actual service >determination >2) A service URN isn't already known. > >I think at best it is a should, is probably only a may. > >Cheers >James > > > > >-----Original Message----- >From: Marc Linsner [mailto:mlinsner@cisco.com] >Sent: Tue 5/13/2008 8:16 PM >To: Winterbottom, James; 'ECRIT' >Subject: RE: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] > >James, > > > > > > > > [AJW] Seriously, our entire ECRIT, i2 and i3 architectures > > are fundamentally different to the way in which GSM and UMTS > > networks operate. In the latter two, call service functions, > > all of them, are handled in the visited network, the ECRIT, > > i2 and i3 architectures don't. In the NENA and ECRIT > > architectures only the local access and location services are > > immediately used, call handling as it were, is handled by a > > home VSP, call-server, proxy, call it what you will. That > > home service then either routes, or determines the route to > > the PSAP. It is totally unclear to me how the dial-string > > even enters into this as long as the correct service URN is > > present, and that mapping doesn't need to be managed by an > > end-point. Since the home VSP knows its home dial string it > > can map that to the appropriate service URN when making a > > LoST request, it just works. > > > > I don't think that the current network analogies hold up > > under scrutiny, can you please provide reasonable rationale > > given that the routing trombones through a home service? > >Proxies/call agents are not a required element in the SIP model, hence, >no >guarantee of 'trombones through a home service'. Knowing local >emergency >dial strings solve the UI issue (the sign on the passing bus that says >'in >case of emergency, dial 1234'), regardless of where the mapping is done. > > >-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] > >_______________________________________________ >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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 17:23:44 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B75FD3A6894; Wed, 14 May 2008 17:23:44 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5007E3A68D5 for ; Wed, 14 May 2008 17:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, 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 kqHWBQaGK--I for ; Wed, 14 May 2008 17:23:42 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 158663A6811 for ; Wed, 14 May 2008 17:23:41 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_14_19_37_44 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, 14 May 2008 19:37:44 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 19:23:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 19:23:41 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Joint Meeting with the 3GPP Thread-Index: Aci2H4N8Ka0DS3kbT/GQxT1sLZpqwAAAbyqw References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net><4829D1AD.1070905@bbn.com><482A41E7.6020202@bbn.com> From: "Winterbottom, James" To: "James M. Polk" , X-OriginalArrivalTime: 15 May 2008 00:23:43.0979 (UTC) FILETIME=[EEFCF3B0:01C8B621] Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think it depends on precisely what is trying to be secured. I have indicated several times what I believe needs to be secured at least by the location provider, and I include the method parameter in this. The and elements are policy that are ultimately set by the Target and not by the LIS, though the LIS can provide guidance, consequently I don't see these as needing to be included in the validation component of the location information itself. At this point I have only seen one proposal on the table for location signing, so I can't comment on what other proposals may be capable of addressing. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Thursday, 15 May 2008 10:05 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] Joint Meeting with the 3GPP > > At 08:35 PM 5/13/2008, Richard Barnes wrote: > >Certainly. I wasn't claiming that that was the recommendation of the > >IETF in any way, just that it was allowed. Using signed location in > >that way is not inconsistent with either location-conveyance or > >framework/phonebcp; it's one option that a jurisdiction could employ to > >assure the validity of static civic location information. > > I believe you are advocating (explicit) in your solution here to only > that which disallows the UAC to modify a single XML element within > the PIDF-LO message body. Though, at the moment I don't believe > location-conveyance says this must be possible, I believe this is > likely mandatory (at least in spirit of Geopriv docs) but for the > mere fact that the owner of the UAC (i.e., the target) needs to be a > rulemaker (but not necessarily the only one) and set/enter/include > some of the elements (at least) such as , > , and - each of which > wouldn't be allowed if the whole PIDF-LO had a signature covering it. > Yet, these are not necessarily, and often cannot be known to the LIS > or PSAP at the time of the LCP response initially sending the PIDF-LO > to the UAC (DHCP client in this case). > > What am I missing? > > > >--RLB > > > > > > > >hannes.tschofenig@nsn.com wrote: > > > We did not agree todo anything close to (2). > > > > > >> -----Original Message----- > > >> From: ext Richard Barnes [mailto:rbarnes@bbn.com] > > >> Sent: 13 May, 2008 20:37 > > >> To: fmenard@xittelecom.com > > >> Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org > > >> Subject: Re: [Ecrit] Joint Meeting with the 3GPP > > >> > > >> Francois, > > >> > > >> Let me answer your question in three parts: > > >> > > >> 1. The spec allows the LbyV to be digitally signed. The > > >> location is carried as a MIME body in the SIP message, and > > >> thus can also be included in S/MIME form, signed, encrypted, > > >> or both. See Appendix B of > > >> draft-ietf-sip-location-conveyance-10 for an example. > > >> > > > > > 10#appendix-B> > > >> > > >> 2. The signer does not necessarily have to be the PSAP (though > > >> this is definitely allowed). In the model described in > > >> framework/phonebcp, the endpoint gets its location from a > > >> server in the access network to which it's connected, so when > > >> we talk about location signing, I usually imagine that it's > > >> signed by the access network's location server. > > >> However, if a PSAP wanted to, it could provide signed location > > >> objects to access networks in its jurisdiction that could then > > >> be handed out to endpoints, who would then send them back to the > PSAP: > > >> > > >> +------------+ > > >> | PSAP |<------(3)--------+ > > >> +------------+ | > > >> | | > > >> (1) | > > >> | | > > >> V | > > >> +------------+ +----------+ > > >> | Access Net |----(2)----->| Endpoint | > > >> +------------+ +----------+ > > >> > > >> 3. The IETF has not defined anything directly analogous to the > > >> MSAG, in the sense of a consolidated database (in fact, I > > >> believe that the NENA > > >> i3 architecture does away with the MSAG entirely). However, > > >> there is a location validation function provided by the LoST > protocol: > > >> > > >> There is no current standard way for a location to be marked > > >> as valid (this could be hard, since notions of validity vary > > >>from place to place), but a PSAP could easily verify that a > > >> location is valid using LoST. > > >> > > >> Cheers, > > >> --Richard > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> Francois Menard wrote: > > >>> Does the spec calls for digitally signing the LbyV by the PSAP, such > > >>> that the PSAP can recognize an LbyV as being signed by itself as > > >>> dispatch-able (i.e. MSAG-VALID), msag=master street address guide. > > >>> > > >>> F. > > >>> > > >>> -----Original Message----- > > >>> From: Richard Barnes [mailto:rbarnes@bbn.com] > > >>> Sent: 13 mai 2008 07:39 > > >>> To: Francois Menard > > >>> Cc: ; ecrit@ietf.org > > >>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP > > >>> > > >>> Francois, > > >>> > > >>> I don't have a complete list, but to answer your specific question, > > >>> location is transmitted by value from the endpoint to the > > >> PSAP in the > > >>> SIP INVITE message using the mechanism described in > > >>> draft-ietf-sip-location-conveyance. > > >>> > > >>> --Richard > > >>> > > >>> > > >>> > > >>> Francois Menard wrote: > > >>>> So that we may come prepared to this meeting, could you > > >> provide links > > >>>> to the latest specs, particularly the transmission of location by > > >>>> value from the end-point to the PSAP. > > >>>> > > >>>> F. > > >>>> > > >>>> > > >>>> On 13-May-08, at 2:58 AM, > > >>> > >>>> > wrote: > > >>>> > > >>>>> Hi all, > > >>>>> > > >>>>> We would like to inform you that we are currently planning to > > >>>>> organize a meeting with the 3GPP around August 2008. The > > >> main topic > > >>>>> for our discussion is the harmonization of the 3GPP and the IETF > > >>>>> emergency services architecture. > > >>>>> > > >>>>> We will distribute more details as soon as they are available. > > >>>>> > > >>>>> Ciao > > >>>>> Hannes & Marc > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Ecrit mailing list > > >>>>> Ecrit@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > > >>>> -- > > >>>> Francois Menard > > >>>> fmenard@xittelecom.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 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 14 19:41:43 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80F43A697D; Wed, 14 May 2008 19:41:43 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85CAB3A687C for ; Wed, 14 May 2008 19:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_46=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 Kzb5gE6+WS-v for ; Wed, 14 May 2008 19:41:41 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 182133A6924 for ; Wed, 14 May 2008 19:41:41 -0700 (PDT) Received: from [128.89.252.44] (helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JwTPU-0004eL-3q; Wed, 14 May 2008 22:41:36 -0400 Message-ID: <482BA2DE.5080700@bbn.com> Date: Wed, 14 May 2008 22:41:34 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "James M. Polk" References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net> <4829D1AD.1070905@bbn.com> <482A41E7.6020202@bbn.com> In-Reply-To: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, (Let me note that I'm not advocating a solution, just saying that it's one way you could do things that's allowed by the specs. I don't really think it's a particularly good one, since it doesn't offer a significant advantage over just using LoST validation when necessary. In fact, LoST is probably faster in a lot of cases than cert validation!) I agree that signing a whole LO is a clumsy way of providing assurance about LI; it would be much preferable to have a selective signature over just the , or even just a signed GML document. However, the concept of signed location is not inimical to the GEOPRIV model. Let me try to clarify a few misconceptions: First, there is not a requirement in 3693 that the Target be a Rule Maker, only that the Location Server respect the rules specified by the Location Generator (in the Location Object) and by the RM. In the scenario where a PSAP is handing out signed LOs, there wouldn't even really be an RM in the distribution process. The PSAP would be the LG, the access network would be the LS, and the endpoint would be the LR. Second, in the PSAP-signed-location scenario, it's OK that there's no access controls, because the signed LOs are "raw" LOs -- they don't have any identity information, since the PSAP doesn't know who the LS is going to send them to. And it's a long-held GEOPRIV tenet that location information by itself (without identity) doesn't need the protections provided by privacy rules. Third, the RM is not necessarily an entity that specifies elements in a PIDF-LO. Rules are propagated in two ways in the 3693 model, within the PIDF-LO (from the LG), and directly from the RM to the LS. So the RM (or the Target acting as an RM) could specify access controls on a signed LO, but could not specify rules that would modify the LO returned. Fourth, the Target can always use the signed LO to create a new LO with whatever location and privacy rules it wants -- it just can't then claim that the results were signed just because the original LO was signed. This is the correct result, since the new LO actually wasn't signed by the PSAP! Cheers, --Richard James M. Polk wrote: > At 08:35 PM 5/13/2008, Richard Barnes wrote: >> Certainly. I wasn't claiming that that was the recommendation of the >> IETF in any way, just that it was allowed. Using signed location in >> that way is not inconsistent with either location-conveyance or >> framework/phonebcp; it's one option that a jurisdiction could employ to >> assure the validity of static civic location information. > > I believe you are advocating (explicit) in your solution here to only > that which disallows the UAC to modify a single XML element within > the PIDF-LO message body. Though, at the moment I don't believe > location-conveyance says this must be possible, I believe this is > likely mandatory (at least in spirit of Geopriv docs) but for the > mere fact that the owner of the UAC (i.e., the target) needs to be a > rulemaker (but not necessarily the only one) and set/enter/include > some of the elements (at least) such as , > , and - each of which > wouldn't be allowed if the whole PIDF-LO had a signature covering it. > Yet, these are not necessarily, and often cannot be known to the LIS > or PSAP at the time of the LCP response initially sending the PIDF-LO > to the UAC (DHCP client in this case). > > What am I missing? > > >> --RLB >> >> >> >> hannes.tschofenig@nsn.com wrote: >>> We did not agree todo anything close to (2). >>> >>>> -----Original Message----- >>>> From: ext Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: 13 May, 2008 20:37 >>>> To: fmenard@xittelecom.com >>>> Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >>>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>>> >>>> Francois, >>>> >>>> Let me answer your question in three parts: >>>> >>>> 1. The spec allows the LbyV to be digitally signed. The >>>> location is carried as a MIME body in the SIP message, and >>>> thus can also be included in S/MIME form, signed, encrypted, >>>> or both. See Appendix B of >>>> draft-ietf-sip-location-conveyance-10 for an example. >>>> >> > >> 10#appendix-B> >>>> 2. The signer does not necessarily have to be the PSAP (though >>>> this is definitely allowed). In the model described in >>>> framework/phonebcp, the endpoint gets its location from a >>>> server in the access network to which it's connected, so when >>>> we talk about location signing, I usually imagine that it's >>>> signed by the access network's location server. >>>> However, if a PSAP wanted to, it could provide signed location >>>> objects to access networks in its jurisdiction that could then >>>> be handed out to endpoints, who would then send them back to the PSAP: >>>> >>>> +------------+ >>>> | PSAP |<------(3)--------+ >>>> +------------+ | >>>> | | >>>> (1) | >>>> | | >>>> V | >>>> +------------+ +----------+ >>>> | Access Net |----(2)----->| Endpoint | >>>> +------------+ +----------+ >>>> >>>> 3. The IETF has not defined anything directly analogous to the >>>> MSAG, in the sense of a consolidated database (in fact, I >>>> believe that the NENA >>>> i3 architecture does away with the MSAG entirely). However, >>>> there is a location validation function provided by the LoST protocol: >>>> >>>> There is no current standard way for a location to be marked >>>> as valid (this could be hard, since notions of validity vary >>> >from place to place), but a PSAP could easily verify that a >>>> location is valid using LoST. >>>> >>>> Cheers, >>>> --Richard >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Francois Menard wrote: >>>>> Does the spec calls for digitally signing the LbyV by the PSAP, such >>>>> that the PSAP can recognize an LbyV as being signed by itself as >>>>> dispatch-able (i.e. MSAG-VALID), msag=master street address guide. >>>>> >>>>> F. >>>>> >>>>> -----Original Message----- >>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>> Sent: 13 mai 2008 07:39 >>>>> To: Francois Menard >>>>> Cc: ; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>>>> >>>>> Francois, >>>>> >>>>> I don't have a complete list, but to answer your specific question, >>>>> location is transmitted by value from the endpoint to the >>>> PSAP in the >>>>> SIP INVITE message using the mechanism described in >>>>> draft-ietf-sip-location-conveyance. >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> Francois Menard wrote: >>>>>> So that we may come prepared to this meeting, could you >>>> provide links >>>>>> to the latest specs, particularly the transmission of location by >>>>>> value from the end-point to the PSAP. >>>>>> >>>>>> F. >>>>>> >>>>>> >>>>>> On 13-May-08, at 2:58 AM, >>>>> >>>>> > wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> We would like to inform you that we are currently planning to >>>>>>> organize a meeting with the 3GPP around August 2008. The >>>> main topic >>>>>>> for our discussion is the harmonization of the 3GPP and the IETF >>>>>>> emergency services architecture. >>>>>>> >>>>>>> We will distribute more details as soon as they are available. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes & Marc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> -- >>>>>> Francois Menard >>>>>> fmenard@xittelecom.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 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 15 10:34:52 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8EF23A6818; Thu, 15 May 2008 10:34:52 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEFC3A6818 for ; Thu, 15 May 2008 10:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_46=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 ob-xnrnr7MmA for ; Thu, 15 May 2008 10:34:47 -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 11E0D3A6806 for ; Thu, 15 May 2008 10:34:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,492,1204531200"; d="scan'208";a="33886264" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 15 May 2008 10:33:45 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4FHXjok011031 for ; Thu, 15 May 2008 10:33:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4FHXiwZ006206 for ; Thu, 15 May 2008 17:33:45 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 10:33:42 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.117.27]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 10:33:42 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 May 2008 12:33:40 -0500 To: ecrit@ietf.org From: "James M. Polk" In-Reply-To: <482BA2DE.5080700@bbn.com> References: <48297DE7.5000107@bbn.com> <008a01c8b4ff$4e149110$ea3db330$@net> <4829D1AD.1070905@bbn.com> <482A41E7.6020202@bbn.com> <482BA2DE.5080700@bbn.com> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 15 May 2008 17:33:42.0451 (UTC) FILETIME=[D1BF7030:01C8B6B1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12141; t=1210872825; x=1211736825; c=relaxed/simple; s=sjdkim2002; 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]=20Joint=20Meeting=20with=20the= 203GPP |Sender:=20; bh=5Lz02Rk3O92unxz5d+LIOXDCGO0/w2DNcpsRTC4Rsmc=; b=0sALAWVN1kGwKF/ymc5MWaGFEyBXG/R1Fp4F9gfCX+0clixwvPUgM/Ib9O 5mNXmKoxvYaGCl2oAfvf1VS8VhG0f1he8boYovmAjr48wfhxP5ANBNUzXAxI ZEgcS2X8Md; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Ecrit] Joint Meeting with the 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Richard ]I want to first say this isn't an attack on you, and I have no internal tone in this, or past, responses. Just to be clear] comments in-line below At 09:41 PM 5/14/2008, Richard Barnes wrote: >James, > >(Let me note that I'm not advocating a solution, just saying that >it's one way you could do things that's allowed by the specs. I >don't really think it's a particularly good one, since it doesn't >offer a significant advantage over just using LoST validation when >necessary. In fact, LoST is probably faster in a lot of cases than >cert validation!) > >I agree that signing a whole LO is a clumsy way of providing >assurance about LI; it would be much preferable to have a selective >signature over just the , to me, it would be preferable to have a PKI and there be a trust relationship between the PSAP and the LG, but that's another leap of faith ;-) Just doing this over the is better than over the PIDF-LO, but this has the problem of deciding for the Target (which is at least involved in the RM process) which elements are included in the message. There are frequently going to be times where where the LG/Target doesn't include elements it knows (i.e., could have included) for various reasons. Perhaps the Target didn't want to include the seat number it was at in the cube it was in, but include the floor on up... >or even just a signed GML document. However, the concept of signed >location is not inimical to the GEOPRIV model. Let me try to clarify >a few misconceptions: > >First, there is not a requirement in 3693 that the Target be a Rule >Maker, only that the Location Server respect the rules specified by >the Location Generator (in the Location Object) and by the RM. In the LbyV delivery of location, nearly all of the time, I believe the UAC to be the LG >In the scenario where a PSAP is handing out signed LOs, there >wouldn't even really be an RM in the distribution process. I think that is violating the 3693 process, one in which the RM makes the policy decisions as to who gets what about a Target. What you describe here is a scenario in which both the Target *and* the SP are not the RM. This was not envisioned in 3693. >The PSAP would be the LG, the access network would be the LS, and >the endpoint would be the LR. I think this makes the PSAP the tail that wags the location dog for all location usages. Do you agree? >Second, in the PSAP-signed-location scenario, it's OK that there's >no access controls, because the signed LOs are "raw" LOs -- they >don't have any identity information, since the PSAP doesn't know who >the LS is going to send them to. And it's a long-held GEOPRIV tenet >that location information by itself (without identity) doesn't need >the protections provided by privacy rules. I'm not sure what you mean by ""raw" LOs", unless you mean raw for a given Target. To me that's just another form of LI, making the delivery system to the Target another LCP (which is not defined yet). >Third, the RM is not necessarily an entity that specifies elements >in a PIDF-LO. oh, I think it is. The RM decides who gets what location from an LG (on behalf of a Target, if the Target is not the LG itself). I think this is the short definition for an RM. >Rules are propagated in two ways in the 3693 model, within the >PIDF-LO (from the LG), and directly from the RM to the LS. I think you're missing the part where the RM gets to decide the policy of whether or not the Location Seeker even gets a response (i.e., who gets location at all, and if a Seeker gets location, which parts of the Target's location do they get). I think you are leaving this (important) part out in your analysis. >So the RM (or the Target acting as an RM) could specify access >controls on a signed LO, but could not specify rules that would >modify the LO returned. This is broken IMO. The Target was and is always part of the RM process, although they might not have final say over all the pieces of the RM process. In other words, there might be a SP rule that nothing below street/street number be allowed in any location given out by the LG (because that entity might not want too precise a location given out for whatever reason). Yet, the SP generally wouldn't have a clue about any individuals the Target has blacklisted. Both of these are RM policies, yet I read that you don't want the RM to be either the Target or SP (or enterprise?)... I don't happen to agree with that model. It places complete control for all location in the hands of PSAPs, and omits how large the location universe will be that doesn't involve emergency services.' Again, PSAPs shouldn't wag the location dog, IMO. >Fourth, the Target can always use the signed LO to create a new LO >with whatever location and privacy rules it wants -- it just can't >then claim that the results were signed just because the original LO >was signed. I'm not sure yet what you mean by "it just can't then claim that the results were signed", because in all scenarios other than what you're talking about here, no one would be making any such claim - principally because there's no means of informing in a SIP or PIDF-LO element or header. This element doesn't exist in the PIDF-LO, and it isn't defined in any SIP header either. >This is the correct result, since the new LO actually wasn't signed >by the PSAP! But they aren't signed in any architecture either... color me confused by your message >Cheers, >--Richard > > > > > > > > >James M. Polk wrote: >>At 08:35 PM 5/13/2008, Richard Barnes wrote: >>>Certainly. I wasn't claiming that that was the recommendation of the >>>IETF in any way, just that it was allowed. Using signed location in >>>that way is not inconsistent with either location-conveyance or >>>framework/phonebcp; it's one option that a jurisdiction could employ to >>>assure the validity of static civic location information. >>I believe you are advocating (explicit) in your solution here to >>only that which disallows the UAC to modify a single XML element >>within the PIDF-LO message body. Though, at the moment I don't >>believe location-conveyance says this must be possible, I believe >>this is likely mandatory (at least in spirit of Geopriv docs) but >>for the mere fact that the owner of the UAC (i.e., the target) >>needs to be a rulemaker (but not necessarily the only one) and >>set/enter/include some of the elements (at least) such as , >>, and - each of which >>wouldn't be allowed if the whole PIDF-LO had a signature covering >>it. Yet, these are not necessarily, and often cannot be known to >>the LIS or PSAP at the time of the LCP response initially sending >>the PIDF-LO to the UAC (DHCP client in this case). >>What am I missing? >> >>>--RLB >>> >>> >>> >>>hannes.tschofenig@nsn.com wrote: >>>>We did not agree todo anything close to (2). >>>> >>>>>-----Original Message----- >>>>>From: ext Richard Barnes [mailto:rbarnes@bbn.com] >>>>>Sent: 13 May, 2008 20:37 >>>>>To: fmenard@xittelecom.com >>>>>Cc: Tschofenig Hannes (NSN - FI/Espoo); ecrit@ietf.org >>>>>Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>>>> >>>>>Francois, >>>>> >>>>>Let me answer your question in three parts: >>>>> >>>>>1. The spec allows the LbyV to be digitally signed. The >>>>>location is carried as a MIME body in the SIP message, and >>>>>thus can also be included in S/MIME form, signed, encrypted, >>>>>or both. See Appendix B of >>>>>draft-ietf-sip-location-conveyance-10 for an example. >>>> >>>10#appendix-B> >>>>>2. The signer does not necessarily have to be the PSAP (though >>>>>this is definitely allowed). In the model described in >>>>>framework/phonebcp, the endpoint gets its location from a >>>>>server in the access network to which it's connected, so when >>>>>we talk about location signing, I usually imagine that it's >>>>>signed by the access network's location server. >>>>>However, if a PSAP wanted to, it could provide signed location >>>>>objects to access networks in its jurisdiction that could then >>>>>be handed out to endpoints, who would then send them back to the PSAP: >>>>> >>>>>+------------+ >>>>>| PSAP |<------(3)--------+ >>>>>+------------+ | >>>>> | | >>>>> (1) | >>>>> | | >>>>> V | >>>>>+------------+ +----------+ >>>>>| Access Net |----(2)----->| Endpoint | >>>>>+------------+ +----------+ >>>>> >>>>>3. The IETF has not defined anything directly analogous to the >>>>>MSAG, in the sense of a consolidated database (in fact, I >>>>>believe that the NENA >>>>>i3 architecture does away with the MSAG entirely). However, >>>>>there is a location validation function provided by the LoST protocol: >>>>> >>>>>There is no current standard way for a location to be marked >>>>>as valid (this could be hard, since notions of validity vary >>>> >from place to place), but a PSAP could easily verify that a >>>>>location is valid using LoST. >>>>> >>>>>Cheers, >>>>>--Richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>Francois Menard wrote: >>>>>>Does the spec calls for digitally signing the LbyV by the PSAP, such >>>>>>that the PSAP can recognize an LbyV as being signed by itself as >>>>>>dispatch-able (i.e. MSAG-VALID), msag=master street address guide. >>>>>> >>>>>>F. >>>>>> >>>>>>-----Original Message----- >>>>>>From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>>Sent: 13 mai 2008 07:39 >>>>>>To: Francois Menard >>>>>>Cc: ; ecrit@ietf.org >>>>>>Subject: Re: [Ecrit] Joint Meeting with the 3GPP >>>>>> >>>>>>Francois, >>>>>> >>>>>>I don't have a complete list, but to answer your specific question, >>>>>>location is transmitted by value from the endpoint to the >>>>>PSAP in the >>>>>>SIP INVITE message using the mechanism described in >>>>>>draft-ietf-sip-location-conveyance. >>>>>> >>>>>>--Richard >>>>>> >>>>>> >>>>>> >>>>>>Francois Menard wrote: >>>>>>>So that we may come prepared to this meeting, could you >>>>>provide links >>>>>>>to the latest specs, particularly the transmission of location by >>>>>>>value from the end-point to the PSAP. >>>>>>> >>>>>>>F. >>>>>>> >>>>>>> >>>>>>>On 13-May-08, at 2:58 AM, >>>>>>>>>>>> > wrote: >>>>>>> >>>>>>>>Hi all, >>>>>>>> >>>>>>>>We would like to inform you that we are currently planning to >>>>>>>>organize a meeting with the 3GPP around August 2008. The >>>>>main topic >>>>>>>>for our discussion is the harmonization of the 3GPP and the IETF >>>>>>>>emergency services architecture. >>>>>>>> >>>>>>>>We will distribute more details as soon as they are available. >>>>>>>> >>>>>>>>Ciao >>>>>>>>Hannes & Marc >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Ecrit mailing list >>>>>>>>Ecrit@ietf.org >>>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>-- >>>>>>>Francois Menard >>>>>>>fmenard@xittelecom.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 >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 16 03:15:15 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F96F3A6859; Fri, 16 May 2008 03:15:15 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4327F3A6883 for ; Fri, 16 May 2008 03:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXLhGt401vPY for ; Fri, 16 May 2008 03:15:12 -0700 (PDT) Received: from anchor-internal-1.mail.demon.net (anchor-internal-1.mail.demon.net [195.173.56.100]) by core3.amsl.com (Postfix) with ESMTP id 8D62C3A6859 for ; Fri, 16 May 2008 03:15:11 -0700 (PDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id m4GAF0I8004743Fri, 16 May 2008 10:15:01 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1Jwwxa-000O7Q-00; Fri, 16 May 2008 11:14:46 +0100 Date: Fri, 16 May 2008 11:14:46 +0100 From: "Clive D.W. Feather" To: Marc Linsner Message-ID: <20080516101446.GH88947@finch-staff-1.thus.net> References: <001501c8b61d$d279bec0$45aa520a@MLINSNER> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <001501c8b61d$d279bec0$45aa520a@MLINSNER> User-Agent: Mutt/1.5.3i Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Marc Linsner said: > You are comfortable denying Andy emergency care because he performed per the > instructions on the back of his hotel room door that states: "In case of > emergency, dial 9-9-9." ?? Since this thread is filling my mailbox, I'm going to stick in my two-penn'orth. (1) Where I live, 999 is the emergency dial string. If I take my device abroad with me, it would be really really nice if 999 still worked. (2) If I'm somewhere where 08 is the emergency dial string, then it would be really really nice if a passerby can pick up my device while I'm lying injured in the street, dial 08, and have it work. My understanding is that (2) is a regulatory requirement in many places. It naively seems obvious to me that (1) can be programmed into the device, but no doubt there are issues that are causing this thread. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 16 05:52:30 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A38828C1A2; Fri, 16 May 2008 05:52:30 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5F128C1A2 for ; Fri, 16 May 2008 05:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, 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 GoBMjtfOLTE4 for ; Fri, 16 May 2008 05:52:24 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id B783628C196 for ; Fri, 16 May 2008 05:52:21 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so739516fga.41 for ; Fri, 16 May 2008 05:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=Rd83N370I6NDcdcfl+41E8uH/E3JHFzMIvO49l/Wzx0=; b=RMjrx7PFT9Pl+Dq4Oq7g+lLlzg7ypY2DhpncdKqaMVQnZ7Ia5bZQ+mzvlU3PaujAShscPX5S0whKHxZOocMv99lZijCfkCqUxapRNz1LJctZZEVFeReWIJvQA53bIaeUhNdeZ/JxKbz83SqGAnhXBz9jTq0zb39McHNtndVj2k4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=BhsY47wPBTpYplZuZCmM0Nw1DQYzmhd4JY8escuwm31GhEuvAAj+48uMpBZzXaTF9zOfjot9B4Z26SHW7TnY0On4/K71reP01A5yZfC+ZtCKP4Dy5RBVYJJJSTQmuer1e2TnUO0CLVJqjOJL8ZLaBU/37qafI84DRGTuBfmG1hM= Received: by 10.82.188.14 with SMTP id l14mr452495buf.85.1210942335890; Fri, 16 May 2008 05:52:15 -0700 (PDT) Received: by 10.82.165.10 with HTTP; Fri, 16 May 2008 05:52:15 -0700 (PDT) Message-ID: Date: Fri, 16 May 2008 14:52:15 +0200 From: "Karl Heinz Wolf" To: ECRIT MIME-Version: 1.0 Content-Disposition: inline Subject: [Ecrit] LoST getServiceBoundary and type of location information X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I have a question regarding Section 9 of lost-09, retrieving the service Boundary via getServiceBoundary. The sample shows the following steps: 1. Step findService with geodetic-2d location profile, serviceBoundary requested as reference findServiceResponse returns the key for the serviceBoundary. 2. Step getServiceBoundary with the key getServiceboundaryResponse with location profile civic is returned. So this sample assumes that the client just has geo location (therefore just the geo location is included in the findService request), but surprisingly gets back a civic serviceBoundary. What can the client do with this boundary information now? When requesting the boundary by value, there is the rule in the lost-draft that there has to be a boundary in the same location type as included in the request. But when retrieving the boundary via getServiceBoundary, I couldn't find such a rule in the draft, and also the sample shows a civic boundary response to a geo request. Have I overlooked something? Karl Heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 16 18:58:34 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 864203A69AD; Fri, 16 May 2008 18:58:34 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7AF53A6BF3 for ; Fri, 16 May 2008 18:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 shIoANKeaO4Y for ; Fri, 16 May 2008 18:58:31 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.54.111.226]) by core3.amsl.com (Postfix) with ESMTP id 942663A68BD for ; Fri, 16 May 2008 18:58:31 -0700 (PDT) Received: from [209.173.57.233] (helo=BROSLT61xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1JxBgb-0002vU-2Z; Fri, 16 May 2008 20:58:14 -0500 From: "Brian Rosen" To: "'Clive D.W. Feather'" , "'Marc Linsner'" References: <001501c8b61d$d279bec0$45aa520a@MLINSNER> <20080516101446.GH88947@finch-staff-1.thus.net> Date: Fri, 16 May 2008 21:58:14 -0400 Message-ID: <00d301c8b7c1$7d1b2040$6d3df544@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Aci3Pbno3SiQ3imtS+WT0N7AId/MegAg1tIQ In-Reply-To: <20080516101446.GH88947@finch-staff-1.thus.net> 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] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yah, that's what I think. You can provide the home dial string via provisioning (we usually think SIP Configuration) by the home network. You discover the local dial string via LoST. As long as the device does this, no problem. We observe that it may be possible for a proxy to do it, but it's really hard, because the proxy doesn't know the location of the device usually. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Clive D.W. Feather Sent: Friday, May 16, 2008 6:15 AM To: Marc Linsner Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Marc Linsner said: > You are comfortable denying Andy emergency care because he performed per the > instructions on the back of his hotel room door that states: "In case of > emergency, dial 9-9-9." ?? Since this thread is filling my mailbox, I'm going to stick in my two-penn'orth. (1) Where I live, 999 is the emergency dial string. If I take my device abroad with me, it would be really really nice if 999 still worked. (2) If I'm somewhere where 08 is the emergency dial string, then it would be really really nice if a passerby can pick up my device while I'm lying injured in the street, dial 08, and have it work. My understanding is that (2) is a regulatory requirement in many places. It naively seems obvious to me that (1) can be programmed into the device, but no doubt there are issues that are causing this thread. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 16 20:47:55 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A79D3A6880; Fri, 16 May 2008 20:47:55 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0FF3A6880 for ; Fri, 16 May 2008 20:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 KhDEL7YN8orC for ; Fri, 16 May 2008 20:47:52 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4746C3A67D5 for ; Fri, 16 May 2008 20:47:51 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2008_05_16_23_01_49 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, 16 May 2008 23:01:49 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 May 2008 22:47:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 22:47:31 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Thread-Index: Aci3Pbno3SiQ3imtS+WT0N7AId/MegAg1tIQAAPppNY= References: <001501c8b61d$d279bec0$45aa520a@MLINSNER><20080516101446.GH88947@finch-staff-1.thus.net> <00d301c8b7c1$7d1b2040$6d3df544@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Clive D.W. Feather" , "Marc Linsner" X-OriginalArrivalTime: 17 May 2008 03:47:46.0420 (UTC) FILETIME=[C4E0B340:01C8B7D0] Cc: ECRIT Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Yes, but nice is not a must, it is a should! -----Original Message----- From: ecrit-bounces@ietf.org on behalf of Brian Rosen Sent: Fri 5/16/2008 8:58 PM To: 'Clive D.W. Feather'; 'Marc Linsner' Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Yah, that's what I think. You can provide the home dial string via provisioning (we usually think SIP Configuration) by the home network. You discover the local dial string via LoST. As long as the device does this, no problem. We observe that it may be possible for a proxy to do it, but it's really hard, because the proxy doesn't know the location of the device usually. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Clive D.W. Feather Sent: Friday, May 16, 2008 6:15 AM To: Marc Linsner Cc: 'ECRIT' Subject: Re: [Ecrit] [Fwd: 3GPP2 TSG-X Corr to IETF re ECRIT/WGLC] Marc Linsner said: > You are comfortable denying Andy emergency care because he performed per the > instructions on the back of his hotel room door that states: "In case of > emergency, dial 9-9-9." ?? Since this thread is filling my mailbox, I'm going to stick in my two-penn'orth. (1) Where I live, 999 is the emergency dial string. If I take my device abroad with me, it would be really really nice if 999 still worked. (2) If I'm somewhere where 08 is the emergency dial string, then it would be really really nice if a passerby can pick up my device while I'm lying injured in the street, dial 08, and have it work. My understanding is that (2) is a regulatory requirement in many places. It naively seems obvious to me that (1) can be programmed into the device, but no doubt there are issues that are causing this thread. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ 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 ecrit-bounces@ietf.org Sun May 18 13:16:53 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6D628C4A7; Sun, 18 May 2008 13:16:53 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A7428C548 for ; Sun, 18 May 2008 13:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnLVyRTIH0xH for ; Sun, 18 May 2008 13:16:44 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 9FC633A6DB8 for ; Sun, 18 May 2008 13:16:44 -0700 (PDT) Received: from [128.89.252.97] (helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JxpJB-0006Pg-3K; Sun, 18 May 2008 16:16:41 -0400 Message-ID: <48308EA8.7090303@bbn.com> Date: Sun, 18 May 2008 16:16:40 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: hannes.tschofenig@nsn.com References: In-Reply-To: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-lost-sync X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I think that this document is a good basis for an ECRIT work item. However, this work should be synchronized with the GIS-based solutions that NENA is looking into. --Richard hannes.tschofenig@nsn.com wrote: > Hi all, > > Henning gave a presentation about this draft at previous IETF meetings. > There was very positive feedback from the group. We would therefore like > to confirm the hum on the mailing list. If you have not stated your > opinion or if you object please let us know. > > Deadline for your response: 30 May 2008 > > Ciao > Hannes & Marc > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 28 04:19:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E4728C1FD; Wed, 28 May 2008 04:19:14 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3217128C1D1 for ; Wed, 28 May 2008 04:19:13 -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 QI2cp5FCtN1F for ; Wed, 28 May 2008 04:19:07 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 0354628C21F for ; Wed, 28 May 2008 04:18:50 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so103896ugd.46 for ; Wed, 28 May 2008 04:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=Gkd3QKas0svfO+uKiwpFqwyvbqUzqGM0OpqRNmV1erk=; b=msyj3j0xXksZ37r282sS12xc7Xk5Borw60f8AxpLX81+WWn+7bgwKWTnIS0IxYCtXyN0cdJRzcJ1LtyCB4aZ0AMgkuUHR9MfYwDI4ZFqomtM5Ao7P+6CI8UqxpKGbwHL4Z0h7Jr5n283r2ledIlmbfVcdAm5DdQPMx9puPqyvGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=AutCPXvY9rmi78sqhYcfHzeIXEaa1jVyfZQiiEB4J9JdREtEg9NTcYLFRCZ1IZa8ed8Kz1FHaTfLxwEremB0VSIdKZfJP4KtKa0MWHk0T0oDJyIuGH9UWUr1sbuiwYITZwhzCiOzwYgrPJtmdQZTJMkBSrn4ypmvoZ44p8j23OY= Received: by 10.66.249.20 with SMTP id w20mr3519133ugh.67.1211973537289; Wed, 28 May 2008 04:18:57 -0700 (PDT) Received: by 10.67.30.1 with HTTP; Wed, 28 May 2008 04:18:57 -0700 (PDT) Message-ID: Date: Wed, 28 May 2008 13:18:57 +0200 From: "Karl Heinz Wolf" To: ECRIT , "Hannes Tschofenig" MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Ecrit] Service Boundary and listServicesByLocation / New Version Notification for draft-wolf-ecrit-lost-servicelistboundary-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I discussed this topic with Hannes at the last Emergency Workshop and he suggested to write a draft. So here it is: A new version of I-D, draft-wolf-ecrit-lost-servicelistboundary-00.txt has been successfuly submitted by Karl Wolf and posted to the IETF repository. Filename: draft-wolf-ecrit-lost-servicelistboundary Revision: 00 Title: Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary Creation_date: 2008-05-28 WG ID: Independent Submission Number_of_pages: 8 Abstract: LoST [I-D.ietf-ecrit-lost] is able to map service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the response from the LoST server does not give information about the geographical region, for which the returned service list is valid. Therefore this document proposes a ServiceListBoundary, in addition to the ServiceBoundary (which indicates the region a specific service URL is valid). The IETF Secretariat. http://www.ietf.org/internet-drafts/draft-wolf-ecrit-lost-servicelistboundary-00.txt Feedback and comments are appreciated. cheers karl heinz On Mon, Jan 14, 2008 at 3:26 PM, Karl Heinz Wolf wrote: > I have a question about how a mobile client notices a change of > available emergency services when moving. Maybe I've just got > something wrong. > > LoST returns a service boundary for a service when a client does a > findService. So the client knows the area, this particular mapping is > valid. > When a client requests listServicesByLocation, no boundary information > is provided telling where this list of services applicable. So, when > is a client expected to do a listServicesByLocation query again? > For example, the client moves to an area where a mountain rescue > service is available, but the listServicesByLocation was done at a > location where no mountain rescue is available. > Did I read over a rule on when to do a listServicesByLocation? > > cheers > karl heinz > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed May 28 07:42:22 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF163A6907; Wed, 28 May 2008 07:42:22 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A5F3A69A5 for ; Wed, 28 May 2008 07:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0u96fcmmZLD for ; Wed, 28 May 2008 07:42:15 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id EF6AB3A6808 for ; Wed, 28 May 2008 07:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1211985743; x=1243521743; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20 |Date:=20Wed,=2028=20May=202008=2007:42:19=20-0700|To:=20 Karl=20Heinz=20Wolf=20,=20ECRIT=20,=0D=0A=20=20=20=20=20=20=20=20Hannes=0D=0A =20Tschofenig=20|From:=20Ted =20Hardie=20|Subject:=20Re:=20[Ecrit ]=20Service=20Boundary=20and=20listServicesByLocation=20/ =20New=20=0D=0A=20Version=20Notification=20for=09draft-wo lf-ecrit-lost-servicelistboundary-00|Content-Type:=20text /plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcA fee=3Bi=3D"5200,2160,5304"=3B=20a=3D"3286844"; bh=r54tZHSxqy9BuxKO2ba66Mv73SNT6SZceEmNv2iSUzs=; b=TMHRkQ9TxFfYkY4gx0MqcaPZXhZfVn9V8iFayu/zDYQuvkE6Nlww4rka hT7mA20dXcSWuNEvwsVRT0NEnsQ96jbjJg/H49wuO+ytvoROjelGV7t7x j+43hqa+trt00aQydNqtnIVMTt6f3/eIj9PENfJrmvRDB9+ys37DV5UCE U=; X-IronPort-AV: E=McAfee;i="5200,2160,5304"; a="3286844" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 May 2008 07:42:23 -0700 Received: from msgtransport06.qualcomm.com (msgtransport06.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4SEgMfE010368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 May 2008 07:42:23 -0700 Received: from nasanexhc03.na.qualcomm.com (nasanexhc03.na.qualcomm.com [172.30.33.34]) by msgtransport06.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m4SEgMG2002838 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 May 2008 07:42:22 -0700 Received: from [129.46.226.27] (129.46.226.27) by qcmail1.qualcomm.com (172.30.33.34) with Microsoft SMTP Server (TLS) id 8.1.278.0; Wed, 28 May 2008 07:42:21 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: Date: Wed, 28 May 2008 07:42:19 -0700 To: Karl Heinz Wolf , ECRIT , Hannes Tschofenig From: Ted Hardie Subject: Re: [Ecrit] Service Boundary and listServicesByLocation / New Version Notification for draft-wolf-ecrit-lost-servicelistboundary-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi, I just took a quick look through the draft, and I have a couple of questions. The core of the draft's purpose seems to be this; Clients can discover available services for a particular location by the query. The LoST server returns a list of services that are available at this particular location. But the server does not inform the client, for which geographical region the returned service list is valid. This may lead to the situation where a client initially discovered all available services by the query, and then moves to a different location while refreshing the service mappings, but does not notice the availability of another service. So if I originally do listServicesByLocation in a flat part of the country, I may not know of Mountain Rescue services; I either have to periodically query using the listServicesByLocation (to see if something new is available) or do without Mountain Rescue even if it is available after I've left the flat lands. Does that capture your aim? First, I think we should all be clear that in emergency services we're dealing with a registered list, so that listServicesByLocation will only ever tell you which items from a known set of items is available. The list is small, and I expect it to be cached. Does that make sense to you? If so, we're using this mechanism not to expand the list, but to indicate when you need to check to see if the "available" state for items on it has changed. Assuming I have your aim right, I see this as a potentially useful optimization. Rather than have periodic client queries drive the discovery process, you shift the work to those creating the mapping databases to generate these boundaries. I'm not actually sure how much this optimization is needed, as I see the listServicesByLocation as fairly easy and likely to be piggy-backed on other queries (when refreshing cached data that has expired, for example), but I also don't see any harm in it. My only real concern is that it may be fairly difficult (especially outside of emergency services) to generate these boundaries, as it may require knowledge at a level higher than that of the authoritative server for a particular region. That means to me that this response must be interpreted as "list valid at least for this area" rather than "response is authoritative boundary;there will be change outside this". Some additional questions: why not include the profiles the client understands in the query, so that the server does not bother returning boundaries in a profile the client does not understand? what errors and warnings do you thing you need? is the expires value in the ServiceBoundary mandatory? regards, Ted Hardie At 4:18 AM -0700 5/28/08, Karl Heinz Wolf wrote: >I discussed this topic with Hannes at the last Emergency Workshop and >he suggested to write a draft. So here it is: > >A new version of I-D, draft-wolf-ecrit-lost-servicelistboundary-00.txt >has been successfuly submitted by Karl Wolf and posted to the IETF >repository. > >Filename: draft-wolf-ecrit-lost-servicelistboundary >Revision: 00 >Title: Location-to-Service Translation Protocol (LoST) Extension: >ServiceListBoundary >Creation_date: 2008-05-28 >WG ID: Independent Submission >Number_of_pages: 8 > >Abstract: >LoST [I-D.ietf-ecrit-lost] is able to map service identifiers and >location information to service contact URIs. If a LoST client wants >to discover available services for a particular location, it will >perform a query to the LoST server. >However, the response from the LoST server does not give information >about the geographical region, for which the returned service list is >valid. Therefore this document proposes a ServiceListBoundary, in >addition to the ServiceBoundary (which indicates the region a >specific service URL is valid). > > > >The IETF Secretariat. > > >http://www.ietf.org/internet-drafts/draft-wolf-ecrit-lost-servicelistboundary-00.txt > > >Feedback and comments are appreciated. > >cheers >karl heinz > > >On Mon, Jan 14, 2008 at 3:26 PM, Karl Heinz Wolf wrote: >> I have a question about how a mobile client notices a change of >> available emergency services when moving. Maybe I've just got >> something wrong. >> >> LoST returns a service boundary for a service when a client does a >> findService. So the client knows the area, this particular mapping is >> valid. >> When a client requests listServicesByLocation, no boundary information >> is provided telling where this list of services applicable. So, when >> is a client expected to do a listServicesByLocation query again? >> For example, the client moves to an area where a mountain rescue >> service is available, but the listServicesByLocation was done at a >> location where no mountain rescue is available. >> Did I read over a rule on when to do a listServicesByLocation? >> >> cheers >> 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 From ecrit-bounces@ietf.org Wed May 28 12:27:36 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42883A6AFA; Wed, 28 May 2008 12:27:36 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8587B3A6A8C for ; Wed, 28 May 2008 12:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0pU8mT07oPo for ; Wed, 28 May 2008 12:27:35 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 771893A69F6 for ; Wed, 28 May 2008 12:27:35 -0700 (PDT) Received: from [128.59.20.159] (irt-af.cs.columbia.edu [128.59.20.159]) (user=agf2104 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m4SJRfHJ002908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 28 May 2008 15:27:42 -0400 (EDT) Message-ID: <483DB2B0.5060400@cs.columbia.edu> Date: Wed, 28 May 2008 15:29:52 -0400 From: "Andrea G. Forte" User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: ecrit@ietf.org X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.8 Subject: [Ecrit] draft-forte-ecrit-service-classification-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0333740654==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0333740654== Content-Type: multipart/alternative; boundary="------------050304090901000800040605" This is a multi-part message in MIME format. --------------050304090901000800040605 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, we have submitted a new draft for defining URNs in the location-based service context. Details are below. -Andrea -------- Original Message -------- Subject: New Version Notification for draft-forte-ecrit-service-classification-00 Date: Wed, 28 May 2008 12:18:42 -0700 (PDT) From: IETF I-D Submission Tool To: andreaf@cs.columbia.edu CC: hgs@cs.columbia.edu A new version of I-D, draft-forte-ecrit-service-classification-00.txt has been successfuly submitted by Andrea Forte and posted to the IETF repository. Filename: draft-forte-ecrit-service-classification Revision: 00 Title: Classification of Location-based Services Creation_date: 2008-05-27 WG ID: Independent Submission Number_of_pages: 12 Abstract: This document creates a registry for describing the types of services available at a specific location. The registry is then referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). The IETF Secretariat. -- http://www.cs.columbia.edu/~andreaf --------------050304090901000800040605 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

we have submitted a new draft for defining URNs in the location-based service context. Details are below.

-Andrea


-------- Original Message --------
Subject: New Version Notification for draft-forte-ecrit-service-classification-00
Date: Wed, 28 May 2008 12:18:42 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission@ietf.org>
To: andreaf@cs.columbia.edu
CC: hgs@cs.columbia.edu 


A new version of I-D, draft-forte-ecrit-service-classification-00.txt has been successfuly submitted by Andrea Forte and posted to the IETF repository.

Filename:	 draft-forte-ecrit-service-classification
Revision:	 00
Title:		 Classification of Location-based Services
Creation_date:	 2008-05-27
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
This document creates a registry for describing the types of services
available at a specific location.  The registry is then referenced by
other protocols that need a common set of service terms as protocol
constants.  In particular, we define location-based service as either
a point at a specific geographic location (e.g., bus stop) or a
service covering a specific region (e.g., pizza delivery).
                                                                                  


The IETF Secretariat.

--
http://www.cs.columbia.edu/~andreaf
--------------050304090901000800040605-- --===============0333740654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============0333740654==-- From ecrit-bounces@ietf.org Wed May 28 12:45:13 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F7D28C174; Wed, 28 May 2008 12:45:13 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E54E33A6AA4; Wed, 28 May 2008 12:45:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080528194506.E54E33A6AA4@core3.amsl.com> Date: Wed, 28 May 2008 12:45:05 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --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 : LoST: A Location-to-Service Translation Protocol Author(s) : T. Hardie, et al. Filename : draft-ietf-ecrit-lost-10.txt Pages : 79 Date : 2008-05-28 This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-28124148.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Wed May 28 12:45:14 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEE6728C18D; Wed, 28 May 2008 12:45:14 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7D0D03A6A7A; Wed, 28 May 2008 12: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: <20080528194502.7D0D03A6A7A@core3.amsl.com> Date: Wed, 28 May 2008 12:45:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-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: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --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 : LoST: A Location-to-Service Translation Protocol Author(s) : T. Hardie, et al. Filename : draft-ietf-ecrit-lost-10.txt Pages : 79 Date : 2008-05-28 This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-10.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-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-28124148.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Thu May 29 00:48:23 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBB5528C135; Thu, 29 May 2008 00:48:23 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA873A68BD for ; Thu, 29 May 2008 00:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35IbyUXdlXeW for ; Thu, 29 May 2008 00:48:19 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by core3.amsl.com (Postfix) with ESMTP id 8C55728C250 for ; Thu, 29 May 2008 00:47:55 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so34886ugd.46 for ; Thu, 29 May 2008 00:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=z2Dv1rGgWqy8wNTsKtM1LpSMLcmpejDMI5iCR3F2/fY=; b=tpFSBHR05SuGZgv/7h4ADP5P3Qs00oiUqRE9geDUrqquJIIgKoS3gaJC7eCfO2lavpvqrQdHDoRvs1LhHvlzAoDjFiN06Eq7GZhIlxAiVMf4rdug/jZ9T4UBcudrvM7668zxzWgAbAPfO9VqWjKzly47aCIwPDfRbX8aeu+dzmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IRqRbJv/Wb4yN4pCoNsYF5rDse1dQUnNr+GFmvQXaujixwU6XTWiLq2CfFwz6DgtekOLleN/4dzZ4z1LDTBbHBx/A2Da2HHuxKgeJCaxq91eNvrTtKu0QIkopr0eYRXt4i+zmQs4ntLUk2C2OaZEu4UL8s+i73KV4t9sD8HOcrs= Received: by 10.67.116.4 with SMTP id t4mr533731ugm.68.1212047273305; Thu, 29 May 2008 00:47:53 -0700 (PDT) Received: by 10.67.30.1 with HTTP; Thu, 29 May 2008 00:47:53 -0700 (PDT) Message-ID: Date: Thu, 29 May 2008 09:47:53 +0200 From: "Karl Heinz Wolf" To: "Ted Hardie" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: ECRIT Subject: Re: [Ecrit] Service Boundary and listServicesByLocation / New Version Notification for draft-wolf-ecrit-lost-servicelistboundary-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi Ted, thank you for your response. See my comments inline. On Wed, May 28, 2008 at 4:42 PM, Ted Hardie wrote: > Hi, > I just took a quick look through the draft, and I have a > couple of questions. The core of the draft's purpose seems to > be this; > > Clients can discover available services for a > particular location by the query. The LoST > server returns a list of services that are available at this > particular location. But the server does not inform the client, for > which geographical region the returned service list is valid. This > may lead to the situation where a client initially discovered all > available services by the query, and then > moves to a different location while refreshing the service mappings, > but does not notice the availability of another service. > > So if I originally do listServicesByLocation in > a flat part of the country, I may not know of > Mountain Rescue services; I either have to periodically > query using the listServicesByLocation (to see if something > new is available) or do without Mountain Rescue even if it > is available after I've left the flat lands. Does that capture > your aim? yes. > First, I think we should all be clear that in > emergency services we're dealing with a registered list, > so that listServicesByLocation will only ever tell you which > items from a known set of items is available. The list > is small, and I expect it to be cached. Does that make sense > to you? I'm not sure what the advantage for the client is, when he knows all the 10 SOS services registered in RFC5031, but at its current location just 1 SOS service is available. Since you can learn the available services with listServicesBylocation, I would expect this query to be the first. Anyway, if the client knows all registered SOS services, and findService says this service is not available at THIS location - when should the client try a findService again? This is the point I'm concerned about. > If so, we're using this mechanism not to expand > the list, but to indicate when you need to check to see if > the "available" state for items on it has changed. yes, my concern is that a client does not notice a new service when moving ("new" does not mean it is not defined in RFC5031, but it was not available at the old location). > Assuming I have your aim right, I see this as a > potentially useful optimization. Rather than have periodic > client queries drive the discovery process, you shift the work > to those creating the mapping databases to generate > these boundaries. I'm not actually sure how much this > optimization is needed, as I see the listServicesByLocation > as fairly easy and likely to be piggy-backed on other > queries (when refreshing cached data that has expired, > for example), A ServiceList may change independent of the service boundary of a particular service or the expiry of cached data of other services. So when should a client perform a listServicesByLocation query? every second? any time moving 1 mm? I think it is the same issue as for the Serviceboundary. > but I also don't see any harm in it. My only real concern > is that it may be fairly difficult (especially outside of emergency services) > to generate these boundaries, as it may require knowledge > at a level higher than that of the authoritative server for > a particular region. That means to me that this response > must be interpreted as "list valid at least for this area" rather > than "response is authoritative boundary;there will be change outside > this". I agree. I could be difficult to get the pizza servicelistboundary. > Some additional questions: why not include > the profiles the client understands in the query, so that the > server does not bother returning boundaries in a profile > the client does not understand? Of course, this makes sense. This is possible in LoST for the ServiceBoundary? I'm afraid I overlooked this. I only read that the server must use one profile the client utilized in the request and may use other, additional profiles too. > what errors and warnings > do you thing you need? is the expires value in the ServiceBoundary > mandatory? I would suggest the ServiceListBoundary to be defined similar to the ServiceBoundary, so the same elements would be mandatory and probably there are no new errors and warnings necessary. I wrote this first version of the draft rather to point my concern out and to get feedback if such a mechanism is useful at all. cheers karl heinz > > At 4:18 AM -0700 5/28/08, Karl Heinz Wolf wrote: >>I discussed this topic with Hannes at the last Emergency Workshop and >>he suggested to write a draft. So here it is: >> >>A new version of I-D, draft-wolf-ecrit-lost-servicelistboundary-00.txt >>has been successfuly submitted by Karl Wolf and posted to the IETF >>repository. >> >>Filename: draft-wolf-ecrit-lost-servicelistboundary >>Revision: 00 >>Title: Location-to-Service Translation Protocol (LoST) Extension: >>ServiceListBoundary >>Creation_date: 2008-05-28 >>WG ID: Independent Submission >>Number_of_pages: 8 >> >>Abstract: >>LoST [I-D.ietf-ecrit-lost] is able to map service identifiers and >>location information to service contact URIs. If a LoST client wants >>to discover available services for a particular location, it will >>perform a query to the LoST server. >>However, the response from the LoST server does not give information >>about the geographical region, for which the returned service list is >>valid. Therefore this document proposes a ServiceListBoundary, in >>addition to the ServiceBoundary (which indicates the region a >>specific service URL is valid). >> >> >> >>The IETF Secretariat. >> >> >>http://www.ietf.org/internet-drafts/draft-wolf-ecrit-lost-servicelistboundary-00.txt >> >> >>Feedback and comments are appreciated. >> >>cheers >>karl heinz >> >> >>On Mon, Jan 14, 2008 at 3:26 PM, Karl Heinz Wolf wrote: >>> I have a question about how a mobile client notices a change of >>> available emergency services when moving. Maybe I've just got >>> something wrong. >>> >>> LoST returns a service boundary for a service when a client does a >>> findService. So the client knows the area, this particular mapping is >>> valid. >>> When a client requests listServicesByLocation, no boundary information >>> is provided telling where this list of services applicable. So, when >>> is a client expected to do a listServicesByLocation query again? >>> For example, the client moves to an area where a mountain rescue >>> service is available, but the listServicesByLocation was done at a >>> location where no mountain rescue is available. >>> Did I read over a rule on when to do a listServicesByLocation? >>> >>> cheers >>> 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 From ecrit-bounces@ietf.org Thu May 29 04:31:33 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4BC93A6AC6; Thu, 29 May 2008 04:31:33 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FCC93A6A37 for ; Thu, 29 May 2008 04:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7XZq+auPp1m for ; Thu, 29 May 2008 04:31:31 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by core3.amsl.com (Postfix) with ESMTP id CB53F28C245 for ; Thu, 29 May 2008 04:31:29 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id y36so78145ugd.46 for ; Thu, 29 May 2008 04:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/dlYSaJR1SJIxhYgno/L8xgTJHnGmnOWbvOQ34jRm6Q=; b=AbvE4RYM+iDRK7gdgXfOcleGZMAuW+24yBf7vHNKVWaWL9Wizll72h7xxu9IKTns5wgQeCj7F5hPqSnvzj0LxtKGfIEU/zgxPg5QF/21IYCXe5U/mOQFQlAwG6H2cQgulIyTmtWkTtfrS7BsBWsJlHVSwppFkAFQD7/HKeBN9Ag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nACVCtw/zDBC0i9RqHiVcAyCCcdlu0nAb9DdbbGdOThVNe1vS5PtRKRrZZcSV0iGzbipuIyO38MiCz9fGAaN/Vzlwe69ljWjSIk9VcND7h58rfxuAU34ETOlPZS2KaopP/8I+HZ02aVGZiI6PIfvMck0KfLoAXDy/caxrN7gx8I= Received: by 10.66.251.3 with SMTP id y3mr748113ugh.88.1212060687593; Thu, 29 May 2008 04:31:27 -0700 (PDT) Received: by 10.67.30.1 with HTTP; Thu, 29 May 2008 04:31:27 -0700 (PDT) Message-ID: Date: Thu, 29 May 2008 13:31:27 +0200 From: "Karl Heinz Wolf" To: ecrit@ietf.org In-Reply-To: <20080528194502.7D0D03A6A7A@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20080528194502.7D0D03A6A7A@core3.amsl.com> Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-lost-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org I just had a look at the new LoST document, and I remembered that I had some questions concerning LoST, I still got no answer for. Here are the points that still confuse me: 1) listServices and path indication: The draft says: "Since the query is answered by the queried server, there is no notion of recursion or indirection and no path indication." But the sample in figure 12 has a element. 2) the serviceNumber is still missing for the sample in figure 18, the default mapping sample (as mentioned here last year http://www.ietf.org/mail-archive/web/ecrit/current/msg04727.html ) Although the servieNumber is optional in LoST, I thought the samples should contain it since they are emergency call samples and without a service number one cannot call the default PSAP. 3) how to request a specific location profile for ? see http://www.ietf.org/mail-archive/web/ecrit/current/msg05226.html And I just noticed something new: profile="urn:ietf:params:lost:location-profile:basic-civic" is used once, all the other examples use profile="civic". editorial: there is a "s" missing in ListServicesResponse: "Figure 12: Example of " I hope someone can clarify my concerns! Thanks in advance. karl heinz 2008/5/28 : > 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 : LoST: A Location-to-Service Translation Protocol > Author(s) : T. Hardie, et al. > Filename : draft-ietf-ecrit-lost-10.txt > Pages : 79 > Date : 2008-05-28 > > This document describes an XML-based protocol for mapping service > identifiers and geodetic or civic location information to service > contact URIs. In particular, it can be used to determine the > location-appropriate Public Safety Answering Point (PSAP) for > emergency services. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-10.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 29 07:31:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4953A6B80; Thu, 29 May 2008 07:31:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41873A67F2 for ; Thu, 29 May 2008 07:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.652 X-Spam-Level: * X-Spam-Status: No, score=1.652 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_LOAN=2.3, 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 3e+SRqjn+hqz for ; Thu, 29 May 2008 07:31:08 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id EA92A3A6BA6 for ; Thu, 29 May 2008 07:31:07 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Thu, 29 May 2008 16:30:58 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 May 2008 16:30:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 16:30:56 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B04296B48@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req Thread-Index: Aci0yFKCAdMTvHCNQROxAcz1h6h62gMvLY9A References: From: "Liess, Laura" To: , X-OriginalArrivalTime: 29 May 2008 14:30:57.0824 (UTC) FILETIME=[9C1AA200:01C8C198] Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1143341242==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1143341242== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C198.9BFCB0AB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C198.9BFCB0AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is my personal hum and the hum of my company in favour of the "location hiding requirements" documenting effort.=20 =20 An additional comment:=20 James Polk also raised a very good point: users or end devices providing false location. But, as Brian pointed out, "a user or a device can always lie." In my opinion, if we choose the right solution(s), location hiding can improve this situation and minimize the risk that users lie about the location (and make the PSAPs life easier).=20 I don't want to discuss location hiding solutions, just try to an example where, in my opinion, the location information received by the PSAPs is more reliable with location hiding than without it. Example: if an end device finds out the ESRP (LOST query) based on a coarse location and sends in the INVITE to the ESRP instead of the precise location a location URI, the ESRP gets the precise location from the LIS based on the location URI. The ESRP then sends the precise location directly to the PSAP. Both the ESRP and the LIS are local and trusted by the local PSAP.=20 =20 Laura =20 _____ =20 Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im Auftrag von hannes.tschofenig@nsn.com Gesendet: Dienstag, 13. Mai 2008 09:10 An: ecrit@ietf.org Betreff: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req =20 Hi all,=20 Henning gave a presentation about this draft at previous IETF meetings. Although this is a controversal topic we believe it is important to capture the problem statement and the requirements. This document is NOT meant to capture solutions -- this is something for future work. We would therefore like to confirm the hum on the mailing list. If you have not stated your opinion or if you object please let us know.=20 Deadline for your response: 30 May 2008=20 Ciao=20 Hannes & Marc=20 ------_=_NextPart_001_01C8C198.9BFCB0AB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hum: draft-schulzrinne-ecrit-location-hiding-req

Here is my = personal hum and the hum of my company in favour of the “location hiding = requirements” documenting effort.

 =

An additional = comment:

James Polk also = raised a very good point: users or end devices providing false location. But, as = Brian pointed out, “a user or a device can always lie.”  In = my opinion, if we choose the right solution(s), location hiding can improve = this situation and minimize the risk that users lie about the location (and make the = PSAPs life easier).

I don’t = want to discuss location hiding solutions, just try to an example where, in my opinion, = the location information received by the PSAPs is more reliable with location hiding = than without it.  Example: if an end device finds out the ESRP (LOST = query) based on a coarse location and sends in the INVITE to the ESRP instead = of the precise location a location URI, the ESRP gets the precise location from = the LIS based on the location URI. The ESRP then sends the precise location = directly to the PSAP.  Both the ESRP and the LIS are local and trusted by the = local PSAP.

 =

Laura<= /span>

 

Von: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im = Auftrag von hannes.tschofenig@nsn.com
Gesendet: Dienstag, 13. = Mai 2008 09:10
An: ecrit@ietf.org
Betreff: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req

 

Hi all,

Henning gave a presentation about this draft at previous = IETF meetings. Although this is a controversal topic we believe it is = important to capture the problem statement and the requirements. This document is NOT = meant to capture solutions -- this is something for future work. We would = therefore like to confirm the hum on the mailing list. If you have not stated your opinion or if you object please let us know. =

Deadline for your response: 30 May 2008 =

Ciao
Hannes & Marc

------_=_NextPart_001_01C8C198.9BFCB0AB-- --===============1143341242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --===============1143341242==-- From ecrit-bounces@ietf.org Thu May 29 11:00:03 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC573A6BE1; Thu, 29 May 2008 11:00:03 -0700 (PDT) X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 47F6B3A6BC6; Thu, 29 May 2008 11:00:00 -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: <20080529180001.47F6B3A6BC6@core3.amsl.com> Date: Thu, 29 May 2008 11:00:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-dhc-lost-discovery-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org --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 : A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-dhc-lost-discovery-03.txt Pages : 9 Date : 2008-05-29 The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desireable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-dhc-lost-discovery-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-05-29105539.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Thu May 29 11:09:29 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92D83A6B82; Thu, 29 May 2008 11:09:29 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B13E3A6B82 for ; Thu, 29 May 2008 11:09:29 -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 skybr5zAe0Kj for ; Thu, 29 May 2008 11:09:28 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id BC1C23A6B38 for ; Thu, 29 May 2008 11:09:27 -0700 (PDT) Received: (qmail invoked by alias); 29 May 2008 18:09:25 -0000 Received: from a91-154-105-144.elisa-laajakaista.fi (EHLO [192.168.255.3]) [91.154.105.144] by mail.gmx.net (mp049) with SMTP; 29 May 2008 20:09:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19AkyJR+DRASzSRGAGlfoJi0XrQpLhj0zAQS3hAPw 7Fwx5DGAIDl54s Message-ID: <483EF155.1070903@gmx.net> Date: Thu, 29 May 2008 21:09:25 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: 'ECRIT' X-Y-GMX-Trusted: 0 Cc: Russ Housley , jari.arkko@ericsson.com, "Vijay K. Gurbani" Subject: [Ecrit] [Fwd: I-D Action:draft-ietf-ecrit-dhc-lost-discovery-03.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This draft update addresses the Gen-Art review by Vijay http://www.ietf.org/mail-archive/web/gen-art/current/msg02497.html and the IESG reviews: https://datatracker.ietf.org/idtracker/draft-ietf-ecrit-dhc-lost-discovery/ We didn't quite understand how to address Tim's issue but Henning has sent him a mail. Ciao Hannes -------- Original Message -------- Subject: I-D Action:draft-ietf-ecrit-dhc-lost-discovery-03.txt Date: Thu, 29 May 2008 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ecrit@ietf.org 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 : A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-dhc-lost-discovery-03.txt Pages : 9 Date : 2008-05-29 The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desireable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu May 29 11:34:18 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F66728C297; Thu, 29 May 2008 11:34:18 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5768E28C1B7 for ; Thu, 29 May 2008 11:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[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 QC6Cperlx+iZ for ; Thu, 29 May 2008 11:34:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8EC5528C2BC for ; Thu, 29 May 2008 11:30:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,562,1204531200"; d="scan'208";a="73711217" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 29 May 2008 11:30:09 -0700 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 m4TIU9fN016880; Thu, 29 May 2008 11:30:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4TIU9IZ014686; Thu, 29 May 2008 18:30:09 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 11:30:09 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.71.234]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 11:30:08 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 May 2008 13:30:07 -0500 To: "Liess, Laura" , , From: "James M. Polk" In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B04296B48@S4DE8PSAAGM.mitte .t-com.de> References: <182C63BFBAF131428EA0C16F7FD2191B04296B48@S4DE8PSAAGM.mitte.t-com.de> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 29 May 2008 18:30:08.0737 (UTC) FILETIME=[05EA2D10:01C8C1BA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2521; t=1212085809; x=1212949809; 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]=20Hum=3A=20draft-schulzrinne-ec rit-location-hiding-req |Sender:=20; bh=cshmG3zPgYxli9QUyZTaDRuZs4U4UfOXETjAfcYWwH0=; b=p6jndp1emSUQDxvoBr85xkd8nh6zT/xYnzd9IegyeLkX122LBmogdf0Ntc vNkssFexSxoJcg2BRz+cL7Ev9nzaqRN2Gs1Zhu04/ApROMQe4eZl66FjxZeB H48RrFYmss; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 09:30 AM 5/29/2008, Liess, Laura wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C8C198.9BFCB0AB" > >Here is my personal hum and the hum of my company in favour of the >"location hiding requirements" documenting effort. > >An additional comment: >James Polk also raised a very good point: users or end devices >providing false location. But, as Brian pointed out, "a user or a >device can always lie." In my opinion, if we choose the right >solution(s), location hiding can improve this situation and minimize >the risk that users lie about the location (and make the PSAPs life easier). >I don't want to discuss location hiding solutions, just try to an >example where, in my opinion, the location information received by >the PSAPs is more reliable with location hiding than without >it. Example: if an end device finds out the ESRP (LOST query) based >on a coarse location and sends in the INVITE to the ESRP instead of >the precise location a location URI, the ESRP gets the precise >location from the LIS based on the location URI. The ESRP then sends >the precise location directly to the PSAP. Both the ESRP and the >LIS are local and trusted by the local PSAP. Laura - you are assuming location is always provided by-reference, and not by-value (as demonstrated in your example by the PSAP retrieving more precise location from the LIS through another transaction). What if the UA's location is GPS derived, or otherwise given to the UA by-value? > >Laura > > > >---------- >Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im >Auftrag von hannes.tschofenig@nsn.com >Gesendet: Dienstag, 13. Mai 2008 09:10 >An: ecrit@ietf.org >Betreff: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req > > >Hi all, > >Henning gave a presentation about this draft at previous IETF >meetings. Although this is a controversal topic we believe it is >important to capture the problem statement and the requirements. >This document is NOT meant to capture solutions -- this is something >for future work. We would therefore like to confirm the hum on the >mailing list. If you have not stated your opinion or if you object >please let us know. > >Deadline for your response: 30 May 2008 > >Ciao >Hannes & Marc >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 30 00:49:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793653A67DA; Fri, 30 May 2008 00:49:57 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38063A6912 for ; Fri, 30 May 2008 00:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jemTPuCny06z for ; Fri, 30 May 2008 00:49:54 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 39CBB3A67A4 for ; Fri, 30 May 2008 00:49:54 -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 m4U7npOJ005907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 May 2008 09:49:51 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4U7nna5016249 for ; Fri, 30 May 2008 09:49:51 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 May 2008 09:49:51 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 May 2008 09:49:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 10:49:49 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification - draft-ietf-ecrit-dhc-lost-discovery-03.txt Thread-Index: AcjB0g3HMkEQkpd0TtysyJUiUnk5XwAVtFfg From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 30 May 2008 07:49:50.0450 (UTC) FILETIME=[BD3E8D20:01C8C229] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1026-15940.005 X-TM-AS-Result: No--3.902500-8.000000-31 Subject: [Ecrit] FW: New Version Notification - draft-ietf-ecrit-dhc-lost-discovery-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI >-----Original Message----- >From: ext Russ Housley [mailto:housley@vigilsec.com] >Sent: 30 May, 2008 00:13 >To: Internet-Draft@ietf.org; ecrit-chairs@tools.ietf.org; >draft-ietf-ecrit-dhc-lost-discovery@tools.ietf.org; >jon.peterson@neustar.biz; jari.arkko@piuha.net >Subject: Re: New Version Notification - >draft-ietf-ecrit-dhc-lost-discovery-03.txt > >I cleared my DISCUSS position. > >At 02:00 PM 5/29/2008, Internet-Draft@ietf.org wrote: >>New version (-03) has been submitted for >>draft-ietf-ecrit-dhc-lost-discovery-03.txt. >>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost- >discovery >>-03.txt Sub state has been changed to AD Follow up from New Id Needed >> >>IETF Secretariat. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 30 00:49:57 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986673A6C0D; Fri, 30 May 2008 00:49:57 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4DB3A67A4 for ; Fri, 30 May 2008 00:49:55 -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 5Uo0aKP-hi5F for ; Fri, 30 May 2008 00:49: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 49E7C3A67DA for ; Fri, 30 May 2008 00:49:54 -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 m4U7npBR006957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 May 2008 09:49:51 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m4U7nna7016249 for ; Fri, 30 May 2008 09:49:51 +0200 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 May 2008 09:49:51 +0200 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 May 2008 09:49:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 10:49:49 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification - draft-ietf-ecrit-dhc-lost-discovery-03.txt Thread-Index: AcjB00S3oulQelRlS8elMqJblnErjgAVaLDg From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ECRIT" X-OriginalArrivalTime: 30 May 2008 07:49:50.0903 (UTC) FILETIME=[BD83AC70:01C8C229] X-TM-AS-Product-Ver: SMEX-7.0.0.1584-5.5.1026-15940.005 X-TM-AS-Result: No--4.673500-8.000000-31 Subject: [Ecrit] FW: New Version Notification - draft-ietf-ecrit-dhc-lost-discovery-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org FYI >-----Original Message----- >From: ext Jari Arkko [mailto:jari.arkko@piuha.net] >Sent: 30 May, 2008 00:30 >To: Russ Housley; draft-ietf-ecrit-dhc-lost-discovery@tools.ietf.org >Cc: ecrit-chairs@tools.ietf.org; jon.peterson@neustar.biz >Subject: Re: New Version Notification - >draft-ietf-ecrit-dhc-lost-discovery-03.txt > >Me too. > >Jari > >Russ Housley kirjoitti: >> I cleared my DISCUSS position. >> >> At 02:00 PM 5/29/2008, Internet-Draft@ietf.org wrote: >>> New version (-03) has been submitted for >>> draft-ietf-ecrit-dhc-lost-discovery-03.txt. >>> >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discove >>> ry-03.txt >>> >>> Sub state has been changed to AD Follow up from New Id Needed >>> >>> IETF Secretariat. >> >> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 30 13:01:27 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0D43A691E; Fri, 30 May 2008 13:01:27 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6923A691E for ; Fri, 30 May 2008 13:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LOAN=2.3, 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 zvYEBKvA6+SH for ; Fri, 30 May 2008 13:01:25 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id AE4263A68E1 for ; Fri, 30 May 2008 13:01:24 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Fri, 30 May 2008 22:01:12 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 May 2008 22:01:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 22:01:10 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B0429702D@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req Thread-Index: AcjBuj8vBOh2RDu1SvKqXrMXOKFxxwAzI3oA References: <182C63BFBAF131428EA0C16F7FD2191B04296B48@S4DE8PSAAGM.mitte.t-com.de> From: "Liess, Laura" To: X-OriginalArrivalTime: 30 May 2008 20:01:12.0481 (UTC) FILETIME=[E8F91910:01C8C28F] Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org James, The example was just one possible scenario, not the general case. = If the UA has a location-by-value, GPS derived or received from the AN, the= UA can in principle do everything with this location. = The intention of the "location hiding" is, as Barbara already pointed out, = to obscure the location, not to provide a false location. = Laura = -----Urspr=FCngliche Nachricht----- Von: James M. Polk [mailto:jmpolk@cisco.com] = Gesendet: Donnerstag, 29. Mai 2008 20:30 An: Liess, Laura; hannes.tschofenig@nsn.com; ecrit@ietf.org Betreff: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req At 09:30 AM 5/29/2008, Liess, Laura wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary=3D"----_=3D_NextPart_001_01C8C198.9BFCB0AB" > >Here is my personal hum and the hum of my company in favour of the = >"location hiding requirements" documenting effort. > >An additional comment: >James Polk also raised a very good point: users or end devices = >providing false location. But, as Brian pointed out, "a user or a = >device can always lie." In my opinion, if we choose the right = >solution(s), location hiding can improve this situation and minimize = >the risk that users lie about the location (and make the PSAPs life easier= ). >I don't want to discuss location hiding solutions, just try to an = >example where, in my opinion, the location information received by = >the PSAPs is more reliable with location hiding than without = >it. Example: if an end device finds out the ESRP (LOST query) based = >on a coarse location and sends in the INVITE to the ESRP instead of = >the precise location a location URI, the ESRP gets the precise = >location from the LIS based on the location URI. The ESRP then sends = >the precise location directly to the PSAP. Both the ESRP and the = >LIS are local and trusted by the local PSAP. Laura - you are assuming location is always provided by-reference, = and not by-value (as demonstrated in your example by the PSAP = retrieving more precise location from the LIS through another = transaction). What if the UA's location is GPS derived, or otherwise = given to the UA by-value? > >Laura > > > >---------- >Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im = >Auftrag von hannes.tschofenig@nsn.com >Gesendet: Dienstag, 13. Mai 2008 09:10 >An: ecrit@ietf.org >Betreff: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req > > >Hi all, > >Henning gave a presentation about this draft at previous IETF = >meetings. Although this is a controversal topic we believe it is = >important to capture the problem statement and the requirements. = >This document is NOT meant to capture solutions -- this is something = >for future work. We would therefore like to confirm the hum on the = >mailing list. If you have not stated your opinion or if you object = >please let us know. > >Deadline for your response: 30 May 2008 > >Ciao >Hannes & Marc >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri May 30 14:56:05 2008 Return-Path: X-Original-To: ecrit-archive@megatron.ietf.org Delivered-To: ietfarch-ecrit-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAF273A6904; Fri, 30 May 2008 14:56:05 -0700 (PDT) X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C936F3A6A5D for ; Fri, 30 May 2008 14:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 2eyKtbUraHo3 for ; Fri, 30 May 2008 14:56:02 -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 37BEF3A6906 for ; Fri, 30 May 2008 14:55:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,568,1204531200"; d="scan'208";a="106277899" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 30 May 2008 14:55:38 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4ULtbS2005489; Fri, 30 May 2008 14:55:37 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m4ULtb1h007804; Fri, 30 May 2008 21:55:37 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.1830); Fri, 30 May 2008 14:55:37 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.71.234]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 14:55:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 May 2008 16:55:35 -0500 To: "Liess, Laura" From: "James M. Polk" In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B0429702D@S4DE8PSAAGM.mitte .t-com.de> References: <182C63BFBAF131428EA0C16F7FD2191B04296B48@S4DE8PSAAGM.mitte.t-com.de> <182C63BFBAF131428EA0C16F7FD2191B0429702D@S4DE8PSAAGM.mitte.t-com.de> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 30 May 2008 21:55:37.0243 (UTC) FILETIME=[E4B0A6B0:01C8C29F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3761; t=1212184537; x=1213048537; 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=20AW=3A=20[Ecrit]=20Hum=3A=0A=20=20draft- schulzrinne-ecrit-location-hiding-req |Sender:=20; bh=yyFdpLx0phSsXMoyUZ8rTYF8pHW+za7boDf4hczDDSo=; b=JzEEFe9CZ058a7h+G+/fQlt8ke/WNdABGPqRS64c70JExuWlaGbv9KPBmZ wqONssIcDam22jJMaNKDnkd8hNK7GTTP7Zwgyvex8wgBzHXOWum9W/GtnewH OJjJEp9IF+; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: hannes.tschofenig@nsn.com, ecrit@ietf.org Subject: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 03:01 PM 5/30/2008, Liess, Laura wrote: >James, > >The example was just one possible scenario, not the general case. fair point >If the UA has a location-by-value, GPS derived = >or received from the AN, the UA can in principle = >do everything with this location. > >The intention of the "location hiding" is, as = >Barbara already pointed out, to obscure the = >location, not to provide a false location. I just can't help with the baggage of (way) = earlier discussion in which false location was a = goal. I guess I'm over sensitive to that, as I = (strongly) don't agree enabling that = "feature". I have always understood a user can = lie, but in some scenarios we've defined, the = user isn't completely involved in attaining the = location that will be conveyed. forgive my sensitivity on this matter. >Laura > > > >-----Urspr=FCngliche Nachricht----- >Von: James M. Polk [mailto:jmpolk@cisco.com] >Gesendet: Donnerstag, 29. Mai 2008 20:30 >An: Liess, Laura; hannes.tschofenig@nsn.com; ecrit@ietf.org >Betreff: Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req > >At 09:30 AM 5/29/2008, Liess, Laura wrote: > >Content-class: urn:content-classes:message > >Content-Type: multipart/alternative; > > boundary=3D"----_=3D_NextPart_001_01C8C198.9BFCB0AB" > > > >Here is my personal hum and the hum of my company in favour of the > >"location hiding requirements" documenting effort. > > > >An additional comment: > >James Polk also raised a very good point: users or end devices > >providing false location. But, as Brian pointed out, "a user or a > >device can always lie." In my opinion, if we choose the right > >solution(s), location hiding can improve this situation and minimize > >the risk that users lie about the location (and make the PSAPs life easi= er). > >I don't want to discuss location hiding solutions, just try to an > >example where, in my opinion, the location information received by > >the PSAPs is more reliable with location hiding than without > >it. Example: if an end device finds out the ESRP (LOST query) based > >on a coarse location and sends in the INVITE to the ESRP instead of > >the precise location a location URI, the ESRP gets the precise > >location from the LIS based on the location URI. The ESRP then sends > >the precise location directly to the PSAP. Both the ESRP and the > >LIS are local and trusted by the local PSAP. > >Laura - you are assuming location is always provided by-reference, >and not by-value (as demonstrated in your example by the PSAP >retrieving more precise location from the LIS through another >transaction). What if the UA's location is GPS derived, or otherwise >given to the UA by-value? > > > > >Laura > > > > > > > >---------- > >Von: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] Im > >Auftrag von hannes.tschofenig@nsn.com > >Gesendet: Dienstag, 13. Mai 2008 09:10 > >An: ecrit@ietf.org > >Betreff: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req > > > > > >Hi all, > > > >Henning gave a presentation about this draft at previous IETF > >meetings. Although this is a controversal topic we believe it is > >important to capture the problem statement and the requirements. > >This document is NOT meant to capture solutions -- this is something > >for future work. We would therefore like to confirm the hum on the > >mailing list. If you have not stated your opinion or if you object > >please let us know. > > > >Deadline for your response: 30 May 2008 > > > >Ciao > >Hannes & Marc > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit