From nobody Thu Jul 3 13:40:37 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E361B2B9B for ; Thu, 3 Jul 2014 13:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdMmMK5bT32M for ; Thu, 3 Jul 2014 13:40:35 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAC51B2B91 for ; Thu, 3 Jul 2014 13:40:34 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id s63KeTKK025147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 3 Jul 2014 13:40:30 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.61]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.03.0181.006; Thu, 3 Jul 2014 13:40:29 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: IETF90 - ECRIT meeting agenda time Thread-Index: Ac+W/v4IYmey+ascRPG8jlx0j/edpQ== Date: Thu, 3 Jul 2014 20:40:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101A9763SEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/TORew8pw3vjZOxVnVVLJ32qoxM4 Subject: [Ecrit] IETF90 - ECRIT meeting agenda time X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 20:40:36 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101A9763SEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please let us know if you want to present your ECRIT related draft(s) at IE= TF90. Roger Marshall & Marc Linsner - ECRIT chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101A9763SEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please let us know if you want to present your ECRIT related draft(= s) at IETF90.

Roger Marshall & Marc Linsner – ECRIT chairs

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101A9763SEAEXMB2telecom_-- From nobody Thu Jul 3 22:06:56 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724751B2BE1 for ; Thu, 3 Jul 2014 22:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.228 X-Spam-Level: X-Spam-Status: No, score=-4.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkjOn_kIx0gU for ; Thu, 3 Jul 2014 22:06:49 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD6C1B2BDB for ; Thu, 3 Jul 2014 22:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1404450409; x=1435986409; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=pW6gcaRnK4rM4orR8dHUNttL5ZnsXLnNT/NHw+zwGwM=; b=NtHZHTEBp2gIIXxU1mfk2e7ZRrSqOYoHSpIlp9gnSDF5pO5fCPXN0sU+ Bo8/kydkrUH7mXgRUOnaz4tKkUabQb77lIHFF8BMAzEYbbxeM0cisTn7U xp4ATmZdB/7lCaqbbGKCX6LuBxoWsJRB3YX3vs7v5qBHfUkyEPsfRXXhm g=; X-IronPort-AV: E=McAfee;i="5600,1067,7488"; a="47845015" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 03 Jul 2014 22:06:28 -0700 X-IronPort-AV: E=Sophos;i="5.01,598,1400050800"; d="scan'208,217";a="706966308" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2014 22:06:27 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 3 Jul 2014 22:06:27 -0700 Message-ID: In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E1D8B92368@HE113667.emea1.cds.t-int ernal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01E1D8B92368@HE113667.emea1.cds.t-int ernal.com> X-Mailer: Eudora for Mac OS X Date: Thu, 3 Jul 2014 22:06:08 -0700 To: From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/nX51ryEWbPV4Z1YGF_grPpv0P3o Cc: ecrit@ietf.org Subject: Re: [Ecrit] review draft-gellens-ecrit-ecall-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 05:06:52 -0000 Re: [Ecrit] review draft-gellens-ecrit-ecall-03.txt
Hello Roland,

Many thanks for your detailed and helpful review of the eCall draft.  Please see in-line below.

At 3:39 PM +0200 4/29/14, <R.Jesske@telekom.de> wrote:

Dear all,
 
as discussed at the last IETF I have reviewed draft-gellens-ecrit-ecall-03.txt.
Here are my comments:
 
General:
1.      ETSI has finalized the Technical Report on eCall and proposes solutions. Question is if it would be worth to mention onr reference it. The report is under http://webapp.etsi.org/ewp/copy_file.asp?wki_id=3D39297  downloadable.

Thank you, I agree and have added a mention of it and reference to it.

 



2.      I will point in some parts of the detailed review to backwards compatibility issues. So we have now implemented a eCall solution for our GSM. So this is an invest done. And PSAP invests are seen as a long term invest. These will be used for a long time so a SIP/IMS/NGN solution is needed where we can built new PSAP understanding the NG-eCall but also have the possibility to route the call towards the =93old" PSAP getting the inband information type eCall. But also the case will appear where we have still the old style end device which have to be interworked towards the new PSAP style.

I completely agree that migration/co-existence (behavior during the transition period when the UE, network, and PSAP may each support or not support NG) is extremely important.  I think the issue is outside the current scope of the draft, which is limited to describing how eCall is handled in an NG environment.
 Question is how this will be done? My opinion is that each PSAP has to understand the in-band information.

It's quite reasonable that PSAPs which are upgraded to support in-band eCall will retain the capability as they are further upgraded to support NG.  It's possible that some future PSAPs will be established later which only support NG, and for these cases I believe the routing decisions can take this into account, or another possibility would be gateways to convert between NG and in-band.  There are further issues of course.  The ETSI TR 103 140 discusses these issues in clause 7.  I have added mention of this and a reference to the TR.

By the way, TR 103 140, recommends that NG IVS and NG PSAP be legacy capable.  A broadcast indicator of network and PSAP capabilities enables the UE to decide whether to use legacy or NG eCall (the operator only uses the indicator when it is able to route to an NG capable PSAP). Alternatively there can be a legacy/NG protocol conversion at the PSAP.


Detailed comments &= ; questions:
1.       Section 3 last paragraph:
...
An eCall
   flag in the call setup marks the call as an eCall, and further
   indicates if the call was automatically or manually triggered.
...
3GPP has more flags that only automatic and manual. (we have discussed this in Berlin)

Do you mean more flags that are specific to eCall, or are you referring to flags that are not specific to eCall?  I assume the latter (based on subsequent comments).

 
the proposal is to add an sentence like:
"Note that 3GPP TS22.101 allows to combine the automatic and manual triggered ecall with the type of emergency guard like police or fire force. This is also uses in some countries."
3GPP describes the requirements in TS 22.101 as follows
 
Possible values in signalling:
 
   o Police
 
   o Ambulance
 
   o =46ire Brigade
 
   o Marine Guard
 
   o Mountain Rescue
 
   o Manually Initiated eCall
 
   o Automatically Initiated eCall
 
   And the bind requirement:
 
   It shall be possible to tie any emergency call number to any single
   emergency call type or to any combination of emergency call types.

This is not a simple matter (there are a number of additional factors), and in fact, 3GPP TS 24.229 (Release 12) contains an Editor's Note:

Editor's Note: [EMC1, CR#4068]            How to fulfil the requirement in 3GPP TS 22.101 [1A] that it shall be possible to tie any emergency call number to any combination of emergency call types is FFS.

So at this point it is not clear that combining types of emergency calls with eCall is required, nor how best to do so if it is required.  If you have time, we can meet and talk about this in Toronto.


 2. Section 3.
Also it would be worth to mention that backward compatibility is an requirement since we have already millions of cars with GSM Chips which will be in future interworked with SIP/IMS networks.

Yes, I agree.  I have added text to the Introduction mentioning the issues but also that it is currently out of scope.

 
3.Section 4.
one requirement is the backwards compatibility. Since mobile networks will not have LTE coverage  all over and =93old" ecall solutions will be interwokked to IMS there is the need when to have a backwards compatible solution. (i.e. Inband communication must be traversed to PSAP understanding in band and/or the PSAP is able to understand in- and out-band information.

I think this requirement is out of scope of the document.
 
4.      Section 6. 1st Paragraph :
      =93In circuit-switched eCall, the IVS places a special form of a 112
   emergency call which carries the eCall flag (indicating that the call
   is an eCall and also if the call was manually or automatically
   triggered)... =93
As mentioned above there are more possible indications within the =93eCall =46lag"

The document is not trying to present a complete picture of circuit-switched emergency calls, but rather a high-level summary of eCall.

5. Section 6 2nd Paragraph: Perhaps mention a option to identify also inband information when available. Or note that inband information then should be routed towards an backwards compatible PSAP.

Migration issues are out of the current scope of the document.

 
6. Section 6. last Paragraph: =93...urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual" >From the discussion we had in the past (i.e http://tools.ietf.org/html/draft-jesske-ecrit-ecall-urn-extension-01 in Berlin) I had the understanding that also the extension of the  urn:service:sos.ecall.automatic is still to long. So that only  urn:service:sos.ecall would be more ort less acaptable. And we need an further extension to identity the additional information for routing.

Speaking generally, call handling is free to take action based on part of the Request-URI, but it is better that the full information be included so that it is up to the call handling entities how to proceed.

 
7. Section 7.  =93...   The routing rules for eCalls are likely to differ from those of other
   emergency calls because eCalls are special types of emergency calls
   (with implications for the types of response required) and need to be
   handled by specially designated PSAPs.
What is meant by =93with implications for the types of response required" I do have slide problems to understand. Is this the fact that there could be diffrent responses like a call back or SMS back?

What is meant here is that it is possible that different types of calls have a presumption of different types of responses; for example, an automatic eCall is more likely to require medical assistance and possible specialized assistance for motor vehicle accidents.  In contrast, a manual eCall, depending on the operational procedures of the agencies involved, might be presumed to require police (e.g., report an emergency road safety issue).  This is not about call back or SMS.

 
 
8.      Section 7.1 mentions a interworking new to old. Is there also the possibility to interwork old to new? Would there be also an Section 7.2, 7.3 for other networks which are not EENA based?

The text is only mentioning the possibility of such interworking in a broader context of ESInets.  It is possible to interwork between old and new by translating between in-band data and the data contained in the call signaling.  This is conceptually similar to interworking between TTY or other legacy text and real-time text.  Such interworking could be done with or without an ESInet.


 
9.      Section 9. Will the same mechanism used or is this one out of a several possibilities? Is this mechanism such as open that each PSAP-operator can define it's own set? Or is it more seen as set to be aligned within RFC's?

This is a situation where the broadest possible support and standardization is needed; if individual PSAPs define their own extensions, there is low likelihood of support by various automotive IVS.  What I think makes the most sense is for the framework to be established by RFC, with IANA registries for the specific actions, which can be populated by SDOs involved in eCall.


 
10.     Section 10. It would be worth if preconditions and the reliability of provisional responses will have a effect of the solution or if they are needed? This question reflects the issue that in many mobile IMS networks such mechanisms will be used.

I'm sorry, I'm not understanding; if you have time, we can meet and talk about this in Toronto.

11.     A IVS provided location could be also manipulated. Independent on the trustworthiness. I think this should be mentioned explicitly. Question is what can provide security on such location. Perhaps a hint would we nice to be mentioned or to mandate the draft trustwothy-location more as an requirement.

There is already a reference to the trustworthy-location draft in Section 11.


 
12.     Section 12. As commented above I would propose an additional URN parameter or an other SIP extension to point to the possible indications appearing within a eCall. Such a indication needs to be considered when routing towards the PSAP.

The draft should not propose such until after 3GPP has decided if such mechanisms are required and if so how they are to be supported.  If you have time, we can meet and talk about this in Toronto.


 
 
13.     Within 3GPP we have the additional indications as mentioned above
 
 
From my (operators) point of view the most important points needed to be discussed are backwards compatible solution and the format of the URN and additional indication for PSAP routeing purposes.
 
My recommendation is also that we can start the work and push it towards work item within ecrit.
 
Thank you and Best Regards

Roland
Mit freundlichen Gr=FC=DFen; With Best Regards
Roland Jesske
Deutsche Telekom Technik GmbH
=46ixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 58-13395 (Fax)
+49 171 8618-445 (Mobil)
http://www.telekom.com

Erleben, was verbindet.

Deutsche Telekom Technik GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Carsten M=FCller
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262
Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.
 
 
 

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


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I have the simplest tastes.  I am always satisfied with the best.
       --Oscar Wilde
From nobody Fri Jul 4 04:53:17 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3901B2865; Fri, 4 Jul 2014 04:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.515 X-Spam-Level: X-Spam-Status: No, score=0.515 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngSr7Di3TsWX; Fri, 4 Jul 2014 04:53:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7891B282B; Fri, 4 Jul 2014 04:53:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704115310.31714.56156.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 04:53:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/pwqcBwnqomM1PIAeomSs3MN9IrU Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-unauthenticated-access-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:53:11 -0000 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 : Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices Authors : Henning Schulzrinne Stephen McCann Gabor Bajko Hannes Tschofenig Dirk Kroeselberg Filename : draft-ietf-ecrit-unauthenticated-access-09.txt Pages : 24 Date : 2014-07-04 Abstract: This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-unauthenticated-access-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-unauthenticated-access-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 7 15:27:37 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E200E1B2979; Mon, 7 Jul 2014 15:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mCYZfpAfMi8; Mon, 7 Jul 2014 15:27:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B6B1B2980; Mon, 7 Jul 2014 15:27:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140707222724.7926.49421.idtracker@ietfa.amsl.com> Date: Mon, 07 Jul 2014 15:27:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/SotVFOT0cUUPHRt7NNQA9hIZVIw Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:27:30 -0000 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 : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-00.txt Pages : 17 Date : 2014-07-04 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles. eCall deployment is required by 2015 in European Union member states, and eCall (and eCall-compatible systems) are also being deployed in other regions. eCall provides an integrated voice path and a standardized set of vehicle, sensor (e.g., crash related), and location data. An eCall is recognized and handled as a specialized form of emergency call and is routed to a specialized eCall-capable Public Safety Answering Point (PSAP) capable of processing the vehicle data and trained in handling emergency calls from vehicles. Currently, eCall functions over circuit-switched cellular telephony; work on next-generation eCall (NG-eCall, sometimes called packet- switched eCall or PS-eCall) is now in process, and this document assists in that work by describing how to support eCall within the IP-based emergency services infrastructure. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the eCall vehicle data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-ecall-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 7 15:28:00 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797C31B2987; Mon, 7 Jul 2014 15:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrjkzRWFH7Bc; Mon, 7 Jul 2014 15:27:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DDF1A0AAD; Mon, 7 Jul 2014 15:27:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140707222745.7498.60005.idtracker@ietfa.amsl.com> Date: Mon, 07 Jul 2014 15:27:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/D0d2r8CBsUwR8QDlepu8pR1Q-VU Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:27:52 -0000 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 : Internet Protocol-based In-Vehicle Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-00.txt Pages : 22 Date : 2014-07-04 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash). Profiling and simplifications are possible due to the nature of the functionality that is provided in vehicles with the usage of Global Satellite Navigation System (GNSS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-car-crash-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 7 15:59:41 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B48F1B28A5 for ; Mon, 7 Jul 2014 15:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMNhsM2xt2lM for ; Mon, 7 Jul 2014 15:59:38 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E311B28C8 for ; Mon, 7 Jul 2014 15:59:37 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id s67MxS7m004000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 7 Jul 2014 15:59:28 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.61]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0181.006; Mon, 7 Jul 2014 15:59:28 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: WGLC announce - draft-ietf-ecrit-additional-data-22 Thread-Index: Ac+aNpN57tVzeABDQgqKbEClFXbaUA== Date: Mon, 7 Jul 2014 22:59:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101B1665SEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/LJdPdeoKxHkydonDPuNeoW7YkZk Subject: [Ecrit] WGLC announce - draft-ietf-ecrit-additional-data-22 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:59:40 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101B1665SEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This starts WGLC for draft-ietf-ecrit-additional-data-22, Additional Data r= elated to an Emergency Call. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Please review the draft and provide comments to the list before our ECRIT m= eeting in Toronto, in a little over 2 weeks from today. Thanks, Marc & Roger CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101B1665SEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This starts WGLC for draft-ietf-ecrit-a= dditional-data-22, Additional Data related to an Emergency Call.

The draft can be found at:
http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

Please review the draft and provide comments to the list before our ECRIT m= eeting in Toronto, in a little over 2 weeks from today.

Thanks,


Marc & Roger

 

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101B1665SEAEXMB2telecom_-- From nobody Fri Jul 18 07:23:05 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956741A045B; Fri, 18 Jul 2014 07:22:46 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c44ftbHluFk2; Fri, 18 Jul 2014 07:22:44 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4491B29A0; Fri, 18 Jul 2014 07:22:42 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so7321137vcb.8 for ; Fri, 18 Jul 2014 07:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8/wH1YRl7Dory7te2FUTIryfwib3Re2gkn+X8JmHKbk=; b=j7KlUMQrDsC6n8+wnS/xLuxUJyEDs72TV196wpFVMEqBob/qrhHkoH5NyLxX/IQEoX zZt6xkCv+IyWAfQ4lGps+Wd4nzDpaHiMuxzXso7HDhvcHScFs3rkxkiP5761zLtK7SBI tQK2rARe5Qxax9zFAQL9xu8BhPRvMPlsYgJ8XRopU+aa9TPHfQzms4pUYttKYX/HoQKP Zu74nRtZsdem8glpIj4QDripDrPqOS3hJZLInqxbfeMjbJxE0atD86hB2X4oBzYpPALT mi1WlAv+egWA+eYPC6KxlrvvuL9TFXA2ZAcex0LkZWmHQrQtbpXS3RrNPyDxikrF9HZI V4qg== MIME-Version: 1.0 X-Received: by 10.221.42.135 with SMTP id ty7mr6469424vcb.14.1405693360114; Fri, 18 Jul 2014 07:22:40 -0700 (PDT) Received: by 10.58.170.8 with HTTP; Fri, 18 Jul 2014 07:22:40 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E289C9@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17E289C9@MCHP04MSX.global-ad.net> Date: Fri, 18 Jul 2014 09:22:40 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a1133997464922504fe787d7a Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/vD-w-rS_0ZCN4jiLNnv8duiu9WI Cc: SIPCORE , "ecrit@ietf.org Org" Subject: [Ecrit] Fwd: [SIPForum-techwg] SIPconnect2.0 Kickoff and IETF90 Next Week. X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 14:22:47 -0000 --001a1133997464922504fe787d7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =10This activity might be of interest to folks in the RAI area. A number o= f you all participated in SIP Connect 1.1 which resulted in new work coming into IETF. I'm cc'ing WGs for which I believe this is of particular interest, noting in particular that emergency services will be addressed. So, if you have comments on this email, please restrict those to a single, relevant mailing list or please contact Andrew directly. Note, that SIP Forum has no membership requirement in order to participate in activities - there is an individual "free" participant membership you can register for. Regards, Mary. ---------- Forwarded message ---------- From: Hutton, Andrew Date: Thu, Jul 17, 2014 at 3:42 PM Subject: [SIPForum-techwg] SIPconnect2.0 Kickoff and IETF90 Next Week. To: "techwg@sipforum.org" Hi All, Those of you that were at SIPNOC 2014 will know that the SIP Forum is about to start a SIPconnect2.0 activity. If you were not at SIPNOC then the presentation from this event can be found at: *http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,= 700/Itemid,261/* . If you are the IETF meeting next week in Toronto then there is a chance to get in touch and discuss this and maybe you want to volunteer to provide some assistance to this activity. Regards Andy _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --001a1133997464922504fe787d7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=10This activity might be of interest to folks in the RAI = area. =C2=A0A number of you all participated in SIP Connect 1.1 which resul= ted in new work coming into IETF. =C2=A0I'm cc'ing WGs for which I = believe this is of particular interest, noting in particular that emergency= services will be addressed. =C2=A0So, if you have comments on this email, = please restrict those to a single, relevant mailing list or please contact = Andrew directly.

Note, that SIP Forum has no membership requirement in order = to participate in activities -=C2=A0there is an individual "free"= participant membership you can register for.=C2=A0

Regards,
Mary.=C2=A0

---= ------- Forwarded message ----------
From: Hutton, Andrew <andrew.hutton@unify.com>
Date: Thu, Jul 17, 2014 at 3:42 PM
Subject: [SIPForum-techwg] SIPconnect= 2.0 Kickoff and IETF90 Next Week.
To: "techwg@sipforum.org" <techwg@sipforum.org>


Hi All,
=C2=A0
Those of you that were at SIPNOC 2014 will know that the SIP Forum is = about to start a SIPconnect2.0 activity.
=C2=A0
If you were not at SIPNOC then the presentation from this event can be= found at: http://www.sipforum.org/component/option,com_docman/task,doc_download/= gid,700/Itemid,261/.
=C2=A0
If you are the IETF meeting next week in Toronto then there is a chanc= e to get in touch and discuss this and maybe you want to volunteer to provi= de some assistance to this activity.
=C2=A0
Regards
Andy
=C2=A0
=C2=A0

_______________________________________________
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at: =C2=A0http://sipforum.org/mailman/listinfo/t= echwg


--001a1133997464922504fe787d7a-- From nobody Fri Jul 18 12:34:01 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F113B1B2A33 for ; Fri, 18 Jul 2014 12:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fck_qEpKo1d for ; Fri, 18 Jul 2014 12:33:55 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.120]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D791A000F for ; Fri, 18 Jul 2014 12:33:55 -0700 (PDT) Received: from [194.106.220.35:41254] by server-16.bemta-14.messagelabs.com id A9/58-14741-1A679C35; Fri, 18 Jul 2014 19:33:53 +0000 X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-3.tower-91.messagelabs.com!1405711998!23460997!56 X-Originating-IP: [206.47.0.173] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23410 invoked from network); 18 Jul 2014 19:33:52 -0000 Received: from tls.exchange.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.173) by server-3.tower-91.messagelabs.com with RC4-SHA encrypted SMTP; 18 Jul 2014 19:33:52 -0000 Received: from hub01-wyn.bell.corp.bce.ca (142.182.199.48) by dm1c8f.exchange1.bell.ca (198.235.102.112) with Microsoft SMTP Server id 8.3.298.1; Fri, 18 Jul 2014 15:33:47 -0400 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub01-wyn.bell.corp.bce.ca ([142.182.199.48]) with mapi; Fri, 18 Jul 2014 15:33:49 -0400 From: "Caron, Guy (A162859)" To: Roger Marshall , "ecrit@ietf.org" Date: Fri, 18 Jul 2014 15:33:48 -0400 Thread-Topic: WGLC announce - draft-ietf-ecrit-additional-data-22 Thread-Index: Ac+aNpN57tVzeABDQgqKbEClFXbaUAHq6bdA Message-ID: <0FEAC1C09868B34A982F4FB40254B37C2957905D94@MBX02.bell.corp.bce.ca> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_0FEAC1C09868B34A982F4FB40254B37C2957905D94MBX02bellcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/bI3dHEIY-GaYHdIZY3cRweVWhKY Subject: Re: [Ecrit] WGLC announce - draft-ietf-ecrit-additional-data-22 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 19:33:58 -0000 --_000_0FEAC1C09868B34A982F4FB40254B37C2957905D94MBX02bellcorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello ECRIT, I've reviewed version -22 of the draft and will shortly post my comments to= the list under separate bucket emails. One will include comments that may = require technical changes to address. The other will contain less substanti= ve clarification/terminology related comments. I've also provided trivial = inconsistencies and editorial changes to the authors directly. Regards, Guy De : Ecrit [mailto:ecrit-bounces@ietf.org] De la part de Roger Marshall Envoy=E9 : 7 juillet 2014 18:59 =C0 : ecrit@ietf.org Objet : [Ecrit] WGLC announce - draft-ietf-ecrit-additional-data-22 This starts WGLC for draft-ietf-ecrit-additional-data-22, Additional Data r= elated to an Emergency Call. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Please review the draft and provide comments to the list before our ECRIT m= eeting in Toronto, in a little over 2 weeks from today. Thanks, Marc & Roger CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_0FEAC1C09868B34A982F4FB40254B37C2957905D94MBX02bellcorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello ECRIT,

 

I’ve reviewed version -22 of= the draft and will shortly post my comments to the list under separate bucket e= mails. One will include comments that may require technical changes to address. Th= e other will contain less substantive clarification/terminology related comme= nts. =A0I’ve also provided trivial inconsistencies and editorial changes t= o the authors directly.

 

Regards,<= /p>

 

Guy

 

De := Ecrit [mailto:ecrit-bounces@ietf.org] D= e la part de Roger Marshall
Envoy=E9 : 7 juillet 20= 14 18:59
=C0 : ecrit@ietf.org Objet : [Ecrit] WGLC an= nounce - draft-ietf-ecrit-additional-data-22

 

This starts WGLC for draft-ietf-ecrit-additional-data-22, Additional Data related to an Emergenc= y Call.

The draft can be found at:
http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
Please review the draft and provide comments to the list before our ECRIT meeting in Toronto, in a little over 2 weeks from today.

Thanks,


Marc & Roger

 

 

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 o= f 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.=

--_000_0FEAC1C09868B34A982F4FB40254B37C2957905D94MBX02bellcorp_-- From nobody Fri Jul 18 12:38:55 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2F81B2A72 for ; Fri, 18 Jul 2014 12:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYQOR_hZGVeD for ; Fri, 18 Jul 2014 12:38:51 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.168]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A921B2A70 for ; Fri, 18 Jul 2014 12:38:51 -0700 (PDT) Received: from [85.158.137.35:10949] by server-8.bemta-3.messagelabs.com id 63/30-31195-AC779C35; Fri, 18 Jul 2014 19:38:50 +0000 X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-10.tower-134.messagelabs.com!1405712308!40985142!35 X-Originating-IP: [206.47.0.177] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14061 invoked from network); 18 Jul 2014 19:38:49 -0000 Received: from tls.exchange.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.177) by server-10.tower-134.messagelabs.com with RC4-SHA encrypted SMTP; 18 Jul 2014 19:38:49 -0000 Received: from hub03-wyn.bell.corp.bce.ca (142.182.199.49) by dm1c8e.exchange3.bell.ca (198.235.102.108) with Microsoft SMTP Server id 8.3.298.1; Fri, 18 Jul 2014 15:38:37 -0400 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub03-wyn.bell.corp.bce.ca ([142.182.199.49]) with mapi; Fri, 18 Jul 2014 15:38:44 -0400 From: "Caron, Guy (A162859)" To: "ecrit@ietf.org" Date: Fri, 18 Jul 2014 15:38:44 -0400 Thread-Topic: Add'l-Data-22: GCaron substantive comments Thread-Index: Ac+iv+KNKP+h8wxPQ1KMMA7yg1jJMA== Message-ID: <0FEAC1C09868B34A982F4FB40254B37C2957905D9E@MBX02.bell.corp.bce.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/r41UKfjBSOhz1OJiWkScDPejbWI Subject: [Ecrit] Add'l-Data-22: GCaron substantive comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 19:38:54 -0000 Hi ECRIT, This email contains comments that may require technical changes to the docu= ment to address. Thanks for considering these. Guy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 3.1.4. Type of Data Provider COMMENT 1: It is not clear to me why the type of data provider is strictly = associated with Data Provider ID and not extended to Data Provider String w= hich is the mandatory element of this structure. I note that the XML schema= does not enforce this, only the text seems to provide that limitation. It = seems to me that allowing the type of provider to be associated with the da= ta provider string would provide the same benefits, but to a larger communi= ty of providers. Since is mandatory, I suggest making = mandatory as well.=20 SUGGESTED CHANGE FOR COMMENT 1: Current text: Use: Conditional. If Data Provider ID is provided, Type of Data Provider = ID is required. Proposed text: Use: Required. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 3.1.5. Data Provider Contact URI COMMENT 2: The guidance provided in relation to URI formats is confusing. F= irst, it is not clear in the text that a generic SIP URI is supported or ap= propriate (the XML schema allows it). COMMENT 3: In relation to telephone numbers, perhaps it should be explicitl= y stated that E.164 format is REQUIRED/RECOMMENDED/PREFERRED to ensure glob= al numbers are provided? SUGGESTED CHANGE FOR COMMENTS 2 & 3: Current text: If a telephone number is the contact address then it MUST be = a tel URI. Proposed text: Generic SIP URIs are supported however, if a telephone numbe= r is the contact address then it MUST be a tel URI in E.164 format. COMMENT 4: The guidance with respect to supporting telephone numbers is unc= lear. Sentence "If it is provided as a SIP URI then it MUST be in the form = of sip:telephonenumber@serviceprovider:user=3Dphone." seems to conflict wit= h "If a telephone number is the contact address then it MUST be a tel URI."= previously stated. SUGGESTED CHANGE FOR COMMENT 4: Drop the sentence about sip:telephonenumber= @serviceprovider:user=3Dphone. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 3.2.2. Service Type, Figure 3 COMMENT 5: MLTS that are hosted, like Centrex service, bear specific regula= tory requirements in some jurisdictions in support of emergency calling. Kn= owing it is such a service can be very useful to the PSAPs. A distinct valu= e would be warranted in my view. SUGGESTED CHANGE FOR COMMENT 5: Add a new token to the registry (e.g., "Hos= ted") which combined with "MLTS" would cover the case. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 3.2.3. Service Mobility Environment COMMENT 6: The description states that a registry reflects the initial entr= ies however I haven't found a corresponding registry in section 9. Has the = registry been created by another RFC? If so, a reference to that RFC should= be provided. Otherwise, there should be an entry for this registry in sect= ion 9. SUGGESTED CHANGE FOR COMMENT 6: Either add the reference to the RFC that cr= eated the registry or add a section to section 9 if the registry is created= by this document. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 3.3.1. Device Classification, Figure 5 COMMENT 7: The list currently contains both physical and application type "= devices". However, I don't see a token to capture softclients as part of th= e list. I believe it should be added. Device Classification can be reported= by the device/application itself or a service provider. For some type of s= ervice providers, being a softclient might be the only thing they know abou= t the device as they may not have visibility to the type of hardware the so= ftclient is riding on. If the device does not participate in providing addi= tional data then no useful information would be provided to the PSAP in tha= t case. I note that the token "SoftPhn" was introduced in -12 but dropped s= omehow in -21. My preference would be "SoftClnt" as it implies more than ju= st voice. SUGGESTED CHANGE FOR COMMENT 7: Add "SoftClnt" to the Device Classification= registry. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 3.4. Owner/Subscriber Information COMMENT 8: This block can describe subscriber information (when provided by= a service provider) however it seems not possible to indicate the context = under which the information was originally captured. For example, the infor= mation provided by the service provider may be derived from a billing syste= m (e.g., billing address), a subscriber profile system (e.g., registered us= er information), from a user-inputting system (e.g., alternate/emergency co= ntacts) or a mix thereof. The nature of the information can provide useful = hints on how to treat the information which might change the way it will be= processed by the call taker. SUGGESTED CHANGE FOR COMMENT 8: A few options are available depending on th= e level of granularity we want to achieve. One option would be to add a new= element in the ProviderInfo allowing the characterization of all the info = being provided by the service provider. The downside of this is that it doe= s not support the characterization of multiple sources. Another option woul= d be to add a new element to xCard with an associated text enumeration to b= e used in the xCard for Subscriber data. This option would allow segmentati= on by source but would require that a distinct xCard be provided for each s= ource. A third option would be to add a new parameter to the xCard that wou= ld allow to characterize each field within the same xCard structure. There = might be others but that's what comes to mind right now. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 5. Examples, Figure 11 COMMENT 9: As currently drawn, the diagram seems to suggest that the origin= ating UA is owned and operated by the access network provider. SUGGESTED CHANGE FOR COMMENT 9: Move the human and the UA to the left, outs= ide the ASP box, and keep the signalling line flow through the ASP box to s= how that the ASP is not participating in the call setup. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Section 6.2. EmergencyCallData.ServiceInfo XML Schema COMMENT 10: The XML optional element "Link" is defined in the schema but th= ere is no describing text in section 3.2 nor is the element present in the = example of section 3.2.4. SUGGESTED CHANGE FOR COMMENT 10: Either remove the element from the schema = or add descriptive text to section 3.2 and update the affected examples in = the document. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D END OF COMMENTS From nobody Fri Jul 18 12:39:56 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7722A1B2A7F for ; Fri, 18 Jul 2014 12:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1DdVxbEIFSq for ; Fri, 18 Jul 2014 12:39:38 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.166]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF371B2A70 for ; Fri, 18 Jul 2014 12:39:37 -0700 (PDT) Received: from [85.158.137.35:18493] by server-6.bemta-3.messagelabs.com id 90/A8-29521-8F779C35; Fri, 18 Jul 2014 19:39:36 +0000 X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-5.tower-134.messagelabs.com!1405712368!34966680!14 X-Originating-IP: [206.47.0.168] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14135 invoked from network); 18 Jul 2014 19:39:36 -0000 Received: from tls.exchange.bell.ca (HELO TLS.Exchange.bell.ca) (206.47.0.168) by server-5.tower-134.messagelabs.com with RC4-SHA encrypted SMTP; 18 Jul 2014 19:39:36 -0000 Received: from hub03-wyn.bell.corp.bce.ca (142.182.199.49) by dm1c8g.exchange1.bell.ca (198.235.102.109) with Microsoft SMTP Server id 8.3.298.1; Fri, 18 Jul 2014 15:39:27 -0400 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub03-wyn.bell.corp.bce.ca ([142.182.199.49]) with mapi; Fri, 18 Jul 2014 15:39:28 -0400 From: "Caron, Guy (A162859)" To: "ecrit@ietf.org" Date: Fri, 18 Jul 2014 15:39:28 -0400 Thread-Topic: Add'l-Data-22: GCaron clarification/terminology comments Thread-Index: Ac+iv/zG4qrg9G1hRNOn4JEbpm3Hkw== Message-ID: <0FEAC1C09868B34A982F4FB40254B37C2957905D9F@MBX02.bell.corp.bce.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/-c4rhX8Qe7kEePibDdZv-PjPNCg Subject: [Ecrit] Add'l-Data-22: GCaron clarification/terminology comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 19:39:43 -0000 Hi ECRIT, This email contains less substantive, hopefully non-controversial, clarific= ation comments. Thanks for considering these. Guy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TERMINOLOGY-RELATED COMMENT 11: There are various permutations of the term "emergency services = authority(ies)" in the document (Emergency Authority, Emergency Services Au= thority, Emergency Service Authority). Consider using the same terminology = consistently. COMMENT 12: The term "emergency service provider" is used in a few places i= n the document. I'm not sure what this term refers to, PSAPs/Responders, sy= stem service providers, something else? Clarification would be helpful. COMMENT 13: The terms "access network provider" and "access network operato= r" are used however the subtlety between the two usage is not totally clear= to the reader. If they are used interchangeably, consider using only one o= f them in the document. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CLARIFICATIONS COMMENT 14: In the 1st paragraph of Section 1. Introduction (page 4), the t= ext states that the emergency service number is conveyed to PSAPs. Not sure= this is always the case. If the sos service URN is used, the dialled strin= g is not conveyed to the PSAP, unless I'm mistaken. COMMENT 15: In the sub-paragraph about Data about the Caller of Section 1. = Introduction (page 5), it is noted that emergency contact data is provided.= While it could be expected to be provided in the Additional Data about the= Caller, the vCard/xCard schema has the capability (admittedly limited but= still a capability) to support emergency contacts under Additional Data ab= out the Call. Should guidance be provided in this document about this? COMMENT 16: In Section 3.1.2. Data Provider ID, under Use (page 8), note th= at NENA Company IDs are not necessarily used outside of the U.S.. Consider = replacing "North America" for "the U.S.". =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D END OF COMMENTS From nobody Tue Jul 22 21:38:26 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B811B2788; Tue, 22 Jul 2014 21:38:23 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHt9I1QX5hSw; Tue, 22 Jul 2014 21:38:21 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3CE1A0302; Tue, 22 Jul 2014 21:38:20 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id q107so783194qgd.0 for ; Tue, 22 Jul 2014 21:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=RJgueyKYKpaGjgpJGmchkuKydbE0v2Hx+LAMOs5Dqgs=; b=WU5SU2a6YFVb9r8nEmvrKOSfXuyB2TVYsRhulfOkD54EySAq8vi6r4/ZDALkPaTmJk G83uuwhJZlMGOPao+ongUO4xqpHfHDQxw/GImpiuZz4mqdrgCji0AOq6K+oy/5wFhTBT fx6eF2K/T0tvel5EUXH5BRewmcqFASQtBHI+E91848yBppF3ja/gszg7l4tDf/95N8Nq am1CkeBeFPSc8ZWA7HyQATBWAfev2KPqj4fLbbicY5RppjFRPurZdi6aYu1G31J2AQR8 y+nPMoZ67y8t8ghPRagzSIj5ZCQgX6qzegFwyEphAcTQsmNtR3+oMdewi8imdr6CRcfQ t7Vg== X-Received: by 10.224.131.71 with SMTP id w7mr50176027qas.91.1406090300167; Tue, 22 Jul 2014 21:38:20 -0700 (PDT) Received: from [172.16.52.44] ([206.47.221.210]) by mx.google.com with ESMTPSA id g4sm2109791qay.6.2014.07.22.21.38.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Jul 2014 21:38:19 -0700 (PDT) Message-ID: <53CF3C38.2070706@gmail.com> Date: Wed, 23 Jul 2014 00:38:16 -0400 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: DISPATCH References: <9F33F40F6F2CD847824537F3C4E37DDF17E289C9@MCHP04MSX.global-ad.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040901020602010107010209" Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/VjCBVZgbjQpd2S1oLCJMK8zcNGE Cc: SIPCORE , "ecrit@ietf.org Org" Subject: Re: [Ecrit] [dispatch] Fwd: [SIPForum-techwg] SIPconnect2.0 Kickoff and IETF90 Next Week. X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 04:38:23 -0000 This is a multi-part message in MIME format. --------------040901020602010107010209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/18/2014 10:22 AM, Mary Barnes wrote: > This activity might be of interest to folks in the RAI area. A > number of you all participated in SIP Connect 1.1 which resulted in > new work coming into IETF. I'm cc'ing WGs for which I believe this is > of particular interest, noting in particular that emergency services > will be addressed. So, if you have comments on this email, please > restrict those to a single, relevant mailing list or please contact > Andrew directly. I'm just following up on Mary's note - we're beginning the process of scheduling a kickoff call for SIPconnect 2.0, and the details about that process are at http://sipforum.org/pipermail/techwg/2014-July/004510.html. The SIP Forum proposed charter for this work is at ttp://www.sipforum.org/content/view/179/213/ This will be my last note on these mailing lists announcing SIPconnect 2.0. If you have questions or comments, please contact me or Andy Hutton. Best wishes to you all. Spencer Dawkins, wearing his SIP Forum Technical Director bandana > > Note, that SIP Forum has no membership requirement in order to > participate in activities - there is an individual "free" participant > membership you can register for. > > Regards, > Mary. > > ---------- Forwarded message ---------- > From: *Hutton, Andrew* > > Date: Thu, Jul 17, 2014 at 3:42 PM > Subject: [SIPForum-techwg] SIPconnect2.0 Kickoff and IETF90 Next Week. > To: "techwg@sipforum.org " > > > > > Hi All, > Those of you that were at SIPNOC 2014 will know that the SIP Forum is > about to start a SIPconnect2.0 activity. > If you were not at SIPNOC then the presentation from this event can be > found at: > _http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,700/Itemid,261/_. > If you are the IETF meeting next week in Toronto then there is a > chance to get in touch and discuss this and maybe you want to > volunteer to provide some assistance to this activity. > Regards > Andy > > _______________________________________________ > techwg mailing list > Send mail to: techwg@sipforum.org > Unsubscribe or edit options at: > http://sipforum.org/mailman/listinfo/techwg > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------040901020602010107010209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/18/2014 10:22 AM, Mary Barnes wrote:
This activity might be of interest to folks in the RAI area.  A number of you all participated in SIP Connect 1.1 which resulted in new work coming into IETF.  I'm cc'ing WGs for which I believe this is of particular interest, noting in particular that emergency services will be addressed.  So, if you have comments on this email, please restrict those to a single, relevant mailing list or please contact Andrew directly.

I'm just following up on Mary's note - we're beginning the process of scheduling a kickoff call for SIPconnect 2.0, and the details about that process are at http://sipforum.org/pipermail/techwg/2014-July/004510.html.

The SIP Forum proposed charter for this work is at ttp://www.sipforum.org/content/view/179/213/

This will be my last note on these mailing lists announcing SIPconnect 2.0. If you have questions or comments, please contact me or Andy Hutton.

Best wishes to you all.

Spencer Dawkins, wearing his SIP Forum Technical Director bandana


Note, that SIP Forum has no membership requirement in order to participate in activities - there is an individual "free" participant membership you can register for. 

Regards,
Mary. 

---------- Forwarded message ----------
From: Hutton, Andrew <andrew.hutton@unify.com>
Date: Thu, Jul 17, 2014 at 3:42 PM
Subject: [SIPForum-techwg] SIPconnect2.0 Kickoff and IETF90 Next Week.
To: "techwg@sipforum.org" <techwg@sipforum.org>


Hi All,
 
Those of you that were at SIPNOC 2014 will know that the SIP Forum is about to start a SIPconnect2.0 activity.
 
If you were not at SIPNOC then the presentation from this event can be found at: http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,700/Itemid,261/.
 
If you are the IETF meeting next week in Toronto then there is a chance to get in touch and discuss this and maybe you want to volunteer to provide some assistance to this activity.
 
Regards
Andy
 
 

_______________________________________________
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at:  http://sipforum.org/mailman/listinfo/techwg




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

--------------040901020602010107010209-- From nobody Wed Jul 23 07:49:37 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674C51B287D for ; Wed, 23 Jul 2014 07:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F4AXOy2Zpys for ; Wed, 23 Jul 2014 07:49:33 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D941B27D1 for ; Wed, 23 Jul 2014 07:49:33 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id s6NEnOTU031313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 23 Jul 2014 07:49:25 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.252]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0195.001; Wed, 23 Jul 2014 07:49:24 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: New Version Notification for draft-marshall-ecrit-similar-location-04.txt Thread-Index: AQHPpn5nffFvAG1w0UiC/H0OyYjg3putujFA Date: Wed, 23 Jul 2014 14:49:24 +0000 Message-ID: References: <20140723135952.5654.36198.idtracker@ietfa.amsl.com> In-Reply-To: <20140723135952.5654.36198.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/p2SEqOlvox-BCxqav8ZjKSc2qlY Subject: [Ecrit] FW: New Version Notification for draft-marshall-ecrit-similar-location-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:49:35 -0000 QW4gdXBkYXRlZCB2ZXJzaW9uLCBkcmFmdC1tYXJzaGFsbC1lY3JpdC1zaW1pbGFyLWxvY2F0aW9u LTA0LCByZWZsZWN0aW5nIHRoZSBjaGFuZ2VzIGJhc2VkIG9uIHRoZSBtdWNoIGFwcHJlY2lhdGVk IHJldmlld3MgYnkgU2NvdHQgQnJhZG5lciBhbmQgQmFyYmFyYSBTdGFyaywgaGFzIGJlZW4gcG9z dGVkIHRvIHRoZSBkYXRhdHJhY2tlciBwYWdlIGF0Og0KDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1tYXJzaGFsbC1lY3JpdC1zaW1pbGFyLWxvY2F0aW9uLw0KDQpJdCB3 b3VsZCBiZSBhcHByZWNpYXRlZCBpZiBmb2xrcyBjb3VsZCB0YWtlIGEgbG9vayBhdCB0aGUgZGlm ZiBpbiBwcmVwYXJhdGlvbiBmb3IgdG9tb3Jyb3cncyBlY3JpdCBtZWV0aW5nLg0KDQpodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tYXJzaGFsbC1lY3JpdC1zaW1pbGFyLWxv Y2F0aW9uLTA0DQoNCi1yb2dlci4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10gDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgNzowMCBBTQ0KVG86IEplZmYgTWFy dGluOyBKZWZmIE1hcnRpbjsgQnJpYW4gUm9zZW47IFJvZ2VyIE1hcnNoYWxsOyBSb2dlciBNYXJz aGFsbDsgQnJpYW4gUm9zZW4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtbWFyc2hhbGwtZWNyaXQtc2ltaWxhci1sb2NhdGlvbi0wNC50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWFyc2hhbGwtZWNyaXQtc2ltaWxhci1sb2NhdGlvbi0wNC50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUm9nZXIgTWFyc2hhbGwgYW5k IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWFyc2hhbGwt ZWNyaXQtc2ltaWxhci1sb2NhdGlvbg0KUmV2aXNpb246CTA0DQpUaXRsZToJCUEgTG9TVCBleHRl bnNpb24gdG8gcmV0dXJuIGNvbXBsZXRlIGFuZCBzaW1pbGFyIGxvY2F0aW9uIGluZm8NCkRvY3Vt ZW50IGRhdGU6CTIwMTQtMDctMjMNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdl czoJCTE2DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtbWFyc2hhbGwtZWNyaXQtc2ltaWxhci1sb2NhdGlvbi0wNC50eHQNClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYXJzaGFsbC1l Y3JpdC1zaW1pbGFyLWxvY2F0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LW1hcnNoYWxsLWVjcml0LXNpbWlsYXItbG9jYXRpb24tMDQNCkRpZmY6 ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tYXJzaGFs bC1lY3JpdC1zaW1pbGFyLWxvY2F0aW9uLTA0DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVu dCBpbnRyb2R1Y2VzIGEgbmV3IHdheSB0byBwcm92aWRlIHJldHVybmVkIGxvY2F0aW9uDQogICBp bmZvcm1hdGlvbiBpbiBMb1NUIHJlc3BvbnNlcyB0aGF0IGlzIGVpdGhlciBvZiBhIGNvbXBsZXRl ZCBvcg0KICAgc2ltaWxhciBmb3JtIHRvIHRoZSBvcmlnaW5hbCBpbnB1dCBjaXZpYyBsb2NhdGlv biwgYmFzZWQgb24gd2hldGhlcg0KICAgdmFsaWQgb3IgaW52YWxpZCBjaXZpYyBhZGRyZXNzIGVs ZW1lbnRzIGFyZSByZXR1cm5lZCB3aXRoaW4gdGhlDQogICBmaW5kU2VydmljZVJlc3BvbnNlIG1l c3NhZ2UuICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgZXh0ZW5zaW9uDQogICB0byB0aGUg ZmluZFNlcnZpY2VSZXNwb25zZSBtZXNzYWdlIHdpdGhpbiB0aGUgTG9TVCBwcm90b2NvbCBbUkZD NTIyMl0NCiAgIHRoYXQgZW5hYmxlcyB0aGUgTG9TVCBwcm90b2NvbCB0byByZXR1cm4gYSBjb21w bGV0ZWQgY2l2aWMgYWRkcmVzcw0KICAgZWxlbWVudCBzZXQgZm9yIGEgdmFsaWQgbG9jYXRpb24g cmVzcG9uc2UsIGFuZCBvbmUgb3IgbW9yZSBzdWdnZXN0ZWQNCiAgIHNldHMgb2Ygc2ltaWxhciBs b2NhdGlvbiBpbmZvcm1hdGlvbiBmb3IgaW52YWxpZCBMb1NUIHJlc3BvbnNlcy4NCiAgIFRoZXNl IHR3byB0eXBlcyBvZiBjaXZpYyBhZGRyZXNzZXMgYXJlIHJlZmVycmVkIHRvIGFzIGVpdGhlcg0K ICAgImNvbXBsZXRlIGxvY2F0aW9uIiBvciAic2ltaWxhciBsb2NhdGlvbiIsIGFuZCBhcmUgaW5j bHVkZWQgYXMNCiAgIGNvbXBpbGF0aW9uIG9mIGNhIHR5cGUgeG1sIGVsZW1lbnRzIHdpdGhpbiB0 aGUgZXhpc3RpbmcgTG9TVA0KICAgZmluZFNlcnZpY2VSZXNwb25zZSBtZXNzYWdlIHN0cnVjdHVy ZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpDT05GSURFTlRJQUxJVFkg Tk9USUNFOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUg cHJpdmlsZWdlZCBhbmQvb3IgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBvciByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGlzIG1lc3NhZ2Ug dG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IHJldmlldywgZm9yd2FyZGluZywgZGlzc2Vt aW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIG9y IGFueSBhdHRhY2htZW50KHMpIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5LCBhbmQgZGVsZXRlIGl0IGFuZCBhbGwgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNv bXB1dGVyIGFuZCBuZXR3b3JrLg0K From nobody Thu Jul 24 07:21:19 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862321A004E; Thu, 24 Jul 2014 07:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiVbVk7oV3SH; Thu, 24 Jul 2014 07:21:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CFE1A016C; Thu, 24 Jul 2014 07:21:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140724142109.6460.75113.idtracker@ietfa.amsl.com> Date: Thu, 24 Jul 2014 07:21:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/mq6I7-1AGhHCyVBJ1ph1OrzjlG8 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:21:16 -0000 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 : Data-Only Emergency Calls Authors : Brian Rosen Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-data-only-ea-08.txt Pages : 22 Date : 2014-07-24 Abstract: RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) can handle Internet multimedia emergency calls natively. The exchange of multimedia traffic typically involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is everything that is needed. Examples of such environments include a temperature sensors issuing alerts, or vehicles sending crash data. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common Alerting Protocol (CAP) and its transmission using the SIP MESSAGE transaction. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-data-only-ea-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 24 09:11:32 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7B01A03B1 for ; Thu, 24 Jul 2014 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDIYhQbZqHIZ for ; Thu, 24 Jul 2014 09:11:22 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3751A01E2 for ; Thu, 24 Jul 2014 09:11:18 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s6OGBGYD010222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Jul 2014 11:11:17 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6OGAuPH003395 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jul 2014 18:11:15 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 24 Jul 2014 18:11:03 +0200 From: "DRAGE, Keith (Keith)" To: ECRIT Thread-Topic: Car crash, ecall, etc Thread-Index: Ac+nWdxR01cozyUBRX2YlRxpYMDZvQ== Date: Thu, 24 Jul 2014 16:11:02 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B2101B4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/HVGBziTxiJubpHP9ffmxSYsUI08 Subject: [Ecrit] Car crash, ecall, etc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:11:29 -0000 I ready through the various drafts on this, and I have some general comment= s. 1) I think the reservation of new URNs to support this should be moved out = into a single separate draft, along with any associated session level requi= rements. That requires some harmonisation, as we have proposals in two sepa= rate drafts that are different. As it is envisaged that this would exist on cellular devices, I think such = a document needs to reference 3GPP TS 23.167 and 3GPP TS 24.229, and talk a= bout what is expected to occur when the vehicle call is activated in a cell= ular network either does not support emergency call, or does not support PS= mode emergency call, or there is only CS mode access. Further it needs to talk about whether SRVCC should be allowed on such call= s or not, and whether the data is expected to continue or not after SRVCC h= as occurred. 2) The test URN needs some study. It is not a sos URN so in cellular networ= ks it currently would not test the emergency bearer capabilities, or the lo= cal network capabilities for a roaming user. 3) In regard to the multiple data mechanisms, these are apparently regional= , i.e. North America versus Europe. Given that vehicles more and more move = between countries, there needs to be some discussion in each solution about= detecting the appropriate solution to use. Regards Keith= From nobody Thu Jul 24 13:25:03 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5193C1B286A for ; Thu, 24 Jul 2014 13:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHGJ2QHsffF2 for ; Thu, 24 Jul 2014 13:24:47 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F961B287F for ; Thu, 24 Jul 2014 13:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1406233486; x=1437769486; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=mpLBXnrUOC3u2LgYjc3dSPEcI6i06NHZdSBYvW5vMx8=; b=qw1GE/zAtksUa77y31ML49oZowO2Jxg4a3qjhkg/QhkEzcb7oAO4mpYq LVj+DQEu+UmweQx+hHWLW724BPMS8Y0UMqrFKmekHqTO8uhlIo1LqMvhR mEC6GJPe5KKkga8H1t4R9XgoIxNIoYNClf/IxNGKy9boFBMHx9UYzm78A 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7509"; a="71128793" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 24 Jul 2014 13:24:45 -0700 X-IronPort-AV: E=Sophos;i="5.01,726,1400050800"; d="scan'208";a="772698315" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Jul 2014 13:24:46 -0700 Received: from [192.168.6.56] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 24 Jul 2014 13:24:44 -0700 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B2101B4@FR712WXCHMBA11.zeu.alcatel-luc ent.com> References: <949EF20990823C4C85C18D59AA11AD8B2101B4@FR712WXCHMBA11.zeu.alcatel-luc ent.com> X-Mailer: Eudora for Mac OS X Date: Thu, 24 Jul 2014 13:24:42 -0700 To: "DRAGE, Keith (Keith)" , ECRIT From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/Vdl1wRsCnhGkY5Ok7eYMWA81W38 Subject: Re: [Ecrit] Car crash, ecall, etc X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:24:53 -0000 Hi Keith, Thanks very much for your reviews. The eCall draft does reference 3GPP and TS22.101 for eCall. I can add references to 23.167 and 24.229 to both for cellular packet switched emergency calling, although the documents try to avoid getting into cellular-specific details, leaving those to 3GPP and other organizations. Similarly, I think discussion of domain selection (e.g., CS or PS), SRVCC, and similar cellular-specific issues should be left to 3GPP. I can add text to this effect to the documents to make this more clear. The test URN pre-exists this draft, and I believe the current eCall test call facility is a non-emergency number so does not get treated as an emergency call. There is the possibility of operators treating a vehicle call in the test URN in a way that tests as much functionality as desired, but that would be best left to 3GPP or another cellular-specific body, I think. I could add some text to mention some of this if you think it would be helpful. I could add an informative mention of a vehicle being able to operate in more than one region and hence use either eCall or the more generic which uses VEDS. It's possible that additional regions will adopt one of these, but of course we don't know. Thanks again for your comments. At 4:11 PM +0000 7/24/14, Keith (Keith) DRAGE wrote: > I ready through the various drafts on this, and I have some general comments. > > 1) I think the reservation of new URNs to support this should be > moved out into a single separate draft, along with any associated > session level requirements. That requires some harmonisation, as we > have proposals in two separate drafts that are different. > > As it is envisaged that this would exist on cellular devices, I > think such a document needs to reference 3GPP TS 23.167 and 3GPP TS > 24.229, and talk about what is expected to occur when the vehicle > call is activated in a cellular network either does not support > emergency call, or does not support PS mode emergency call, or > there is only CS mode access. > > Further it needs to talk about whether SRVCC should be allowed on > such calls or not, and whether the data is expected to continue or > not after SRVCC has occurred. > > 2) The test URN needs some study. It is not a sos URN so in > cellular networks it currently would not test the emergency bearer > capabilities, or the local network capabilities for a roaming user. > > 3) In regard to the multiple data mechanisms, these are > apparently regional, i.e. North America versus Europe. Given that > vehicles more and more move between countries, there needs to be > some discussion in each solution about detecting the appropriate > solution to use. > > Regards > > Keith > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The chance of forgetting something is directly proportional to.....to........uh.............. From nobody Thu Jul 24 16:03:04 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242BB1A0311 for ; Thu, 24 Jul 2014 16:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jlVUd-ruNSU for ; Thu, 24 Jul 2014 16:02:56 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70011A02E8 for ; Thu, 24 Jul 2014 16:02:56 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so4454081pdj.8 for ; Thu, 24 Jul 2014 16:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=+TWdi7CaDthWxgdWuio7zttxkg+lo+5GJBRF/gJooWQ=; b=cnpQukDvGCUVf0rUS9S2nZ57m5yhVQ9ZzheeisyxuBL02wfwgK9yv8bYvetujVtUh9 8jFv3g8OcjD+u863cFl2mm8QJOU9Fbjr4kCaobkA9nScfXthGT41JCd3+KeQr7x3AXd8 44Kf88VDopdUzjgHtI38E9tSt0jQGtMugIbD/MGb+NG2VVV+JJ21gjk3s64QjXOOyZ1m U3ui+afvI0Ph1RLrS1/n0TG5v7a4iotNObp2YL0iHSogrR5KKLK5QjP5lk4DZ9+SvxMo g/TrfaDDp9h/FsU5trBTCNQ/jC1YhkvynzfI5faQl+HhL2zKwNxGD7PusNB2mtTQ5vE/ IUHA== X-Received: by 10.68.111.36 with SMTP id if4mr12741562pbb.86.1406242976470; Thu, 24 Jul 2014 16:02:56 -0700 (PDT) Received: from [192.168.1.100] ([120.158.59.117]) by mx.google.com with ESMTPSA id mn2sm6729158pbc.64.2014.07.24.16.02.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 16:02:55 -0700 (PDT) From: James Winterbottom Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> Date: Fri, 25 Jul 2014 09:02:50 +1000 To: "ecrit_ietf.org" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/6Pg9O929iLopEVmUHT9jjs9AwoA Subject: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 23:03:03 -0000 Hi All, This is a bit of rant, for which I am only partially apologetic because = Laura and I first presented the need for this draft more than years ago = when there was time for a debate. I think that that time has largely = passed now. I sent emails to the list at the end of May and the start of = June asking for feedback on this draft and again stated why it was = needed and got next to zero response back. http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html The specification that is dependent on a solution to this problem has a = milestone set for end of 1H15. There simply isn=92t time to have a 3 month mailing list debate on this = topic and then =93maybe=94 have something that can be adopted in the = nov/dec timeframe. If this topic can move =93very quickly=94 then I see some benefit in = continuing a discussion, otherwise I see little point as decisions to = address the need will be made elsewhere. Cheers James From nobody Thu Jul 24 17:29:13 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918801A0AAA for ; Thu, 24 Jul 2014 17:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dlo4i093-3Hy for ; Thu, 24 Jul 2014 17:28:56 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4761A03C8 for ; Thu, 24 Jul 2014 17:28:56 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id s6P0SkrI014722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 24 Jul 2014 17:28:46 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.252]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0195.001; Thu, 24 Jul 2014 17:28:46 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: Milestones update Thread-Index: Ac+nnZ6A0XiPNYMJRuOBF8+zmdW/jQ== Date: Fri, 25 Jul 2014 00:28:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101F9DB0SEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/nB1YRvwBrLll6EsH0g-zgOtjstA Subject: [Ecrit] Milestones update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 00:29:00 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101F9DB0SEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As discussed in today's ECRIT meeting, we're sending out the full text to a= n updated ECRIT Charter and Milestones list. This reflects target date updates and new draft additions based on wg conse= nsus at IETF89-London and at today's Toronto meeting. Please submit any objections you might have regarding these changes to the = ecrit list within five days. Roger & Marc *** Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- Charter Current Status: Active Chairs: Marc Linsner Roger Marshall Real-time Applications and Infrastructure Area Directors: Richard Barnes Alissa Cooper Real-time Applications and Infrastructure Area Advisor: Alissa Cooper Mailing Lists: General Discussion: ecrit@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ecrit Archive: http://www.ietf.org/mail-archive/web/ecrit/ Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group has described where and how these mechanisms may be used. The group specified how location data and call routing information are used to enable communication between a user and a relevant emergency response center [RFC6443,RFC6444]. Though the term "call routing" is used, it should be understood that some of the mechanisms described might be used to enable other types of media streams. Beyond human initiated emergency call request mechanisms, this group will develop new methods to enable non-human-initiated requests for emergency assistance, such as sensor initiated emergency requests. The working group will also address topics required for the operation of emergency calling systems, such as: authentication of location, management of the service URN namespace, augmented information that could assist emergency call takers or responders. Explicitly outside the scope of this group is the question of pre- emption or prioritization of emergency services traffic in the network. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA, EENA, 3GPP, and ETSI , any solution presented must be general enough to be potentially useful in or across multiple regions or jurisdictions, and it must be possible to use without requiring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, things such as call routing for specific emergency types, media types, language contents, etc., may be routed differently depending on established policies and availability. This working group will address privacy and security concerns within its documents. Goals and Milestones: Done - Informational RFC containing terminology definitions and the r= equirements Done - An Informational document describing the threats and security = considerations Done - A Standards Track RFC describing how to identify a session set= -up request is to an emergency response center Done - A Standards Track RFC describing how to route an emergency cal= l based on location information Done - An Informational document describing the Mapping Protocol Arch= itecture Done - Submit 'Location Hiding: Problem Statement and Requirements' t= o the IESG for consideration as an Informational RFC. Done - Submit 'Framework for Emergency Calling using Internet Multime= dia' to the IESG for consideration as an Informational RFC. Done - Submit 'Best Current Practice for Communications Services in s= upport of Emergency Calling' to the IESG for consideration as a BCP document Done - Submit 'LoST Extension for returning Boundary Information for = Services' to the IESG for consideration as an Experimental RFC Done - Submit 'Synchronizing Location-to-Service Translation (LoST) P= rotocol based Service Boundaries and Mapping Elements' to the IESG for cons= ideration as an Experimental RFC Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the= IESG for consideration as an Informational RFC Done - Submit 'Extensions to the Emergency Services Architecture for = dealing with Unauthenticated and Unauthorized Devices' to the IESG for cons= ideration as a Standards Track RFC Oct 2014 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergen= cy Alerts using the Session Initiation Protocol (SIP)' to the IESG for cons= ideration as an Experimental RFC Done - Submit 'Trustworthy Location Information' to the IESG for consider= ation as an Informational RFC Oct 2014 - Submit 'Additional Data related to a Call for Emergency Call P= urposes' to the IESG for consideration as a Standards Track RFC Oct 2014 - Submit 'Policy for defining new service-identifying labels' to= the IESG for consideration as BCP Done - Submit 'URN For Country Specific Emergency Services' to the IESG f= or consideration as a Standards Track RFC Mar 2015 - Submit 'Internet Protocol-based In-Vehicle Emergency Calls' to= the IESG for consideration as an Informational RFC Mar 2015 - Submit 'Next-Generation Pan-European eCall' to the IESG for co= nsideration as an Informational RFC Mar 2015 - Submit 'A LoST extension to return complete and similar locati= on info' to the IESG for consideration as an Informational RFC CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101F9DB0SEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As discussed in today's ECRIT meeting, we're sending= out the full text to an updated ECRIT Charter and Milestones list.

 

This reflects target date updates and new draft addi= tions based on wg consensus at IETF89-London and at today's Toronto meeting= .

 

Please submit any objections you might have regardin= g these changes to the ecrit list within five days.

 

Roger & Marc

 

***

 

 

Emergency Context Resolution with Internet Technolog= ies (ecrit)

----------------------------------------------------= -----------

 

Charter

 

Current Status: Active

 

Chairs:

     Marc Linsner <marc.linsn= er@cisco.com>

     Roger Marshall <rmarshal= l@telecomsys.com>

 

Real-time Applications and Infrastructure Area Direc= tors:

     Richard Barnes <rlb@ipv.= sx>

     Alissa Cooper <alissa@co= operw.in>

 

Real-time Applications and Infrastructure Area Advis= or:

     Alissa Cooper <alissa@co= operw.in>

 

Mailing Lists:

     General Discussion: ecrit@i= etf.org

     To Subscribe:  &n= bsp;    https://www.ietf.org/mailman/listinfo/ecrit

     Archive:   &= nbsp;        http://www.ietf.org/mail-ar= chive/web/ecrit/

 

Description of Working Group:

 

  In a number of areas, the public switched tel= ephone network (PSTN) has

  been configured to recognize an explicitly sp= ecified number (usually one

 that is short and easily memorized) as a reque= st for emergency services.

  These numbers (e.g., 911, 112) are related to= an emergency service

  context and depend on a broad, regional confi= guration of service contact

  methods and a geographically-constrained appr= oach for service delivery.

  These calls are intended to be delivered to s= pecial call centers

  equipped to manage emergency response. Succes= sful delivery of an

  emergency service call within those systems r= equires an association of

  both the physical location of the originating= device  along with

  appropriate call routing to an emergency serv= ice center.

 

  Calls placed using Internet technologies do n= ot use the same systems

  mentioned above to achieve those same goals, = and the common use of

  overlay networks and tunnels (either as VPNs = or for mobility) makes

  meeting these goals even more challenging.&nb= sp; There are, however, Internet

  technologies available to manage location and= to perform call routing.

 

  This working group has described where and ho= w these mechanisms may be

  used. The group specified how location data a= nd call routing information

  are  used to enable communication betwee= n a user and a relevant

  emergency response center [RFC6443,RFC6444]. = Though the term "call

  routing" is used, it should be understoo= d that some of the mechanisms

  described might be used to enable other types= of media streams.

 

  Beyond human initiated emergency call request= mechanisms, this group

  will develop new methods to enable non-human-= initiated requests for

  emergency assistance, such as sensor initiate= d emergency requests.

 

  The working group will also address topics re= quired for the operation of

  emergency calling systems, such as:  aut= hentication of location,

  management of the service URN namespace, augm= ented information that

  could assist emergency call takers or respond= ers.

 

  Explicitly outside the scope of this group is= the question of pre-

  emption or prioritization of emergency servic= es traffic in the network.

  This group is considering emergency services = calls which might be made

  by any user of the Internet, as opposed to go= vernment or military

  services that may impose very different authe= ntication and routing

  requirements.

 

  While this group anticipates a close working = relationship with groups

  such as NENA, EENA, 3GPP, and ETSI , any solu= tion presented must be

  general enough to be potentially useful in or= across multiple regions or

  jurisdictions, and it must be possible to use= without requiring a

  single, central authority.  Further, it = must be possible for multiple

  delegations within a jurisdiction to be handl= ed independently, things

  such as call routing for specific emergency t= ypes, media types,

  language contents, etc.,  may be routed = differently depending on

  established policies and availability.

 

  This working group will address privacy and s= ecurity concerns within its

  documents.

 

Goals and Milestones:

  Done     - Informational = RFC containing terminology definitions and the requirements

  Done     - An Information= al document describing the threats and security considerations

  Done     - A Standards Tr= ack RFC describing how to identify a session set-up request is to an emerge= ncy response center

  Done     - A Standards Tr= ack RFC describing how to route an emergency call based on location informa= tion

  Done     - An Information= al document describing the Mapping Protocol Architecture

  Done     - Submit 'Locati= on Hiding: Problem Statement and Requirements' to the IESG for consideratio= n as an Informational RFC.

  Done     - Submit 'Framew= ork for Emergency Calling using Internet Multimedia' to the IESG for consid= eration as an Informational RFC.

  Done     - Submit 'Best C= urrent Practice for Communications Services in support of Emergency Calling= ' to the IESG for consideration as a BCP document

  Done     - Submit 'LoST E= xtension for returning Boundary Information for Services' to the IESG for c= onsideration as an Experimental RFC

  Done     - Submit 'Synchr= onizing Location-to-Service Translation (LoST) Protocol based Service Bound= aries and Mapping Elements' to the IESG for consideration as an Experimenta= l RFC

  Done     - Submit 'Public= Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as = an Informational RFC

  Done     - Submit 'Extens= ions to the Emergency Services Architecture for dealing with Unauthenticate= d and Unauthorized Devices' to the IESG for consideration as a Standards Tr= ack RFC

  Oct 2014 - Submit 'Common Alerting Protocol (= CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol= (SIP)' to the IESG for consideration as an Experimental RFC

  Done - Submit 'Trustworthy Location Informati= on' to the IESG for consideration as an Informational RFC

  Oct 2014 - Submit 'Additional Data related to= a Call for Emergency Call Purposes' to the IESG for consideration as a Sta= ndards Track RFC

  Oct 2014 - Submit 'Policy for defining new se= rvice-identifying labels' to the IESG for consideration as BCP

  Done - Submit 'URN For Country Specific Emerg= ency Services' to the IESG for consideration as a Standards Track RFC<= /o:p>

  Mar 2015 – Submit ‘Internet Proto= col-based In-Vehicle Emergency Calls‘ to the IESG for consideration a= s an Informational RFC

  Mar 2015 – Submit ‘Next-Generatio= n Pan-European eCall‘ to the IESG for consideration as an Information= al RFC

  Mar 2015 – Submit ‘A LoST extensi= on to return complete and similar location info‘ to the IESG for cons= ideration as an Informational RFC

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC101F9DB0SEAEXMB2telecom_-- From nobody Fri Jul 25 18:34:57 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1C51B27AC for ; Fri, 25 Jul 2014 18:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wyf6olMAwCPL for ; Fri, 25 Jul 2014 18:34:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68A21B27A9 for ; Fri, 25 Jul 2014 18:34:51 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-bd-53d305b934b1 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E9.40.03739.9B503D35; Sat, 26 Jul 2014 03:34:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Sat, 26 Jul 2014 03:34:49 +0200 From: Christer Holmberg To: "ecrit@ietf.org" , "ecrit-chairs@tools.ietf.org" Thread-Topic: IETF#90: ECRIT raw notes Thread-Index: Ac+ocb+N7lYv9HruRLWCwUckcqWlXA== Date: Sat, 26 Jul 2014 01:34:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3D5571@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D3D5571ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje5O1svBBi1bdC36H1xntGhc9JTV gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mr4vfs/W8GTTsaKHdO3szQwXq3sYuTkkBAw kfjzYj0LhC0mceHeerYuRi4OIYGjjBJLO/pZIZxFjBIrtvwFynBwsAlYSHT/0wZpEBFIkdjy 8xBYs7CAosTEIzuYIeJqEmf2/YWy9ST6F10Eq2ERUJV4s/IvO4jNK+ArsWbDNDYQmxFo8fdT a5hAbGYBcYlbT+YzQRwkILFkz3lmCFtU4uXjf6wQtpJE45InrBD1+RJ3N05mhJgpKHFy5hOW CYxCs5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tbg4N93IWC+1 KDO5uDg/Ty8vtWQTIzBSDm75rbuDcfVrx0OMAhyMSjy8CrMvBQuxJpYVV+YeYpTmYFES5110 bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaez9wl1hul2J6+PfQlzO3zRcsvh5U6r9VP 2VP8vvd9edDTZqW/lhvXKR+yi3e88WnpbSnJ8OXZiVv1YhitniVeur9s4X575but1xgMBCr/ /n1+NVLeRoPdXa088fGPj04rSrQ2nMrL2xFc1XD71o1Nr6+vWfjl3tGge8p3fryTUeX9vCTs pcQuJZbijERDLeai4kQAHB6ZfnUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/-QIvp2NP1ZAUaFTiftQO3ESsgR4 Subject: [Ecrit] IETF#90: ECRIT raw notes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 01:34:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D3D5571ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below are my raw notes from the ECRIT session in Toronto. Regards, Christer ------------------ Topic: Additional data: Draft: draft-ietf-ecrit-additional-data-22 Presenter: Randall Gellens ISSUE: As IMSI has been added to device identifier types, associated privac= y issues need to be described in the security considerations. OUTCOME: Text regarding privacy issues associated with IMSI delivery will b= e added. ISSUE: Does device classification registry in section 3.3.1 need an entry f= or soft client on unknown device type? OUTCOME: Yes (Soft client running on a computer does not know on what type = of computer it is running) ISSUE: Service providers without NENA/EENA IDs. Do providers need to be ide= ntified and globally unique? OUTCOME: Service providers do need to be unique. ISSUE: Type Of Data Provider is unclear OUTCOME: Will be renamed TypeOfProvider ISSUE: Does a Data Provider Contact, given as a telephone number, have to b= e in E.164 format? OUTCOME: Data Provider Contact URI can be generic SIP URI and when telephon= e number, MUST be E.164. ISSUE: Suggestion to add a new element in Owner/Subscriber block to indicat= e source of data. OUTCOME: The suggested was not accepted. It was indicated that the document is not restricted to emergency calls. It was indicated that a UE may not be aware that it is making an emergency = call (but the network will detect the call as an emergency call), in which = case a UE will not provide additional data. It was determined that additional text is needed to cover the privacy issue= s associated with the additional data, and that the data should only be pro= vided for emergency calls. The chairs indicated that a new WGLC is not need= ed, but that the community needs to review such text. Topic: Data-Only Emergency Calls Draft: draft-ietf-ecrit-data-only-ea-08 Presenter: Brian Rosen The author requested WGLC for the draft. It was indicated that the terminol= ogy needs to be double checked, as "call" often implies the presence of con= versational media. Topic: A LoST extension to support return of complete and similar locat= ion info Draft: draft-marshall-ecrit-similar-location-03 Presenter: Roger Marshall ISSUE: There was a request to adopt the draft as a WG document. OUTCOME: There was WG consensus to adopt the draft. Topic: A Routing Extension for HELD Draft: draft-winterbottom-ecrit-priv-loc-04 Presenter: Laura Liess ISSUE: It was suggested to extend HELD, by adopting draft-winterbottom-ecri= t-priv-loc, in order to solve the problem presented. OUTCOME: Some people did not agree to the statements made, and the suggeste= d was to solve the problem. Additional discussions need to take place on th= e mailing list. Topic: Feedback for ACE Use Cases Draft: draft-seitz-ace-usecases-01 Presenter: Ludwig Seitz The ECRIT community was requested to provide feedback, and real-lire use-ca= ses. --_000_7594FB04B1934943A5C02806D1A2204B1D3D5571ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below are my raw notes from the ECRIT session in Tor= onto.

 

Regards,

 

Christer

 

------------------

 

Topic:     Additional data:=

Draft:     draft-ietf-ecrit-additional-data-22

Presenter: Randall Gellens

 

ISSUE:= As IMSI has been added to device identifier types, associated privacy issu= es need to be described in the security considerations.

OUTCOME: Text regarding privacy issues associated with IMSI delivery will be adde= d.

 

ISSUE:= Does device classification registry in section 3.3.1 need an entry for sof= t client on unknown device type?

OUTCOME: Yes (Soft client running on a computer does not know on what type of com= puter it is running)

 

ISSUE:= Service providers without NENA/EENA IDs. Do providers need to be identifie= d and globally unique?

OUTCOME: Service providers do need to be unique.

 

ISSUE:= Type Of Data Provider is unclear

OUTCOME: Will be renamed TypeOfProvider

 

ISSUE:= Does a Data Provider Contact, given as a telephone number, have to be in E= .164 format?

OUTCOME: Data Provider Contact URI can be generic SIP URI and when telephone numb= er, MUST be E.164.

 

ISSUE:= Suggestion to add a new element in Owner/Subscriber block to indicate sour= ce of data.

OUTCOME: The suggested was not accepted.

 

It was indicated that the document is not restricted to emergency calls.=

 

It was indicated that a UE may not be aware that it is making an emergen= cy call (but the network will detect the call as an emergency call), in whi= ch case a UE will not provide additional data.

 

It was determined that additional text is needed to cover the privacy is= sues associated with the additional data, and that the data should only be = provided for emergency calls. The chairs indicated that a new WGLC is not needed, but that the community needs to review such= text.

 

 

 

Topic:     Data-Only Emergency Calls

Draft:     draft-ietf-ecrit-data-only-ea-08<= /o:p>

Presenter: Brian Rosen

 

The author requested WGLC for the draft. It was indicated that the termi= nology needs to be double checked, as “call” often implies the = presence of conversational media.

 

 

 

Topic:     A LoST extension to support return of = complete and similar location info

Draft:     draft-marshall-ecrit-similar-location-= 03     

Presenter: Roger Marshall

 

ISSUE:= There was a request to adopt the draft as a WG document.=

OUTCOME: There was WG consensus to adopt the draft.

 

 

 

Topic:     A Routing Extension for HELD

Draft:     draft-winterbottom-ecrit-priv-loc-04

Presenter: Laura Liess

 

ISSUE:= It was suggested to extend HELD, by adopting draft-winterbottom-ecrit-priv= -loc, in order to solve the problem presented.

OUTCOME: Some people did not agree to the statements made, and the suggested was = to solve the problem. Additional discussions need to take place on the mailing list.

 

 

 

Topic:     Feedback for ACE Use Cases<= /span>

Draft:     draft-seitz-ace-usecases-01=

Presenter: Ludwig Seitz

 

The ECRIT community was requested to provide feedback, and real-lire use= -cases.

 

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D3D5571ESESSMB209erics_-- From nobody Mon Jul 28 06:20:15 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820281A049C for ; Mon, 28 Jul 2014 06:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNaAZA2ShD43 for ; Mon, 28 Jul 2014 06:19:59 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3E81B278A for ; Mon, 28 Jul 2014 06:19:58 -0700 (PDT) Received: from pps.filterd (m0049367.ppops.net [127.0.0.1]) by m0049367.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s6SDIRg7008592; Mon, 28 Jul 2014 09:19:57 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049367.ppops.net-0018ba01. with ESMTP id 1ncck7m547-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Jul 2014 09:19:57 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc10.cis.neustar.com ([169.254.4.169]) with mapi id 14.03.0158.001; Mon, 28 Jul 2014 09:19:56 -0400 From: "Rosen, Brian" To: James Winterbottom Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqmafuI7FAtqYZUKte6fVQPTeRw== Date: Mon, 28 Jul 2014 13:19:55 +0000 Message-ID: <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> In-Reply-To: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: <950F28435C7E8F43ADA785AF13750968@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7512 signatures=670489 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/Nsi_9YOMoDrLHM1E5hc6STDEjvs Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:20:06 -0000 The milestone you are referring to is a document so far from the IETF appro= ach on emergency calls that I fail to see the benefit of getting one protoc= ol, HELD, used by the group pushing this architecture. =20 I am convinced we will need to support an environment where it is not accep= table to have the end device in the path for location. The level of parano= ia about that is so high, if we want to make progress in the countries wher= e it exists, we need to do something. In some of these environments, it=92= s unacceptable to have the CSP get location. Using HELD with some non-IP i= dentifier to get location by reference works okay. What is needed is a way= for routing to work. This can be done in two ways. One is allowing HELD = to return route, which is how this doc does it. The other is to allow LoST= to do LbyR. I prefer the latter, but would be willing to go along with th= e HELD mechanism if consensus was to do it that way. Please don=92t use th= e =93one less query=94 argument. It just moves the route query from the CS= P to the LIS. =20 Brian On Jul 24, 2014, at 7:02 PM, James Winterbottom wrote: > Hi All, >=20 > This is a bit of rant, for which I am only partially apologetic because L= aura and I first presented the need for this draft more than years ago when= there was time for a debate. I think that that time has largely passed now= . I sent emails to the list at the end of May and the start of June asking = for feedback on this draft and again stated why it was needed and got next = to zero response back. >=20 > http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html > http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html >=20 > The specification that is dependent on a solution to this problem has a m= ilestone set for end of 1H15. > There simply isn=92t time to have a 3 month mailing list debate on this t= opic and then =93maybe=94 have something that can be adopted in the nov/dec= timeframe. > If this topic can move =93very quickly=94 then I see some benefit in cont= inuing a discussion, otherwise I see little point as decisions to address t= he need will be made elsewhere. >=20 > Cheers > James >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Jul 28 06:22:50 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF791A0255 for ; Mon, 28 Jul 2014 06:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTyY2oZo0hI0 for ; Mon, 28 Jul 2014 06:22:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FADB1A01C6 for ; Mon, 28 Jul 2014 06:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3263; q=dns/txt; s=iport; t=1406553766; x=1407763366; h=from:to:subject:date:message-id:mime-version; bh=EsymzRIM/ieJJxs4yLu9yt+0qGc2bVmvM0dLDUN1DrM=; b=Ep0jv8hbF6E8ixOeDdby0eqTfb7U0lnHpRYlFAyQjByGygfHgP8EUsp/ 1+Oko77tGQl8X/wscvyh0mf6qya2cyZJ40Wg3vBun/Gad765rezUlPh6c CQ+Ic2AShp9m2KVMTBqOaU3vPTa4BWOurHtrAF+xKmxk1urwMhocQ3HBB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFANBN1lOtJA2G/2dsb2JhbABZgkdHgS3UXhZ3hAqBCwEMdCcEiFWXUaYlF5QdBZtMlEyDSYIx X-IronPort-AV: E=Sophos;i="5.01,749,1400025600"; d="scan'208,217";a="343289344" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jul 2014 13:22:45 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6SDMiDk009048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Jul 2014 13:22:44 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 08:22:44 -0500 From: "Marc Linsner (mlinsner)" To: "ecrit@ietf.org" Thread-Topic: draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqmcDQBOWz8idXUOAditSmLV3Jg== Date: Mon, 28 Jul 2014 13:22:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.98] Content-Type: multipart/alternative; boundary="_000_CFFBC6E25D512mlinsnerciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/2_gwShrA6ADjReuM7LhTu_2Eu2s Subject: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 13:22:48 -0000 --_000_CFFBC6E25D512mlinsnerciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, This draft was presented in a compressed time slot at the Toronto meeting l= ast week. James W. has indicated an urgency to move this work forward. Th= e chairs are asking everyone to review this from the perspective of adoptin= g this draft as a wg item. So, please review this from the overall archite= ctural value of providing emergency call routing within a HELD req/response= (protocol details and word smithing can be done after it becomes a wg item= ). Since James has indicated this work will be used by other SDOs, and coupled= with the stated urgency, the chairs request that you review the draft and = indicate to the list by COB Wednesday August 6, 2014 your opinion: 1. I believe this work should move forward in ECRIT 2. I=92m agnostic to this work and don=92t care either way 3. I=92m opposed to this architectural change to the ECRIT model and bel= ieve this work should not be adopted. A indication of #2 tells the chairs that you are aware of the work and trul= y don=92t have an opinion, it helps us in determining what percentage of th= e wg participants have read the draft. Thanks, Marc & Roger --_000_CFFBC6E25D512mlinsnerciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9D2A51C2B4886249B8D26F4089E06964@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
All,

This draft was presented in a compressed time slot at the Toronto meet= ing last week.  James W. has indicated an urgency to move this work fo= rward.  The chairs are asking everyone to review this from the perspec= tive of adopting this draft as a wg item.  So, please review this from the overall architectural value of provi= ding emergency call routing within a HELD req/response (protocol details an= d word smithing can be done after it becomes a wg item).

Since James has indicated this work will be used by other SDOs, and co= upled with the stated urgency, the chairs request that you review the draft= and indicate to the list by COB Wednesday August 6, 2014 your opinion:
  1. I believe this work should move forward in ECRIT
  2. I=92m agnostic= to this work and don=92t care either way
  3. I=92m opposed to this arc= hitectural change to the ECRIT model and believe this work should not be ad= opted.

A indication of #2 tells the chairs that you are aware of the work and= truly don=92t have an opinion, it helps us in determining what percentage = of the wg participants have read the draft.

Thanks,

Marc & Roger


--_000_CFFBC6E25D512mlinsnerciscocom_-- From nobody Mon Jul 28 07:11:11 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDD01B2843 for ; Mon, 28 Jul 2014 07:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRj_tju1WOUd for ; Mon, 28 Jul 2014 07:11:07 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B1D1B2840 for ; Mon, 28 Jul 2014 07:11:07 -0700 (PDT) Received: from pps.filterd (m0049402.ppops.net [127.0.0.1]) by m0049402.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s6SE8pXs006158; Mon, 28 Jul 2014 10:11:06 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049402.ppops.net-0018ba01. with ESMTP id 1nccjtkku0-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Jul 2014 10:11:06 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 28 Jul 2014 10:11:04 -0400 From: "Rosen, Brian" To: Marc Linsner Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqm3Ewhw0VRgmoEOQPGSTHRxQ3A== Date: Mon, 28 Jul 2014 14:11:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.12] Content-Type: multipart/alternative; boundary="_000_FF65E979C6E04413B58B708FB1E804EFneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7512 signatures=670489 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/9kEct223IWf3B7hiER7SWM_KBcc Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 14:11:08 -0000 --_000_FF65E979C6E04413B58B708FB1E804EFneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As I said in my prior email, I think we need to do SOMETHING that allows an= environment where the device is not involved with location and the CSP can= not see location. I prefer LoST-allows-LbyR, but if consensus is HELD-retu= rns-route, I=92ll support it. I=92m not in a hurry - the document James is concerned about is not somethi= ng I am interested in facilitating. It should not be advanced. I hope it = doesn=92t advance, at least as is. So that puts me between 1 and 3. Brian On Jul 28, 2014, at 9:22 AM, Marc Linsner (mlinsner) > wrote: All, This draft was presented in a compressed time slot at the Toronto meeting l= ast week. James W. has indicated an urgency to move this work forward. Th= e chairs are asking everyone to review this from the perspective of adoptin= g this draft as a wg item. So, please review this from the overall archite= ctural value of providing emergency call routing within a HELD req/response= (protocol details and word smithing can be done after it becomes a wg item= ). Since James has indicated this work will be used by other SDOs, and coupled= with the stated urgency, the chairs request that you review the draft and = indicate to the list by COB Wednesday August 6, 2014 your opinion: 1. I believe this work should move forward in ECRIT 2. I=92m agnostic to this work and don=92t care either way 3. I=92m opposed to this architectural change to the ECRIT model and bel= ieve this work should not be adopted. A indication of #2 tells the chairs that you are aware of the work and trul= y don=92t have an opinion, it helps us in determining what percentage of th= e wg participants have read the draft. Thanks, Marc & Roger _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_FF65E979C6E04413B58B708FB1E804EFneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <233D9764261C4542892AA406A76A658B@neustar.biz> Content-Transfer-Encoding: quoted-printable As I said in my prior email, I think we need to do SOMETHING that allows an= environment where the device is not involved with location and the CSP can= not see location.  I prefer LoST-allows-LbyR, but if consensus is HELD= -returns-route, I=92ll support it.

I=92m not in a hurry - the document James is concerned about is not so= mething I am interested in facilitating.  It should not be advanced. &= nbsp;I hope it doesn=92t advance, at least as is.

So that puts me between 1 and 3.

Brian

On Jul 28, 2014, at 9:22 AM, Marc Linsner (mlinsner) <mlinsner@cisco.com> wrote:

All,

This draft was presented in a compressed time slot at the Toronto meet= ing last week.  James W. has indicated an urgency to move this work fo= rward.  The chairs are asking everyone to review this from the perspec= tive of adopting this draft as a wg item.  So, please review this from the overall architectural value of provi= ding emergency call routing within a HELD req/response (protocol details an= d word smithing can be done after it becomes a wg item).

Since James has indicated this work will be used by other SDOs, and co= upled with the stated urgency, the chairs request that you review the draft= and indicate to the list by COB Wednesday August 6, 2014 your opinion:
  1. I believe this work should move forward in ECRIT
  2. I=92m agnostic= to this work and don=92t care either way
  3. I=92m opposed to this arc= hitectural change to the ECRIT model and believe this work should not be ad= opted.

A indication of #2 tells the chairs that you are aware of the work and= truly don=92t have an opinion, it helps us in determining what percentage = of the wg participants have read the draft.

Thanks,

Marc & Roger


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

--_000_FF65E979C6E04413B58B708FB1E804EFneustarbiz_-- From nobody Mon Jul 28 08:04:02 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEF21B2866 for ; Mon, 28 Jul 2014 08:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHHcXt9_1rwo for ; Mon, 28 Jul 2014 08:03:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id DF9711A02E6 for ; Mon, 28 Jul 2014 08:03:56 -0700 (PDT) Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MTBsk-1X1Dnz0O4E-00S6rw; Mon, 28 Jul 2014 17:03:45 +0200 Message-ID: <53D66652.8050509@gmx.net> Date: Mon, 28 Jul 2014 17:03:46 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Marc Linsner (mlinsner)" , "ecrit@ietf.org" References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="saXgUaHlCBQe5v5V7pGmubowVSxGt51PW" X-Provags-ID: V03:K0:IuqzZmT0YXuYVBfdpU3CfkUb3sGEaSG+HjLrN8gqN7rAffkcFql /6Vcbl/JN1e1iFIMZCHWxlFoSqO1t+0G5mg6cDc5O1/+Vh0P+i23GOzN9Lsx9HLx0mDHkqq 65f2J1wujjbMuSu0XkU7F52A+990efPqnIeqzd6vVENAKZ8ucTX6jPg0gJNvFj7Oq+7WTzl 8Wh+Go29CtBPD4Xh2oqhQ== Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/tPNNN5A8Td0iBspT29zVqD2aDgw Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:04:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --saXgUaHlCBQe5v5V7pGmubowVSxGt51PW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would go with #1. Some deployments prefer a deployment where the device does not use LoST or, even worse, where the device does not contribute location at all. I also see the need to finish this work quickly since otherwise other protocols will get chosen. Ciao Hannes On 07/28/2014 03:22 PM, Marc Linsner (mlinsner) wrote: > All, >=20 > This draft was presented in a compressed time slot at the Toronto > meeting last week. James W. has indicated an urgency to move this work= > forward. The chairs are asking everyone to review this from the > perspective of adopting this draft as a wg item. So, please review thi= s > from the overall architectural value of providing emergency call routin= g > within a HELD req/response (protocol details and word smithing can be > done after it becomes a wg item). >=20 > Since James has indicated this work will be used by other SDOs, and > coupled with the stated urgency, the chairs request that you review the= > draft and indicate to the list by COB Wednesday August 6, 2014 your opi= nion: >=20 > 1. I believe this work should move forward in ECRIT > 2. I=92m agnostic to this work and don=92t care either way > 3. I=92m opposed to this architectural change to the ECRIT model and > believe this work should not be adopted. >=20 >=20 > A indication of #2 tells the chairs that you are aware of the work and > truly don=92t have an opinion, it helps us in determining what percenta= ge > of the wg participants have read the draft. >=20 > Thanks, >=20 > Marc & Roger >=20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 --saXgUaHlCBQe5v5V7pGmubowVSxGt51PW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJT1mZSAAoJEGhJURNOOiAtcDgH/3o/WUvl5qktii/wJKBDPMsl 2RSlCTl8/5myiZRMFj6UqSgtmcw9TUAsMEFTZE/XjhzV4DjeX4aOUEhIvM0rc+eF /rZqqBeVOPxdjo+MChXX2f+8hd5mPOHzsAZMrHDDvliWVSCcDI2i0wfmwgVmXFwe c3vW8IUmZd9OWKRhHlXvld0G9oVADryNfpXxT2/7VN5FBJ9Qb0nwzlpi8xXC4H2T eoatzH1kJfe+irdj/QZpBFoXawrKywE1WJ2Z8QQ2FPJY/pBFNPnc3URkvBGD0NVx yks1APMIftEe5qaw5z4kZom2f4xfqXol48kvk5jOIyD+AnvDSMnVBQjJhh80w0w= =atsZ -----END PGP SIGNATURE----- --saXgUaHlCBQe5v5V7pGmubowVSxGt51PW-- From nobody Mon Jul 28 13:28:04 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A451A00EB for ; Mon, 28 Jul 2014 13:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN4ywU9W_866 for ; Mon, 28 Jul 2014 13:28:01 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706621B28E6 for ; Mon, 28 Jul 2014 13:28:01 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id fp1so10551363pdb.27 for ; Mon, 28 Jul 2014 13:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WW3fyCHA6AnNEajSeXyMqWrPYsi3xuYW3g9fGtLmvXo=; b=vndaAJeJ2UCsvFzykEKY3wm/opgiGFs9o5ACogPEiJrGFx1CHTQ8YRPXqHfgiQ/JhQ 7iwnHL/3UwFHeitin7ekDa/RoGPnN03oq1Mk9x7visI1kvgCdsGeGIivlMuFWJLPewVl EIzmt/56P1VS5oJp0KFDnMs3dtKJVKyHnDBlddG1pnTkkvNEYgYhowmpa9oSIb5mEVEM Yw32jI/etFvegzgfegGG8Kk1B7ie99m9hAfm4H0I9+YKUH0Bz0jiY87tPSPn7gGnGKVM Ejfrg7y73L92dDK7fpXe8Dd3BQWI9obrMr1bWA8G7n4e9/KGL3IMaE6W/f+FFqP+WfBq 7Jdw== X-Received: by 10.68.130.170 with SMTP id of10mr3850479pbb.103.1406579281075; Mon, 28 Jul 2014 13:28:01 -0700 (PDT) Received: from [192.168.1.10] (124-168-198-48.dyn.iinet.net.au. [124.168.198.48]) by mx.google.com with ESMTPSA id kk3sm18564061pbc.51.2014.07.28.13.27.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 13:28:00 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> Date: Tue, 29 Jul 2014 06:27:56 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/LjrGb4R49O9lc5ZnJV9CDAEJcrY Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:28:03 -0000 I totally disagree with your opening statement Brian. The IETF approach allows a VSP to acquire the endpoint location and = obtain routing information to the correct ESRP. This option allows = exactly this, but it adds the advantages or being a single query AND = allowing not requiring a trust relationship between the LS and the VSP. = If anything it enhances the security of the ECRIT proposal. LoST with LbyR is not going to meet the European needs, and on top of = this LoST using LbyR breaks the moment you introduce forest guides or = don=92t have the authoritative server at the get-go. Which, you won=92t. = Please don=92t try and push this solution, it won=92t address what is = needed and any work done will go the way of rough location. There really = is not time for a 5 year debate on this topic only for the IETF to come = around in the end like other protocol suggestions that I won=92t name! Let=92s be clear about a LIS holding civic address record EVEN in a = LoST-based environment. If, the LIS is required to validate records = then, if it ued LoST to do this it has EXACTLY and same informant that = any public LoST server would have, including the expiry times for the = bindings. Quite simply it has everything you need. What possible = conceivable benefits are there is forcing a to query approach except = that you want to delay the call from getting through or want to divulge = location values to entities that may not be entitled to see them? This debate should have happened 2 years ago. LbyR for LoST simply = doesn=92t work.=20 Cheers James On 28 Jul 2014, at 11:19 pm, Rosen, Brian = wrote: > The milestone you are referring to is a document so far from the IETF = approach on emergency calls that I fail to see the benefit of getting = one protocol, HELD, used by the group pushing this architecture. =20 >=20 > I am convinced we will need to support an environment where it is not = acceptable to have the end device in the path for location. The level = of paranoia about that is so high, if we want to make progress in the = countries where it exists, we need to do something. In some of these = environments, it=92s unacceptable to have the CSP get location. Using = HELD with some non-IP identifier to get location by reference works = okay. What is needed is a way for routing to work. This can be done in = two ways. One is allowing HELD to return route, which is how this doc = does it. The other is to allow LoST to do LbyR. I prefer the latter, = but would be willing to go along with the HELD mechanism if consensus = was to do it that way. Please don=92t use the =93one less query=94 = argument. It just moves the route query from the CSP to the LIS. =20 >=20 > Brian >=20 > On Jul 24, 2014, at 7:02 PM, James Winterbottom = wrote: >=20 >> Hi All, >>=20 >> This is a bit of rant, for which I am only partially apologetic = because Laura and I first presented the need for this draft more than = years ago when there was time for a debate. I think that that time has = largely passed now. I sent emails to the list at the end of May and the = start of June asking for feedback on this draft and again stated why it = was needed and got next to zero response back. >>=20 >> http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html >> http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html >>=20 >> The specification that is dependent on a solution to this problem has = a milestone set for end of 1H15. >> There simply isn=92t time to have a 3 month mailing list debate on = this topic and then =93maybe=94 have something that can be adopted in = the nov/dec timeframe. >> If this topic can move =93very quickly=94 then I see some benefit in = continuing a discussion, otherwise I see little point as decisions to = address the need will be made elsewhere. >>=20 >> Cheers >> James >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From nobody Mon Jul 28 13:30:09 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EF11A00EB for ; Mon, 28 Jul 2014 13:30:08 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KJIVgdgLnlD for ; Mon, 28 Jul 2014 13:30:06 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B291B2925 for ; Mon, 28 Jul 2014 13:30:06 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id eu11so11077969pac.18 for ; Mon, 28 Jul 2014 13:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Fvr3Hv6tSOPzcZ3yuu47pA/LyNqnx6exxiun+paDPqc=; b=YgEumSapDzR1Mqp5vNCeE+ZO32DD/TkIpiuGcJdMcRBJuPgB5Avfcn63FsCvinjecj rTr+SXb0etXtDRjYJd4RM9YGyrMO2hkfztRJPbtmT55mvfelSsIIfdbzRRAqqoNNuCdB S6ujRjnnyBvsnJsaRHsUXaeF7uUvu154OUf3VA+++0To3lw3D5W8Xi+XYT8ia/1y6ENb Lm2tZB8ZRDh0Q+1x8CnSkF5DMLe7vNa9CBHOT7qP4LbcHdK6qwqom1wmcVh1hEfIf+Kz G36Ghwk+lj5KZGkCQ9ihhcbef9CEsFgtGZQuQugiGmOK62cjdOe0mGZUQiy+pL2I5o9l R06g== X-Received: by 10.66.163.98 with SMTP id yh2mr41678565pab.104.1406579406164; Mon, 28 Jul 2014 13:30:06 -0700 (PDT) Received: from [192.168.1.10] (124-168-198-48.dyn.iinet.net.au. [124.168.198.48]) by mx.google.com with ESMTPSA id xy4sm70022628pac.19.2014.07.28.13.30.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 13:30:05 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4CAD86B0-AA38-482D-AB9D-8CCD5FFC4E48" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: Date: Tue, 29 Jul 2014 06:30:02 +1000 Message-Id: <3B7C55D6-CE28-4B95-80D2-11AA101C53C2@gmail.com> References: To: "Marc Linsner (mlinsner)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/djE1zJ-w_3UcDncGIsNfNWDCgDY Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:30:08 -0000 --Apple-Mail=_4CAD86B0-AA38-482D-AB9D-8CCD5FFC4E48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am going for #1. On 28 Jul 2014, at 11:22 pm, Marc Linsner (mlinsner) = wrote: > All, >=20 > This draft was presented in a compressed time slot at the Toronto = meeting last week. James W. has indicated an urgency to move this work = forward. The chairs are asking everyone to review this from the = perspective of adopting this draft as a wg item. So, please review this = from the overall architectural value of providing emergency call routing = within a HELD req/response (protocol details and word smithing can be = done after it becomes a wg item). >=20 > Since James has indicated this work will be used by other SDOs, and = coupled with the stated urgency, the chairs request that you review the = draft and indicate to the list by COB Wednesday August 6, 2014 your = opinion: > I believe this work should move forward in ECRIT > I=92m agnostic to this work and don=92t care either way > I=92m opposed to this architectural change to the ECRIT model and = believe this work should not be adopted. >=20 > A indication of #2 tells the chairs that you are aware of the work and = truly don=92t have an opinion, it helps us in determining what = percentage of the wg participants have read the draft. >=20 > Thanks, >=20 > Marc & Roger >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_4CAD86B0-AA38-482D-AB9D-8CCD5FFC4E48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am = going for #1.



On 28 Jul = 2014, at 11:22 pm, Marc Linsner (mlinsner) <mlinsner@cisco.com> = wrote:

All,

This draft was presented in a compressed time slot at the Toronto = meeting last week.  James W. has indicated an urgency to move this = work forward.  The chairs are asking everyone to review this from = the perspective of adopting this draft as a wg item.  So, please review this from the overall architectural value of = providing emergency call routing within a HELD req/response (protocol = details and word smithing can be done after it becomes a wg item).

Since James has indicated this work will be used by other SDOs, and = coupled with the stated urgency, the chairs request that you review the = draft and indicate to the list by COB Wednesday August 6, 2014 your = opinion:
  1. I believe this work should move forward in ECRIT
  2. I=92m = agnostic to this work and don=92t care either way
  3. I=92m opposed = to this architectural change to the ECRIT model and believe this work = should not be adopted.

A indication of #2 tells the chairs that you are aware of the work = and truly don=92t have an opinion, it helps us in determining what = percentage of the wg participants have read the draft.

Thanks,

Marc & Roger


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

= --Apple-Mail=_4CAD86B0-AA38-482D-AB9D-8CCD5FFC4E48-- From nobody Mon Jul 28 13:44:19 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F9C1A01A9 for ; Mon, 28 Jul 2014 13:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO7aveF-OQfK for ; Mon, 28 Jul 2014 13:44:15 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B351A01E6 for ; Mon, 28 Jul 2014 13:44:15 -0700 (PDT) Received: from pps.filterd (m0049376.ppops.net [127.0.0.1]) by m0049376.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s6SKgpa6031357; Mon, 28 Jul 2014 16:44:14 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049376.ppops.net-0018ba01. with ESMTP id 1ndvvf83ed-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Jul 2014 16:44:14 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc10.cis.neustar.com ([169.254.4.169]) with mapi id 14.03.0158.001; Mon, 28 Jul 2014 16:44:12 -0400 From: "Rosen, Brian" To: James Winterbottom Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqmafuI7FAtqYZUKte6fVQPTeR5u2MxUA//+PMYA= Date: Mon, 28 Jul 2014 20:44:12 +0000 Message-ID: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> In-Reply-To: <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.33.192.12] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5EDA3BDC0CC29947B28F18D539EBCE98@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7513 signatures=670489 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/QpxZrTVzpdC1l4bX_kEYqy2PqLA Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:44:17 -0000 Anyone who has access to the document is welcome to make their own judgement on what I said. LbyR in LoST allows the VSP to acquire an endpoint location reference and obtain routing information to the correct ESRP. It does=B9t require a trus= t relationship between the LS and the VSP. LoST using LbyR would work just fine with forest guides. The forest guide would have to accept LbyR, but since it uses LoST as its interface, no problem if that=B9s the way we decide to do it. You need an authoritative route server that accepts geo and civic addresses and returns SIP URIs. If your interface to that server isn=B9t LoST, it has to be something that duplicates it pretty closely. Routes should not be static. Things can change, and especially, in disaster situations, routes can change with no notice. The route you get at validation may not be the route you get when you query at call time. LoST provides a TTL, but its a TTL on the binding, not the validation. Civic addresses validation can change, and the fact that we don=B9t have a way to push a change from the validation server back to the entity that validated is a problem. -planned-changes addresses that. Of course, you are only discussing civic addresses (geos don=B9t get validated), so using the validation query to obtain route doesn=B9t work with geos. None of this changes anything. LoST LbyR is as least as good of a solution as HELD-returns-route. HELD-returns-route has to have the TTL, the boundary, and the other LoST return things to be useful. Brian On 7/28/14, 4:27 PM, "James Winterbottom" wrote: >I totally disagree with your opening statement Brian. > >The IETF approach allows a VSP to acquire the endpoint location and >obtain routing information to the correct ESRP. This option allows >exactly this, but it adds the advantages or being a single query AND >allowing not requiring a trust relationship between the LS and the VSP. >If anything it enhances the security of the ECRIT proposal. > >LoST with LbyR is not going to meet the European needs, and on top of >this LoST using LbyR breaks the moment you introduce forest guides or >don=B9t have the authoritative server at the get-go. Which, you won=B9t. >Please don=B9t try and push this solution, it won=B9t address what is need= ed >and any work done will go the way of rough location. There really is not >time for a 5 year debate on this topic only for the IETF to come around >in the end like other protocol suggestions that I won=B9t name! > >Let=B9s be clear about a LIS holding civic address record EVEN in a >LoST-based environment. If, the LIS is required to validate records then, >if it ued LoST to do this it has EXACTLY and same informant that any >public LoST server would have, including the expiry times for the >bindings. Quite simply it has everything you need. What possible >conceivable benefits are there is forcing a to query approach except that >you want to delay the call from getting through or want to divulge >location values to entities that may not be entitled to see them? > >This debate should have happened 2 years ago. LbyR for LoST simply >doesn=B9t work.=20 > >Cheers >James > > > > > >On 28 Jul 2014, at 11:19 pm, Rosen, Brian wrote: > >> The milestone you are referring to is a document so far from the IETF >>approach on emergency calls that I fail to see the benefit of getting >>one protocol, HELD, used by the group pushing this architecture. >>=20 >> I am convinced we will need to support an environment where it is not >>acceptable to have the end device in the path for location. The level >>of paranoia about that is so high, if we want to make progress in the >>countries where it exists, we need to do something. In some of these >>environments, it=B9s unacceptable to have the CSP get location. Using >>HELD with some non-IP identifier to get location by reference works >>okay. What is needed is a way for routing to work. This can be done in >>two ways. One is allowing HELD to return route, which is how this doc >>does it. The other is to allow LoST to do LbyR. I prefer the latter, >>but would be willing to go along with the HELD mechanism if consensus >>was to do it that way. Please don=B9t use the =B3one less query=B2 argum= ent. >>It just moves the route query from the CSP to the LIS. >>=20 >> Brian >>=20 >> On Jul 24, 2014, at 7:02 PM, James Winterbottom >> wrote: >>=20 >>> Hi All, >>>=20 >>> This is a bit of rant, for which I am only partially apologetic >>>because Laura and I first presented the need for this draft more than >>>years ago when there was time for a debate. I think that that time has >>>largely passed now. I sent emails to the list at the end of May and the >>>start of June asking for feedback on this draft and again stated why it >>>was needed and got next to zero response back. >>>=20 >>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html >>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html >>>=20 >>> The specification that is dependent on a solution to this problem has >>>a milestone set for end of 1H15. >>> There simply isn=B9t time to have a 3 month mailing list debate on this >>>topic and then =B3maybe=B2 have something that can be adopted in the >>>nov/dec timeframe. >>> If this topic can move =B3very quickly=B2 then I see some benefit in >>>continuing a discussion, otherwise I see little point as decisions to >>>address the need will be made elsewhere. >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 > From nobody Mon Jul 28 13:58:48 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792BC1A0277 for ; Mon, 28 Jul 2014 13:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjeKWveikRb1 for ; Mon, 28 Jul 2014 13:58:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A298F1A013B for ; Mon, 28 Jul 2014 13:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5188; q=dns/txt; s=iport; t=1406581121; x=1407790721; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9ZQinB6N36KUhXyENH/DihYfLIgWFpCVt9kzjByM1sw=; b=Xm2JTGl6DOGZtUgYKMMOWlHl4mHenCHXRoYlnqQfsMBwzVEA9/w9Nd7z 6lELpUuT/a3gSNmme4joWltz41JjYyZ3cpuIO2SJo0yr38URvHLqNvc8J qjfkupGYRFWCJlRuYZZqlY8And/4Aw4vZ1bjeGSQqCxk/nU3BByHNcoAA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAJG41lOtJV2Y/2dsb2JhbABZgw5SVwTMAQqHRQGBERZ3hAMBAQEEAQEBawQHDAQCAQgOAwECAQIBLiEGCxcGCAIEDgUJEgSIDwMRDbcUDYcHF4l/gyCBXAEBHAgrAgUCBIREBYo3jxCCBY4phiODSWwBgQICBxcEAhw X-IronPort-AV: E=Sophos;i="5.01,751,1400025600"; d="scan'208";a="343396981" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 28 Jul 2014 20:58:40 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s6SKweYw019988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 20:58:40 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 15:58:40 -0500 From: "Marc Linsner (mlinsner)" To: James Winterbottom Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPp5Nv4tqyEK5JTUai44qlt9Y0P5u10emAgAB3lgD//8WEgA== Date: Mon, 28 Jul 2014 20:58:39 +0000 Message-ID: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> In-Reply-To: <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.98] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/aD9-Zv6G6yqJP3UdK81mSk6GLPM Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 20:58:45 -0000 James, (with wg chair hat off) The IETF ECRIT architecture is designed to provide a clean approach to enabling emergency calls in the multi-layered Internet, by allowing the service provider of each layer to perform functions reasonably adaptable to their discipline. Forcing a L2/L3 provider to be responsible for emergency call routing is a "layer violation" that we normally don=B9t go out of our way to support. Reverse-engineering requirements to the benefit of a non-layered solution will be temporary at best. -Marc- -----Original Message----- From: James Winterbottom Date: Monday, July 28, 2014 at 4:27 PM To: "Rosen, Brian" Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 >I totally disagree with your opening statement Brian. > >The IETF approach allows a VSP to acquire the endpoint location and >obtain routing information to the correct ESRP. This option allows >exactly this, but it adds the advantages or being a single query AND >allowing not requiring a trust relationship between the LS and the VSP. >If anything it enhances the security of the ECRIT proposal. > >LoST with LbyR is not going to meet the European needs, and on top of >this LoST using LbyR breaks the moment you introduce forest guides or >don=B9t have the authoritative server at the get-go. Which, you won=B9t. >Please don=B9t try and push this solution, it won=B9t address what is need= ed >and any work done will go the way of rough location. There really is not >time for a 5 year debate on this topic only for the IETF to come around >in the end like other protocol suggestions that I won=B9t name! > >Let=B9s be clear about a LIS holding civic address record EVEN in a >LoST-based environment. If, the LIS is required to validate records then, >if it ued LoST to do this it has EXACTLY and same informant that any >public LoST server would have, including the expiry times for the >bindings. Quite simply it has everything you need. What possible >conceivable benefits are there is forcing a to query approach except that >you want to delay the call from getting through or want to divulge >location values to entities that may not be entitled to see them? > >This debate should have happened 2 years ago. LbyR for LoST simply >doesn=B9t work.=20 > >Cheers >James > > > > > >On 28 Jul 2014, at 11:19 pm, Rosen, Brian wrote: > >> The milestone you are referring to is a document so far from the IETF >>approach on emergency calls that I fail to see the benefit of getting >>one protocol, HELD, used by the group pushing this architecture. >>=20 >> I am convinced we will need to support an environment where it is not >>acceptable to have the end device in the path for location. The level >>of paranoia about that is so high, if we want to make progress in the >>countries where it exists, we need to do something. In some of these >>environments, it=B9s unacceptable to have the CSP get location. Using >>HELD with some non-IP identifier to get location by reference works >>okay. What is needed is a way for routing to work. This can be done in >>two ways. One is allowing HELD to return route, which is how this doc >>does it. The other is to allow LoST to do LbyR. I prefer the latter, >>but would be willing to go along with the HELD mechanism if consensus >>was to do it that way. Please don=B9t use the =B3one less query=B2 argum= ent. >>It just moves the route query from the CSP to the LIS. >>=20 >> Brian >>=20 >> On Jul 24, 2014, at 7:02 PM, James Winterbottom >> wrote: >>=20 >>> Hi All, >>>=20 >>> This is a bit of rant, for which I am only partially apologetic >>>because Laura and I first presented the need for this draft more than >>>years ago when there was time for a debate. I think that that time has >>>largely passed now. I sent emails to the list at the end of May and the >>>start of June asking for feedback on this draft and again stated why it >>>was needed and got next to zero response back. >>>=20 >>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html >>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html >>>=20 >>> The specification that is dependent on a solution to this problem has >>>a milestone set for end of 1H15. >>> There simply isn=B9t time to have a 3 month mailing list debate on this >>>topic and then =B3maybe=B2 have something that can be adopted in the >>>nov/dec timeframe. >>> If this topic can move =B3very quickly=B2 then I see some benefit in >>>continuing a discussion, otherwise I see little point as decisions to >>>address the need will be made elsewhere. >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Jul 28 14:00:09 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375B31A0271 for ; Mon, 28 Jul 2014 14:00:06 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htimnJsM3uRl for ; Mon, 28 Jul 2014 14:00:02 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F2C1A0217 for ; Mon, 28 Jul 2014 14:00:02 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so11175914pab.2 for ; Mon, 28 Jul 2014 14:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=bFVyxwtlD9jxgJYK5KQiC/Qcq3OCmW8k3rmMP+/AL8Y=; b=NLxDtwHq95wCq9TSWfz7PdfdG94n1g3RINuLgnQkXskrr5iCS4f3scWFcq+mR/lO7I AFp0iZeStlVsx6CLYLR8S/UllWtMF60p8+03iIZ4ZqIJb8bmsBb4gmSt0RV/1kelTq96 O4DpZIlpBNHkPavJZG5jvgqDeOPxPufOCSnGqxpQokV+sNARBXC/my4O1g45C5dULa4P pBEpFUjhnjmkmpKaWtebwnagf4I57QWroXYV8wUw5JWbM0+hRo/0fhlZVWU2WjRoSuJB KMHb/K0ufbVKcFfy3sS7e+WVx/XB+3WCXOywbe/MwpXzoDSUwDi8qFUQSxfFIyCgYXes VHDA== X-Received: by 10.68.232.34 with SMTP id tl2mr40938185pbc.81.1406581201258; Mon, 28 Jul 2014 14:00:01 -0700 (PDT) Received: from [192.168.1.10] (124-168-198-48.dyn.iinet.net.au. [124.168.198.48]) by mx.google.com with ESMTPSA id df4sm15265736pbc.19.2014.07.28.13.59.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 14:00:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C6B8DB4A-7236-4FE8-B340-DFF718CFDC40" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: Date: Tue, 29 Jul 2014 06:59:55 +1000 Message-Id: <5FB89935-D6BA-46CF-A2AB-116F8DA9DCB4@gmail.com> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/w9_ebtpsUsZhLV6BO-sEnIgXw6E Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:00:06 -0000 --Apple-Mail=_C6B8DB4A-7236-4FE8-B340-DFF718CFDC40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 inline: On 29 Jul 2014, at 6:44 am, Rosen, Brian = wrote: > Anyone who has access to the document is welcome to make their own > judgement on what I said. >=20 > LbyR in LoST allows the VSP to acquire an endpoint location reference = and > obtain routing information to the correct ESRP. It does=B9t require a = trust > relationship between the LS and the VSP. [AJW] Huh?? Which LoST server does the VSP contact in your scenario? = The ANP won=92t have put any record into the DNS for its domain and even = if it did that domain span several geographic areas LbyR in LoST can=92t = recurse or redirect.. BREAK.. The only way that it could work would = require the ANP to establish its own LoST server and simply spit back = the records from the LS anyway. Why is this being made as two queries = again? >=20 > LoST using LbyR would work just fine with forest guides. The forest = guide > would have to accept LbyR, but since it uses LoST as its interface, no > problem if that=B9s the way we decide to do it. [AJW] This means that any forest guide anywhere in the world is allowed = to get location from any LS in the world using an LbyR. This has huge = security and privacy implications apart from the fact imposing certain = constraints in countries that may well not want or need these = constraints. The problem with deciding to it that was is that you will end up in the = same position as with rough location after 2 years of debate, by which = time an alternative will have been found an used. >=20 > You need an authoritative route server that accepts geo and civic > addresses and returns SIP URIs. If your interface to that server = isn=B9t > LoST, it has to be something that duplicates it pretty closely. [AJW] No, we don=92t really need that. In the US you have = highly-structured civic addresses, for most of the rest of the world = they don=92t. In countries like German, ESRP addresses will be based on = who the ANP is, not necessarily the area served by the ANP. In the = mobile case, point of attachment is good enough usually to get to the = ESRP, again, I don=92t need a complex route server, just a table.=20 >=20 > Routes should not be static. Things can change, and especially, in > disaster situations, routes can change with no notice. The route you = get > at validation may not be the route you get when you query at call = time. > LoST provides a TTL, but its a TTL on the binding, not the validation. [AJW] Is this or is this not used by servers that cache the data and can = return a response? > Civic addresses validation can change, and the fact that we don=B9t = have a > way to push a change from the validation server back to the entity = that > validated is a problem. -planned-changes addresses that. Of course, = you > are only discussing civic addresses (geos don=B9t get validated), so = using > the validation query to obtain route doesn=B9t work with geos. [AJW] The route is no more static in the proposal I have made than it = would using forest guides or ached data sets. >=20 > None of this changes anything. LoST LbyR is as least as good of a > solution as HELD-returns-route. HELD-returns-route has to have the = TTL, > the boundary, and the other LoST return things to be useful. >=20 [AJW] See above, I have still not heard from anyone how the will work = despite having asked a number of times. > Brian >=20 > On 7/28/14, 4:27 PM, "James Winterbottom" = > wrote: >=20 >> I totally disagree with your opening statement Brian. >>=20 >> The IETF approach allows a VSP to acquire the endpoint location and >> obtain routing information to the correct ESRP. This option allows >> exactly this, but it adds the advantages or being a single query AND >> allowing not requiring a trust relationship between the LS and the = VSP. >> If anything it enhances the security of the ECRIT proposal. >>=20 >> LoST with LbyR is not going to meet the European needs, and on top of >> this LoST using LbyR breaks the moment you introduce forest guides or >> don=B9t have the authoritative server at the get-go. Which, you = won=B9t. >> Please don=B9t try and push this solution, it won=B9t address what is = needed >> and any work done will go the way of rough location. There really is = not >> time for a 5 year debate on this topic only for the IETF to come = around >> in the end like other protocol suggestions that I won=B9t name! >>=20 >> Let=B9s be clear about a LIS holding civic address record EVEN in a >> LoST-based environment. If, the LIS is required to validate records = then, >> if it ued LoST to do this it has EXACTLY and same informant that any >> public LoST server would have, including the expiry times for the >> bindings. Quite simply it has everything you need. What possible >> conceivable benefits are there is forcing a to query approach except = that >> you want to delay the call from getting through or want to divulge >> location values to entities that may not be entitled to see them? >>=20 >> This debate should have happened 2 years ago. LbyR for LoST simply >> doesn=B9t work.=20 >>=20 >> Cheers >> James >>=20 >>=20 >>=20 >>=20 >>=20 >> On 28 Jul 2014, at 11:19 pm, Rosen, Brian = wrote: >>=20 >>> The milestone you are referring to is a document so far from the = IETF >>> approach on emergency calls that I fail to see the benefit of = getting >>> one protocol, HELD, used by the group pushing this architecture. >>>=20 >>> I am convinced we will need to support an environment where it is = not >>> acceptable to have the end device in the path for location. The = level >>> of paranoia about that is so high, if we want to make progress in = the >>> countries where it exists, we need to do something. In some of = these >>> environments, it=B9s unacceptable to have the CSP get location. = Using >>> HELD with some non-IP identifier to get location by reference works >>> okay. What is needed is a way for routing to work. This can be = done in >>> two ways. One is allowing HELD to return route, which is how this = doc >>> does it. The other is to allow LoST to do LbyR. I prefer the = latter, >>> but would be willing to go along with the HELD mechanism if = consensus >>> was to do it that way. Please don=B9t use the =B3one less query=B2 = argument. >>> It just moves the route query from the CSP to the LIS. >>>=20 >>> Brian >>>=20 >>> On Jul 24, 2014, at 7:02 PM, James Winterbottom >>> wrote: >>>=20 >>>> Hi All, >>>>=20 >>>> This is a bit of rant, for which I am only partially apologetic >>>> because Laura and I first presented the need for this draft more = than >>>> years ago when there was time for a debate. I think that that time = has >>>> largely passed now. I sent emails to the list at the end of May and = the >>>> start of June asking for feedback on this draft and again stated = why it >>>> was needed and got next to zero response back. >>>>=20 >>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html >>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html >>>>=20 >>>> The specification that is dependent on a solution to this problem = has >>>> a milestone set for end of 1H15. >>>> There simply isn=B9t time to have a 3 month mailing list debate on = this >>>> topic and then =B3maybe=B2 have something that can be adopted in = the >>>> nov/dec timeframe. >>>> If this topic can move =B3very quickly=B2 then I see some benefit = in >>>> continuing a discussion, otherwise I see little point as decisions = to >>>> address the need will be made elsewhere. >>>>=20 >>>> Cheers >>>> James >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >=20 --Apple-Mail=_C6B8DB4A-7236-4FE8-B340-DFF718CFDC40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 inline:

On 29 Jul 2014, at 6:44 = am, Rosen, Brian <Brian.Rosen@neustar.biz> = wrote:

Anyone who has access to the document is welcome to make = their own
judgement on what I said.

LbyR in LoST allows the = VSP to acquire an endpoint location reference and
obtain routing = information to the correct ESRP.  It does=B9t require a = trust
relationship between the LS and the = VSP.
[AJW] Huh?? =  Which LoST server does the VSP contact in your scenario? The ANP = won=92t have put any record into the DNS for its domain and even if it = did that domain span several geographic areas LbyR in LoST can=92t = recurse or redirect.. BREAK.. The only way that it could work = would require the ANP to establish its own LoST server and simply = spit back the records from the LS anyway. Why is this being made as two = queries again?



LoST using LbyR would work just fine with forest = guides.  The forest guide
would have to accept LbyR, but since = it uses LoST as its interface, no
problem if that=B9s the way we = decide to do it.
[AJW] = This means that any forest guide anywhere in the world is = allowed to get location from any LS in the world using an LbyR. This has = huge security and privacy implications apart from the fact imposing = certain constraints in countries that may well not want or need these = constraints.
The problem = with deciding to it that was is that you will end up in the same = position as with rough location after 2 years of debate, by which time = an alternative will have been found an = used.


You need an = authoritative route server that accepts geo and civic
addresses and = returns SIP URIs.  If your interface to that server isn=B9t
LoST, = it has to be something that duplicates it pretty = closely.
[AJW] No, we = don=92t really need that. In the US you have highly-structured civic = addresses, for most of the rest of the world they don=92t. = In countries like German, ESRP addresses will be based on who the = ANP is, not necessarily the area served by the ANP. In the mobile case, = point of attachment is good enough usually to get to the ESRP, again, I = don=92t need a complex route server, just a = table. 


Routes = should not be static.  Things can change, and especially, = in
disaster situations, routes can change with no notice.  The = route you get
at validation may not be the route you get when you = query at call time.
LoST provides a TTL, but its a TTL on the = binding, not the validation.
[AJW] Is this or is this not used by servers that = cache the data and can return a = response?

Civic addresses = validation can change, and the fact that we don=B9t have a
way to = push a change from the validation server back to the entity = that
validated is a problem.  -planned-changes addresses that. =  Of course, you
are only discussing civic addresses (geos don=B9t = get validated), so using
the validation query to obtain route doesn=B9t= work with geos.
[AJW] = The route is no more static in the proposal I have made than it = would using forest guides or ached data = sets.


None of this = changes anything.  LoST LbyR is as least as good of a
solution = as HELD-returns-route.  HELD-returns-route has to have the = TTL,
the boundary, and the other LoST return things to be = useful.

[AJW] See = above, I have still not heard from anyone how the will work = despite having asked a number of times.

Brian

On 7/28/14, 4:27 PM, "James Winterbottom" = <a.james.winterbottom@gmail.= com>
wrote:

I totally = disagree with your opening statement Brian.

The IETF approach = allows a VSP to acquire the endpoint location and
obtain routing = information to the correct ESRP. This option allows
exactly this, but = it adds the advantages or being a single query AND
allowing not = requiring a trust relationship between the LS and the VSP.
If = anything it enhances the security of the ECRIT proposal.

LoST = with LbyR is not going to meet the European needs, and on top of
this = LoST using LbyR breaks the moment you introduce forest guides = or
don=B9t have the authoritative server at the get-go. Which, you = won=B9t.
Please don=B9t try and push this solution, it won=B9t = address what is needed
and any work done will go the way of rough = location. There really is not
time for a 5 year debate on this topic = only for the IETF to come around
in the end like other protocol = suggestions that I won=B9t name!

Let=B9s be clear about a LIS = holding civic address record EVEN in a
LoST-based environment. If, = the LIS is required to validate records then,
if it ued LoST to do = this it has EXACTLY and same informant that any
public LoST server = would have, including the expiry times for the
bindings. Quite simply = it has everything you need. What possible
conceivable benefits are = there is forcing a to query approach except that
you want to delay = the call from getting through or want to divulge
location values to = entities that may not be entitled to see them?

This debate should = have happened 2 years ago. LbyR for LoST simply
doesn=B9t work. =

Cheers
James





On 28 Jul 2014, at 11:19 = pm, Rosen, Brian <Brian.Rosen@neustar.biz> = wrote:

The milestone you are referring = to is a document so far from the IETF
approach on emergency calls = that I fail to see the benefit of getting
one protocol, HELD, used by = the group pushing this architecture.

I am convinced we will need = to support an environment where it is not
acceptable to have the end = device in the path for location.  The level
of paranoia about = that is so high, if we want to make progress in the
countries where = it exists, we need to do something.  In some of = these
environments, it=B9s unacceptable to have the CSP get location. =  Using
HELD with some non-IP identifier to get location by = reference works
okay.  What is needed is a way for routing to = work.  This can be done in
two ways.  One is allowing HELD = to return route, which is how this doc
does it.  The other is to = allow LoST to do LbyR.  I prefer the latter,
but would be = willing to go along with the HELD mechanism if consensus
was to do it = that way.  Please don=B9t use the =B3one less query=B2 = argument.
It just moves the route query from the CSP to the = LIS.

Brian

On Jul 24, 2014, at 7:02 PM, James = Winterbottom
<a.james.winterbottom@gmail.= com> wrote:

Hi All,

This = is a bit of rant, for which I am only partially apologetic
because = Laura and I first presented the need for this draft more than
years = ago when there was time for a debate. I think that that time = has
largely passed now. I sent emails to the list at the end of May = and the
start of June asking for feedback on this draft and again = stated why it
was needed and got next to zero response = back.

= http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html
ht= tp://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html

The = specification that is dependent on a solution to this problem has
a = milestone set for end of 1H15.
There simply isn=B9t time to have a 3 = month mailing list debate on this
topic and then =B3maybe=B2 have = something that can be adopted in the
nov/dec timeframe.
If this = topic can move =B3very quickly=B2 then I see some benefit = in
continuing a discussion, otherwise I see little point as decisions = to
address the need will be made = elsewhere.

Cheers
James



_________________________= ______________________
Ecrit mailing = list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
<= /blockquote>



<= /div>= --Apple-Mail=_C6B8DB4A-7236-4FE8-B340-DFF718CFDC40-- From nobody Mon Jul 28 14:04:27 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A951A0398 for ; Mon, 28 Jul 2014 14:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6zuKBiWmXwz for ; Mon, 28 Jul 2014 14:04:24 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D511A02E2 for ; Mon, 28 Jul 2014 14:04:24 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id g10so10494516pdj.15 for ; Mon, 28 Jul 2014 14:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gkVQybuagyIiD+1FVSwxYWFXcwwpoxMk+5GTkapSzzI=; b=Lq/0641zYYoAviNrocp7g3PFaBVnLHSkbjKacyeOzHBA5sWow5yjngCGgVKDLCuo+E x0u6NYa1c+C2B1Q0gTGUv1DqEvU+9ToGyQDZkL8qQxE7cv214e/gXIuMFVwEdp9dkVpq KZqjJqy48YuMRfOsPH/LfJ4TZycog5vBHpGpiAZdx8xxHy/WX77vXxK/t9LapnukcFG1 BYWlIm8v3NcbEiLz+0xsr8EhvKc7oWOmmPeP/CY/6Kae5ghLR2D6dWMZg4iLQfkcHMZq EsZccFAlmitvfjRKFuo7B6LuOMZScrttdLjeVeGUY2ildv9PLM9+cI3BC1FWrpgCmN4C Thiw== X-Received: by 10.66.231.139 with SMTP id tg11mr41492435pac.87.1406581463699; Mon, 28 Jul 2014 14:04:23 -0700 (PDT) Received: from [192.168.1.10] (124-168-198-48.dyn.iinet.net.au. [124.168.198.48]) by mx.google.com with ESMTPSA id mj9sm25736330pdb.44.2014.07.28.14.04.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 14:04:23 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: Date: Tue, 29 Jul 2014 07:04:19 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> To: "Marc Linsner (mlinsner)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/7HQNU-sJOI67XVtrAeKwTbFp_pU Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:04:26 -0000 Hi Marc, The IETF architecture already quasi-requires them to do this. They need to put a UNAPTR record for their domain into the DNS to enable = LoST to work for their domain. They need to ensure that civic address information will work with the = LoST server so that the call gets to the right ESRP. These are quasi-routing requirements placed on the ANP.=20 If you introduce LbyR to LoST then you now require them to have a LoST = server interface too. So quite honestly, I think it is a real stretch to say that we don=92t = place routing requirements on ANPs today. Cheers James On 29 Jul 2014, at 6:58 am, Marc Linsner (mlinsner) = wrote: > James, >=20 > (with wg chair hat off) >=20 > The IETF ECRIT architecture is designed to provide a clean approach to > enabling emergency calls in the multi-layered Internet, by allowing = the > service provider of each layer to perform functions reasonably = adaptable > to their discipline. Forcing a L2/L3 provider to be responsible for > emergency call routing is a "layer violation" that we normally don=B9t = go > out of our way to support. >=20 > Reverse-engineering requirements to the benefit of a non-layered = solution > will be temporary at best. >=20 > -Marc- >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: James Winterbottom > Date: Monday, July 28, 2014 at 4:27 PM > To: "Rosen, Brian" > Cc: "ecrit_ietf.org" > Subject: Re: [Ecrit] Discussion on = draft-winterbottom-ecrit-priv-loc-04 >=20 >> I totally disagree with your opening statement Brian. >>=20 >> The IETF approach allows a VSP to acquire the endpoint location and >> obtain routing information to the correct ESRP. This option allows >> exactly this, but it adds the advantages or being a single query AND >> allowing not requiring a trust relationship between the LS and the = VSP. >> If anything it enhances the security of the ECRIT proposal. >>=20 >> LoST with LbyR is not going to meet the European needs, and on top of >> this LoST using LbyR breaks the moment you introduce forest guides or >> don=B9t have the authoritative server at the get-go. Which, you = won=B9t. >> Please don=B9t try and push this solution, it won=B9t address what is = needed >> and any work done will go the way of rough location. There really is = not >> time for a 5 year debate on this topic only for the IETF to come = around >> in the end like other protocol suggestions that I won=B9t name! >>=20 >> Let=B9s be clear about a LIS holding civic address record EVEN in a >> LoST-based environment. If, the LIS is required to validate records = then, >> if it ued LoST to do this it has EXACTLY and same informant that any >> public LoST server would have, including the expiry times for the >> bindings. Quite simply it has everything you need. What possible >> conceivable benefits are there is forcing a to query approach except = that >> you want to delay the call from getting through or want to divulge >> location values to entities that may not be entitled to see them? >>=20 >> This debate should have happened 2 years ago. LbyR for LoST simply >> doesn=B9t work.=20 >>=20 >> Cheers >> James >>=20 >>=20 >>=20 >>=20 >>=20 >> On 28 Jul 2014, at 11:19 pm, Rosen, Brian = wrote: >>=20 >>> The milestone you are referring to is a document so far from the = IETF >>> approach on emergency calls that I fail to see the benefit of = getting >>> one protocol, HELD, used by the group pushing this architecture. >>>=20 >>> I am convinced we will need to support an environment where it is = not >>> acceptable to have the end device in the path for location. The = level >>> of paranoia about that is so high, if we want to make progress in = the >>> countries where it exists, we need to do something. In some of = these >>> environments, it=B9s unacceptable to have the CSP get location. = Using >>> HELD with some non-IP identifier to get location by reference works >>> okay. What is needed is a way for routing to work. This can be = done in >>> two ways. One is allowing HELD to return route, which is how this = doc >>> does it. The other is to allow LoST to do LbyR. I prefer the = latter, >>> but would be willing to go along with the HELD mechanism if = consensus >>> was to do it that way. Please don=B9t use the =B3one less query=B2 = argument. >>> It just moves the route query from the CSP to the LIS. >>>=20 >>> Brian >>>=20 >>> On Jul 24, 2014, at 7:02 PM, James Winterbottom >>> wrote: >>>=20 >>>> Hi All, >>>>=20 >>>> This is a bit of rant, for which I am only partially apologetic >>>> because Laura and I first presented the need for this draft more = than >>>> years ago when there was time for a debate. I think that that time = has >>>> largely passed now. I sent emails to the list at the end of May and = the >>>> start of June asking for feedback on this draft and again stated = why it >>>> was needed and got next to zero response back. >>>>=20 >>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html >>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html >>>>=20 >>>> The specification that is dependent on a solution to this problem = has >>>> a milestone set for end of 1H15. >>>> There simply isn=B9t time to have a 3 month mailing list debate on = this >>>> topic and then =B3maybe=B2 have something that can be adopted in = the >>>> nov/dec timeframe. >>>> If this topic can move =B3very quickly=B2 then I see some benefit = in >>>> continuing a discussion, otherwise I see little point as decisions = to >>>> address the need will be made elsewhere. >>>>=20 >>>> Cheers >>>> James >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From nobody Mon Jul 28 14:22:54 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9121A02A0 for ; Mon, 28 Jul 2014 14:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id defGcoK_nGR6 for ; Mon, 28 Jul 2014 14:22:49 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896ED1A01E2 for ; Mon, 28 Jul 2014 14:22:49 -0700 (PDT) Received: from pps.filterd (m0049367.ppops.net [127.0.0.1]) by m0049367.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s6SLKHpX023972; Mon, 28 Jul 2014 17:22:48 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049367.ppops.net-0018ba01. with ESMTP id 1ndvftr8s5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Jul 2014 17:22:47 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 28 Jul 2014 17:22:47 -0400 From: "Rosen, Brian" To: James Winterbottom Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqmafuI7FAtqYZUKte6fVQPTeR5u2MxUA//+PMYCAAHm+gP//kQmA Date: Mon, 28 Jul 2014 21:22:46 +0000 Message-ID: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> <5FB89935-D6BA-46CF-A2AB-116F8DA9DCB4@gmail.com> In-Reply-To: <5FB89935-D6BA-46CF-A2AB-116F8DA9DCB4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.33.192.12] Content-Type: multipart/alternative; boundary="_000_CFFC3260715CDbrianrosenneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7513 signatures=670489 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/NS6NdcxEGgq19Q-sSF2CnS7vrqs Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:22:52 -0000 --_000_CFFC3260715CDbrianrosenneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Inline From: James Winterbottom > Date: Monday, July 28, 2014 at 4:59 PM To: Brian Rosen > Cc: "ecrit_ietf.org" > Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 inline: On 29 Jul 2014, at 6:44 am, Rosen, Brian > wrote: Anyone who has access to the document is welcome to make their own judgement on what I said. LbyR in LoST allows the VSP to acquire an endpoint location reference and obtain routing information to the correct ESRP. It does=B9t require a trus= t relationship between the LS and the VSP. [AJW] Huh?? Which LoST server does the VSP contact in your scenario? The A= NP won=92t have put any record into the DNS for its domain and even if it d= id that domain span several geographic areas LbyR in LoST can=92t recurse o= r redirect.. BREAK.. The only way that it could work would require the ANP = to establish its own LoST server and simply spit back the records from the = LS anyway. Why is this being made as two queries again?
The VSP contacts any LoST server. Using recursion or iteration, it get= s to the authoritative one. If LoST does LbyR, then the VSP gets an LbyR b= y querying the LS. It then queries any LoST server to get route. LoST using LbyR would work just fine with forest guides. The forest guide would have to accept LbyR, but since it uses LoST as its interface, no problem if that=B9s the way we decide to do it. [AJW] This means that any forest guide anywhere in the world is allowed to = get location from any LS in the world using an LbyR. This has huge security= and privacy implications apart from the fact imposing certain constraints = in countries that may well not want or need these constraints. The problem with deciding to it that was is that you will end up in the sam= e position as with rough location after 2 years of debate, by which time an= alternative will have been found an used.
Spare me the polemics. Yes, the route infrastructure has to be trusted= . The LS can return something appropriately rough, with no standardization= , to an FG or a LoST server it doesn=92t recognize, if it wants to. Any po= int in the country, for example. Recursion would probably be required if e= veryone was paranoid about location. Note that the VSP can figure out loca= tion to a country with the route URI, no leakage there. You need an authoritative route server that accepts geo and civic addresses and returns SIP URIs. If your interface to that server isn=B9t LoST, it has to be something that duplicates it pretty closely. [AJW] No, we don=92t really need that. In the US you have highly-structured= civic addresses, for most of the rest of the world they don=92t. In countr= ies like German, ESRP addresses will be based on who the ANP is, not necess= arily the area served by the ANP. In the mobile case, point of attachment i= s good enough usually to get to the ESRP, again, I don=92t need a complex r= oute server, just a table.
In the US, like most places, you route by cell and sector, but the way = that is mechanized is the cell and sector is turned into some kind of locat= ion =96 a civic or a geo. The LoST database can be a simple table if you o= nly have a small range of addresses. We=92re discussing the protocol, not = the complexity of the data. I=92ll agree that if the VSP has the entire route table for all the jurisdi= ctions it operates in, then it doesn=92t need LoST for query and could use = something proprietary. Not sure what will happen in 3GPP, which is taking = that approach. I think that is a big mistake, but you still need a protoco= l that is queried with location and delivers URI. Routes should not be static. Things can change, and especially, in disaster situations, routes can change with no notice. The route you get at validation may not be the route you get when you query at call time. LoST provides a TTL, but its a TTL on the binding, not the validation. [AJW] Is this or is this not used by servers that cache the data and can re= turn a response?
Yes, but the route server determines the binding TTL. If it=92s set fo= r 15 minutes, it can change routes in a disaster situation reasonably promp= tly. As long as the cache is invalidated after the binding TTL, everything= works. You described a scenario where route was cached at validation. Th= at=92s fine, as long as the binding TTL is respected. Civic addresses validation can change, and the fact that we don=B9t have a way to push a change from the validation server back to the entity that validated is a problem. -planned-changes addresses that. Of course, you are only discussing civic addresses (geos don=B9t get validated), so using the validation query to obtain route doesn=B9t work with geos. [AJW] The route is no more static in the proposal I have made than it would= using forest guides or ached data sets.
If you accept the binding time as the validation period, okay, but I do= n=92t think that is what you meant. None of this changes anything. LoST LbyR is as least as good of a solution as HELD-returns-route. HELD-returns-route has to have the TTL, the boundary, and the other LoST return things to be useful. [AJW] See above, I have still not heard from anyone how the will work despi= te having asked a number of times. Brian On 7/28/14, 4:27 PM, "James Winterbottom" > wrote: I totally disagree with your opening statement Brian. The IETF approach allows a VSP to acquire the endpoint location and obtain routing information to the correct ESRP. This option allows exactly this, but it adds the advantages or being a single query AND allowing not requiring a trust relationship between the LS and the VSP. If anything it enhances the security of the ECRIT proposal. LoST with LbyR is not going to meet the European needs, and on top of this LoST using LbyR breaks the moment you introduce forest guides or don=B9t have the authoritative server at the get-go. Which, you won=B9t. Please don=B9t try and push this solution, it won=B9t address what is neede= d and any work done will go the way of rough location. There really is not time for a 5 year debate on this topic only for the IETF to come around in the end like other protocol suggestions that I won=B9t name! Let=B9s be clear about a LIS holding civic address record EVEN in a LoST-based environment. If, the LIS is required to validate records then, if it ued LoST to do this it has EXACTLY and same informant that any public LoST server would have, including the expiry times for the bindings. Quite simply it has everything you need. What possible conceivable benefits are there is forcing a to query approach except that you want to delay the call from getting through or want to divulge location values to entities that may not be entitled to see them? This debate should have happened 2 years ago. LbyR for LoST simply doesn=B9t work. Cheers James On 28 Jul 2014, at 11:19 pm, Rosen, Brian > wrote: The milestone you are referring to is a document so far from the IETF approach on emergency calls that I fail to see the benefit of getting one protocol, HELD, used by the group pushing this architecture. I am convinced we will need to support an environment where it is not acceptable to have the end device in the path for location. The level of paranoia about that is so high, if we want to make progress in the countries where it exists, we need to do something. In some of these environments, it=B9s unacceptable to have the CSP get location. Using HELD with some non-IP identifier to get location by reference works okay. What is needed is a way for routing to work. This can be done in two ways. One is allowing HELD to return route, which is how this doc does it. The other is to allow LoST to do LbyR. I prefer the latter, but would be willing to go along with the HELD mechanism if consensus was to do it that way. Please don=B9t use the =B3one less query=B2 argumen= t. It just moves the route query from the CSP to the LIS. Brian On Jul 24, 2014, at 7:02 PM, James Winterbottom > wro= te: Hi All, This is a bit of rant, for which I am only partially apologetic because Laura and I first presented the need for this draft more than years ago when there was time for a debate. I think that that time has largely passed now. I sent emails to the list at the end of May and the start of June asking for feedback on this draft and again stated why it was needed and got next to zero response back. http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html The specification that is dependent on a solution to this problem has a milestone set for end of 1H15. There simply isn=B9t time to have a 3 month mailing list debate on this topic and then =B3maybe=B2 have something that can be adopted in the nov/dec timeframe. If this topic can move =B3very quickly=B2 then I see some benefit in continuing a discussion, otherwise I see little point as decisions to address the need will be made elsewhere. Cheers James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_CFFC3260715CDbrianrosenneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0F262A6B0F725A4E9B8EA9CEB407F55E@neustar.biz> Content-Transfer-Encoding: quoted-printable
Inline

From: James Winterbottom <a.james.winterbottom@gmail.com<= /a>>
Date: Monday, July 28, 2014 at 4:59= PM
To: Brian Rosen <brian.rosen@neustar.biz>
Cc: "ecrit_ietf.org" <= ecrit@ietf.org>
Subject: Re: [Ecrit] Discussion on = draft-winterbottom-ecrit-priv-loc-04

inline:

On 29 Jul 2014, at 6:44 am, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:

Anyone who has access to the document is welcome = to make their own
judgement on what I said.

LbyR in LoST allows the VSP to acquire an endpoint location reference and obtain routing information to the correct ESRP.  It does=B9t require a= trust
relationship between the LS and the VSP.
[AJW] Huh??  Which LoST server does th= e VSP contact in your scenario? The ANP won=92t have put any record into th= e DNS for its domain and even if it did that domain span several geographic= areas LbyR in LoST can=92t recurse or redirect.. BREAK.. The only way that it could work would require the ANP to esta= blish its own LoST server and simply spit back the records from the LS anyw= ay. Why is this being made as two queries again?

<br>The VSP contacts any LoST server.  Using recursion or iterat= ion, it gets to the authoritative one.  If LoST does LbyR, then the VS= P gets an LbyR by querying the LS.  It then queries any LoST server to= get route.


 

LoST using LbyR would work just fine with forest guides.  The forest g= uide
would have to accept LbyR, but since it uses LoST as its interface, no
problem if that=B9s the way we decide to do it.
[AJW] This means that any forest guide=  anywhere in the world is allowed to get location from any LS in the w= orld using an LbyR. This has huge security and privacy implications ap= art from the fact imposing certain constraints in countries that may well not want or need these constraints.
The problem with deciding to it that was is= that you will end up in the same position as with rough location after 2 y= ears of debate, by which time an alternative will have been found an used.<= /font>
<br>Spare me the polemics.  Yes, the route infrastructure has to= be trusted.  The LS can return something appropriately rough, with no= standardization, to an FG or a LoST server it doesn=92t recognize, if it w= ants to.  Any point in the country, for example.  Recursion would probably be required if everyone was paranoid about location.  = Note that the VSP can figure out location to a country with the route URI, = no leakage there.




You need an authoritative route server that accepts geo and civic
addresses and returns SIP URIs.  If your interface to that server isn= =B9t
LoST, it has to be something that duplicates it pretty closely.
[AJW] No, we don=92t really need that. In t= he US you have highly-structured civic addresses, for most of the rest of t= he world they don=92t. In countries like German, ESRP addresses will b= e based on who the ANP is, not necessarily the area served by the ANP. In the mobile case, point of attachment is goo= d enough usually to get to the ESRP, again, I don=92t need a complex r= oute server, just a table. 
<br>In the US, like most places, you route by cell and sector, but th= e way that is mechanized is the cell and sector is turned into some kind of= location =96 a civic or a geo.  The LoST database can be a simple tab= le if you only have a small range of addresses.  We=92re discussing the protocol, not the complexity of the data.

I=92ll agree that if the VSP has the entire route table for all the ju= risdictions it operates in, then it doesn=92t need LoST for query and could= use something proprietary.  Not sure what will happen in 3GPP, which = is taking that approach.  I think that is a big mistake, but you still need a protocol that is queried with location= and delivers URI.


Routes should not be static.  Things can change, and especially, in disaster situations, routes can change with no notice.  The route you = get
at validation may not be the route you get when you query at call time.
LoST provides a TTL, but its a TTL on the binding, not the validation.
[AJW] Is this or is this not used by server= s that cache the data and can return a response?
<br>Yes, but the route server determines the binding TTL.  If it= =92s set for 15 minutes, it can change routes in a disaster situation reaso= nably promptly.  As long as the cache is invalidated after the binding= TTL, everything works.  You described a scenario where route was cached at validation.  That=92s fine, as long as the = binding TTL is respected.


Civic addresses validation can change, and the fa= ct that we don=B9t have a
way to push a change from the validation server back to the entity that
validated is a problem.  -planned-changes addresses that.  Of cou= rse, you
are only discussing civic addresses (geos don=B9t get validated), so using<= br> the validation query to obtain route doesn=B9t work with geos.
[AJW] The route is no more static in t= he proposal I have made than it would using forest guides or ached data set= s.
<br>If you accept the binding time as the validation period, okay, bu= t I don=92t think that is what you meant.

None of this changes anything.  LoST LbyR is as least as good of a
solution as HELD-returns-route.  HELD-returns-route has to have the TT= L,
the boundary, and the other LoST return things to be useful.

[AJW] See above, I have still not heard fro= m anyone how the will work despite having asked a number of times= .

Brian

On 7/28/14, 4:27 PM, "James Winterbottom" <a.james.winterbottom@gmail.com>
wrote:

I totally disagree with your opening statement Br= ian.

The IETF approach allows a VSP to acquire the endpoint location and
obtain routing information to the correct ESRP. This option allows
exactly this, but it adds the advantages or being a single query AND
allowing not requiring a trust relationship between the LS and the VSP.
If anything it enhances the security of the ECRIT proposal.

LoST with LbyR is not going to meet the European needs, and on top of
this LoST using LbyR breaks the moment you introduce forest guides or
don=B9t have the authoritative server at the get-go. Which, you won=B9t. Please don=B9t try and push this solution, it won=B9t address what is neede= d
and any work done will go the way of rough location. There really is not time for a 5 year debate on this topic only for the IETF to come around
in the end like other protocol suggestions that I won=B9t name!

Let=B9s be clear about a LIS holding civic address record EVEN in a
LoST-based environment. If, the LIS is required to validate records then, if it ued LoST to do this it has EXACTLY and same informant that any
public LoST server would have, including the expiry times for the
bindings. Quite simply it has everything you need. What possible
conceivable benefits are there is forcing a to query approach except that you want to delay the call from getting through or want to divulge
location values to entities that may not be entitled to see them?

This debate should have happened 2 years ago. LbyR for LoST simply
doesn=B9t work.

Cheers
James





On 28 Jul 2014, at 11:19 pm, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:

The milestone you are referring to is a document = so far from the IETF
approach on emergency calls that I fail to see the benefit of getting
one protocol, HELD, used by the group pushing this architecture.

I am convinced we will need to support an environment where it is not
acceptable to have the end device in the path for location.  The level=
of paranoia about that is so high, if we want to make progress in the
countries where it exists, we need to do something.  In some of these<= br> environments, it=B9s unacceptable to have the CSP get location.  Using=
HELD with some non-IP identifier to get location by reference works
okay.  What is needed is a way for routing to work.  This can be = done in
two ways.  One is allowing HELD to return route, which is how this doc=
does it.  The other is to allow LoST to do LbyR.  I prefer the la= tter,
but would be willing to go along with the HELD mechanism if consensus
was to do it that way.  Please don=B9t use the =B3one less query=B2 ar= gument.
It just moves the route query from the CSP to the LIS.

Brian

On Jul 24, 2014, at 7:02 PM, James Winterbottom
<a.james.winterbottom@= gmail.com> wrote:

Hi All,

This is a bit of rant, for which I am only partially apologetic
because Laura and I first presented the need for this draft more than
years ago when there was time for a debate. I think that that time has
largely passed now. I sent emails to the list at the end of May and the
start of June asking for feedback on this draft and again stated why it
was needed and got next to zero response back.

http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html
http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html

The specification that is dependent on a solution to this problem has
a milestone set for end of 1H15.
There simply isn=B9t time to have a 3 month mailing list debate on this
topic and then =B3maybe=B2 have something that can be adopted in the
nov/dec timeframe.
If this topic can move =B3very quickly=B2 then I see some benefit in
continuing a discussion, otherwise I see little point as decisions to
address the need will be made elsewhere.

Cheers
James



_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.or= g/mailman/listinfo/ecrit




 --_000_CFFC3260715CDbrianrosenneustarbiz_-- From nobody Mon Jul 28 14:30:46 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0701A0318 for ; Mon, 28 Jul 2014 14:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ucgc9c7TWKI7 for ; Mon, 28 Jul 2014 14:30:42 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE21D1A02D0 for ; Mon, 28 Jul 2014 14:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9492; q=dns/txt; s=iport; t=1406583042; x=1407792642; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hWU/aWxosCTQRCtzVrvSA/Qn827m79zLwPFk5IwhL/E=; b=Ye7LW80IB0HN9KaeQxBw5O1NSrRJk8rwfFs6jH8h+cJ/vRs9PX+D1Y6N sMBUfDtzzR1UhtiwF666vn+y8J3uosAjI+jDjoNtx75eNPPyL5thabGCd KH62XNetlXH2Ajlt0LKgEaCDxcekvs7L2VtdKahbIuPTLngWEbEXX8DRn M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAIXA1lOtJV2U/2dsb2JhbABZgw5SVwSCdMkNCodFARl5FneEAwEBAQQBAQExOgQHDAQCAQgOAwECAQIBBCgCAh8GCxcGCAIEDgUJEgSIDwMRDYpknCgGkA4NhxMXgSaIWYMggVwBASQrBwICAoJtgVcFmUeCBYwfggqGI4NJbAGBAgIHFwQCHA X-IronPort-AV: E=Sophos;i="5.01,751,1400025600"; d="scan'208";a="343437294" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jul 2014 21:30:41 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6SLUfHY011714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 21:30:41 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 16:30:41 -0500 From: "Marc Linsner (mlinsner)" To: James Winterbottom Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPp5Nv4tqyEK5JTUai44qlt9Y0P5u10emAgAB3lgD//8WEgIAARKaA///ETYA= Date: Mon, 28 Jul 2014 21:30:40 +0000 Message-ID: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.98] Content-Type: text/plain; charset="euc-kr" Content-ID: <8DD9DAABB91AAB49AD72781F4BFE1295@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/tFy01t2AIOnpx0wvMlmYfMDp3e4 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:30:44 -0000 SmFtZXMsDQoNCkluIHRoZSBFQ1JJVCBhcmNoaXRlY3R1cmUsIGxvY2F0aW9uIGRvZXMgbm90IGhh dmUgdG8gY29tZSBmcm9tIHRoZSBBTlAsDQp0aGUgZW5kLWRldmljZSBjYW4gc3VwcGx5IGxvY2F0 aW9uIHRvIGl0oa9zIFZTUC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEph bWVzIFdpbnRlcmJvdHRvbSA8YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPg0KRGF0ZTog TW9uZGF5LCBKdWx5IDI4LCAyMDE0IGF0IDU6MDQgUE0NClRvOiBNYXJjIExpbnNuZXIgPG1saW5z bmVyQGNpc2NvLmNvbT4NCkNjOiAiZWNyaXRfaWV0Zi5vcmciIDxlY3JpdEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbRWNyaXRdIERpc2N1c3Npb24gb24gZHJhZnQtd2ludGVyYm90dG9tLWVjcml0 LXByaXYtbG9jLTA0DQoNCj5IaSBNYXJjLA0KPg0KPlRoZSBJRVRGIGFyY2hpdGVjdHVyZSBhbHJl YWR5IHF1YXNpLXJlcXVpcmVzIHRoZW0gdG8gZG8gdGhpcy4NCj5UaGV5IG5lZWQgdG8gcHV0IGEg VU5BUFRSIHJlY29yZCBmb3IgdGhlaXIgZG9tYWluIGludG8gdGhlIEROUyB0byBlbmFibGUNCj5M b1NUIHRvIHdvcmsgZm9yIHRoZWlyIGRvbWFpbi4NCg0KSSBkb26hr3QgdW5kZXJzdGFuZCwgTGJ5 UiBwb2ludHMgdG8gdGhlIExTLCB3aGF0IGlzIFVOQVBUUiBmb3I/DQoNCg0KPlRoZXkgbmVlZCB0 byBlbnN1cmUgdGhhdCBjaXZpYyBhZGRyZXNzIGluZm9ybWF0aW9uIHdpbGwgd29yayB3aXRoIHRo ZQ0KPkxvU1Qgc2VydmVyIHNvIHRoYXQgdGhlIGNhbGwgZ2V0cyB0byB0aGUgcmlnaHQgRVNSUC4N Cj4NCj5UaGVzZSBhcmUgcXVhc2ktcm91dGluZyByZXF1aXJlbWVudHMgcGxhY2VkIG9uIHRoZSBB TlAuDQoNCk5vLCBpZiB0aGUgQU5QIGlzIHByb3ZpZGluZyBsb2NhdGlvbiwgaXQgbmVlZHMgdG8g cHJvdmlkZSB0aGUgZGF0YSBpbiBhDQpmb3JtIGFkaGVyaW5nIHRvIGxvY2FsIHN0YW5kYXJkcy4g IEkgZG9uoa90IGNvbnNpZGVyIHRoYXQgY2FsbCByb3V0aW5nLg0KDQoNCj4gDQo+SWYgeW91IGlu dHJvZHVjZSBMYnlSIHRvIExvU1QgdGhlbiB5b3Ugbm93IHJlcXVpcmUgdGhlbSB0byBoYXZlIGEg TG9TVA0KPnNlcnZlciBpbnRlcmZhY2UgdG9vLg0KDQpObywgZGVyZWZlcmVuY2luZyBMYnlSIGRv ZXNuoa90IHJlcXVpcmUgTG9TVC4NCg0KPg0KPlNvIHF1aXRlIGhvbmVzdGx5LCBJIHRoaW5rIGl0 IGlzIGEgcmVhbCBzdHJldGNoIHRvIHNheSB0aGF0IHdlIGRvbqGvdA0KPnBsYWNlIHJvdXRpbmcg cmVxdWlyZW1lbnRzIG9uIEFOUHMgdG9kYXkuDQo+DQo+Q2hlZXJzDQo+SmFtZXMNCj4NCj4NCj4N Cj5PbiAyOSBKdWwgMjAxNCwgYXQgNjo1OCBhbSwgTWFyYyBMaW5zbmVyIChtbGluc25lcikgPG1s aW5zbmVyQGNpc2NvLmNvbT4NCj53cm90ZToNCj4NCj4+IEphbWVzLA0KPj4gDQo+PiAod2l0aCB3 ZyBjaGFpciBoYXQgb2ZmKQ0KPj4gDQo+PiBUaGUgSUVURiBFQ1JJVCBhcmNoaXRlY3R1cmUgaXMg ZGVzaWduZWQgdG8gcHJvdmlkZSBhIGNsZWFuIGFwcHJvYWNoIHRvDQo+PiBlbmFibGluZyBlbWVy Z2VuY3kgY2FsbHMgaW4gdGhlIG11bHRpLWxheWVyZWQgSW50ZXJuZXQsIGJ5IGFsbG93aW5nIHRo ZQ0KPj4gc2VydmljZSBwcm92aWRlciBvZiBlYWNoIGxheWVyIHRvIHBlcmZvcm0gZnVuY3Rpb25z IHJlYXNvbmFibHkgYWRhcHRhYmxlDQo+PiB0byB0aGVpciBkaXNjaXBsaW5lLiAgRm9yY2luZyBh IEwyL0wzIHByb3ZpZGVyIHRvIGJlIHJlc3BvbnNpYmxlIGZvcg0KPj4gZW1lcmdlbmN5IGNhbGwg cm91dGluZyBpcyBhICJsYXllciB2aW9sYXRpb24iIHRoYXQgd2Ugbm9ybWFsbHkgZG9uqfZ0IGdv DQo+PiBvdXQgb2Ygb3VyIHdheSB0byBzdXBwb3J0Lg0KPj4gDQo+PiBSZXZlcnNlLWVuZ2luZWVy aW5nIHJlcXVpcmVtZW50cyB0byB0aGUgYmVuZWZpdCBvZiBhIG5vbi1sYXllcmVkDQo+PnNvbHV0 aW9uDQo+PiB3aWxsIGJlIHRlbXBvcmFyeSBhdCBiZXN0Lg0KPj4gDQo+PiAtTWFyYy0NCj4+IA0K Pj4gDQo+PiANCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJv bTogSmFtZXMgV2ludGVyYm90dG9tIDxhLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20+DQo+ PiBEYXRlOiBNb25kYXksIEp1bHkgMjgsIDIwMTQgYXQgNDoyNyBQTQ0KPj4gVG86ICJSb3Nlbiwg QnJpYW4iIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4NCj4+IENjOiAiZWNyaXRfaWV0Zi5vcmci IDxlY3JpdEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIERpc2N1c3Npb24gb24g ZHJhZnQtd2ludGVyYm90dG9tLWVjcml0LXByaXYtbG9jLTA0DQo+PiANCj4+PiBJIHRvdGFsbHkg ZGlzYWdyZWUgd2l0aCB5b3VyIG9wZW5pbmcgc3RhdGVtZW50IEJyaWFuLg0KPj4+IA0KPj4+IFRo ZSBJRVRGIGFwcHJvYWNoIGFsbG93cyBhIFZTUCB0byBhY3F1aXJlIHRoZSBlbmRwb2ludCBsb2Nh dGlvbiBhbmQNCj4+PiBvYnRhaW4gcm91dGluZyBpbmZvcm1hdGlvbiB0byB0aGUgY29ycmVjdCBF U1JQLiBUaGlzIG9wdGlvbiBhbGxvd3MNCj4+PiBleGFjdGx5IHRoaXMsIGJ1dCBpdCBhZGRzIHRo ZSBhZHZhbnRhZ2VzIG9yIGJlaW5nIGEgc2luZ2xlIHF1ZXJ5IEFORA0KPj4+IGFsbG93aW5nIG5v dCByZXF1aXJpbmcgYSB0cnVzdCByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgTFMgYW5kIHRoZSBW U1AuDQo+Pj4gSWYgYW55dGhpbmcgaXQgZW5oYW5jZXMgdGhlIHNlY3VyaXR5IG9mIHRoZSBFQ1JJ VCBwcm9wb3NhbC4NCj4+PiANCj4+PiBMb1NUIHdpdGggTGJ5UiBpcyBub3QgZ29pbmcgdG8gbWVl dCB0aGUgRXVyb3BlYW4gbmVlZHMsIGFuZCBvbiB0b3Agb2YNCj4+PiB0aGlzIExvU1QgdXNpbmcg TGJ5UiBicmVha3MgdGhlIG1vbWVudCB5b3UgaW50cm9kdWNlIGZvcmVzdCBndWlkZXMgb3INCj4+ PiBkb26p9nQgaGF2ZSB0aGUgYXV0aG9yaXRhdGl2ZSBzZXJ2ZXIgYXQgdGhlIGdldC1nby4gV2hp Y2gsIHlvdSB3b26p9nQuDQo+Pj4gUGxlYXNlIGRvbqn2dCB0cnkgYW5kIHB1c2ggdGhpcyBzb2x1 dGlvbiwgaXQgd29uqfZ0IGFkZHJlc3Mgd2hhdCBpcw0KPj4+bmVlZGVkDQo+Pj4gYW5kIGFueSB3 b3JrIGRvbmUgd2lsbCBnbyB0aGUgd2F5IG9mIHJvdWdoIGxvY2F0aW9uLiBUaGVyZSByZWFsbHkg aXMNCj4+Pm5vdA0KPj4+IHRpbWUgZm9yIGEgNSB5ZWFyIGRlYmF0ZSBvbiB0aGlzIHRvcGljIG9u bHkgZm9yIHRoZSBJRVRGIHRvIGNvbWUgYXJvdW5kDQo+Pj4gaW4gdGhlIGVuZCBsaWtlIG90aGVy IHByb3RvY29sIHN1Z2dlc3Rpb25zIHRoYXQgSSB3b26p9nQgbmFtZSENCj4+PiANCj4+PiBMZXSp 9nMgYmUgY2xlYXIgYWJvdXQgYSBMSVMgaG9sZGluZyBjaXZpYyBhZGRyZXNzIHJlY29yZCBFVkVO IGluIGENCj4+PiBMb1NULWJhc2VkIGVudmlyb25tZW50LiBJZiwgdGhlIExJUyBpcyByZXF1aXJl ZCB0byB2YWxpZGF0ZSByZWNvcmRzDQo+Pj50aGVuLA0KPj4+IGlmIGl0IHVlZCBMb1NUIHRvIGRv IHRoaXMgaXQgaGFzIEVYQUNUTFkgYW5kIHNhbWUgaW5mb3JtYW50IHRoYXQgYW55DQo+Pj4gcHVi bGljIExvU1Qgc2VydmVyIHdvdWxkIGhhdmUsIGluY2x1ZGluZyB0aGUgZXhwaXJ5IHRpbWVzIGZv ciB0aGUNCj4+PiBiaW5kaW5ncy4gUXVpdGUgc2ltcGx5IGl0IGhhcyBldmVyeXRoaW5nIHlvdSBu ZWVkLiBXaGF0IHBvc3NpYmxlDQo+Pj4gY29uY2VpdmFibGUgYmVuZWZpdHMgYXJlIHRoZXJlIGlz IGZvcmNpbmcgYSB0byBxdWVyeSBhcHByb2FjaCBleGNlcHQNCj4+PnRoYXQNCj4+PiB5b3Ugd2Fu dCB0byBkZWxheSB0aGUgY2FsbCBmcm9tIGdldHRpbmcgdGhyb3VnaCBvciB3YW50IHRvIGRpdnVs Z2UNCj4+PiBsb2NhdGlvbiB2YWx1ZXMgdG8gZW50aXRpZXMgdGhhdCBtYXkgbm90IGJlIGVudGl0 bGVkIHRvIHNlZSB0aGVtPw0KPj4+IA0KPj4+IFRoaXMgZGViYXRlIHNob3VsZCBoYXZlIGhhcHBl bmVkIDIgeWVhcnMgYWdvLiBMYnlSIGZvciBMb1NUIHNpbXBseQ0KPj4+IGRvZXNuqfZ0IHdvcmsu IA0KPj4+IA0KPj4+IENoZWVycw0KPj4+IEphbWVzDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+ Pj4gDQo+Pj4gT24gMjggSnVsIDIwMTQsIGF0IDExOjE5IHBtLCBSb3NlbiwgQnJpYW4gPEJyaWFu LlJvc2VuQG5ldXN0YXIuYml6Pg0KPj4+d3JvdGU6DQo+Pj4gDQo+Pj4+IFRoZSBtaWxlc3RvbmUg eW91IGFyZSByZWZlcnJpbmcgdG8gaXMgYSBkb2N1bWVudCBzbyBmYXIgZnJvbSB0aGUgSUVURg0K Pj4+PiBhcHByb2FjaCBvbiBlbWVyZ2VuY3kgY2FsbHMgdGhhdCBJIGZhaWwgdG8gc2VlIHRoZSBi ZW5lZml0IG9mIGdldHRpbmcNCj4+Pj4gb25lIHByb3RvY29sLCBIRUxELCB1c2VkIGJ5IHRoZSBn cm91cCBwdXNoaW5nIHRoaXMgYXJjaGl0ZWN0dXJlLg0KPj4+PiANCj4+Pj4gSSBhbSBjb252aW5j ZWQgd2Ugd2lsbCBuZWVkIHRvIHN1cHBvcnQgYW4gZW52aXJvbm1lbnQgd2hlcmUgaXQgaXMgbm90 DQo+Pj4+IGFjY2VwdGFibGUgdG8gaGF2ZSB0aGUgZW5kIGRldmljZSBpbiB0aGUgcGF0aCBmb3Ig bG9jYXRpb24uICBUaGUgbGV2ZWwNCj4+Pj4gb2YgcGFyYW5vaWEgYWJvdXQgdGhhdCBpcyBzbyBo aWdoLCBpZiB3ZSB3YW50IHRvIG1ha2UgcHJvZ3Jlc3MgaW4gdGhlDQo+Pj4+IGNvdW50cmllcyB3 aGVyZSBpdCBleGlzdHMsIHdlIG5lZWQgdG8gZG8gc29tZXRoaW5nLiAgSW4gc29tZSBvZiB0aGVz ZQ0KPj4+PiBlbnZpcm9ubWVudHMsIGl0qfZzIHVuYWNjZXB0YWJsZSB0byBoYXZlIHRoZSBDU1Ag Z2V0IGxvY2F0aW9uLiAgVXNpbmcNCj4+Pj4gSEVMRCB3aXRoIHNvbWUgbm9uLUlQIGlkZW50aWZp ZXIgdG8gZ2V0IGxvY2F0aW9uIGJ5IHJlZmVyZW5jZSB3b3Jrcw0KPj4+PiBva2F5LiAgV2hhdCBp cyBuZWVkZWQgaXMgYSB3YXkgZm9yIHJvdXRpbmcgdG8gd29yay4gIFRoaXMgY2FuIGJlIGRvbmUN Cj4+Pj5pbg0KPj4+PiB0d28gd2F5cy4gIE9uZSBpcyBhbGxvd2luZyBIRUxEIHRvIHJldHVybiBy b3V0ZSwgd2hpY2ggaXMgaG93IHRoaXMgZG9jDQo+Pj4+IGRvZXMgaXQuICBUaGUgb3RoZXIgaXMg dG8gYWxsb3cgTG9TVCB0byBkbyBMYnlSLiAgSSBwcmVmZXIgdGhlIGxhdHRlciwNCj4+Pj4gYnV0 IHdvdWxkIGJlIHdpbGxpbmcgdG8gZ28gYWxvbmcgd2l0aCB0aGUgSEVMRCBtZWNoYW5pc20gaWYg Y29uc2Vuc3VzDQo+Pj4+IHdhcyB0byBkbyBpdCB0aGF0IHdheS4gIFBsZWFzZSBkb26p9nQgdXNl IHRoZSCp+G9uZSBsZXNzIHF1ZXJ5qfcNCj4+Pj5hcmd1bWVudC4NCj4+Pj4gSXQganVzdCBtb3Zl cyB0aGUgcm91dGUgcXVlcnkgZnJvbSB0aGUgQ1NQIHRvIHRoZSBMSVMuDQo+Pj4+IA0KPj4+PiBC cmlhbg0KPj4+PiANCj4+Pj4gT24gSnVsIDI0LCAyMDE0LCBhdCA3OjAyIFBNLCBKYW1lcyBXaW50 ZXJib3R0b20NCj4+Pj4gPGEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbT4gd3JvdGU6DQo+ Pj4+IA0KPj4+Pj4gSGkgQWxsLA0KPj4+Pj4gDQo+Pj4+PiBUaGlzIGlzIGEgYml0IG9mIHJhbnQs IGZvciB3aGljaCBJIGFtIG9ubHkgcGFydGlhbGx5IGFwb2xvZ2V0aWMNCj4+Pj4+IGJlY2F1c2Ug TGF1cmEgYW5kIEkgZmlyc3QgcHJlc2VudGVkIHRoZSBuZWVkIGZvciB0aGlzIGRyYWZ0IG1vcmUg dGhhbg0KPj4+Pj4geWVhcnMgYWdvIHdoZW4gdGhlcmUgd2FzIHRpbWUgZm9yIGEgZGViYXRlLiBJ IHRoaW5rIHRoYXQgdGhhdCB0aW1lDQo+Pj4+Pmhhcw0KPj4+Pj4gbGFyZ2VseSBwYXNzZWQgbm93 LiBJIHNlbnQgZW1haWxzIHRvIHRoZSBsaXN0IGF0IHRoZSBlbmQgb2YgTWF5IGFuZA0KPj4+Pj50 aGUNCj4+Pj4+IHN0YXJ0IG9mIEp1bmUgYXNraW5nIGZvciBmZWVkYmFjayBvbiB0aGlzIGRyYWZ0 IGFuZCBhZ2FpbiBzdGF0ZWQgd2h5DQo+Pj4+Pml0DQo+Pj4+PiB3YXMgbmVlZGVkIGFuZCBnb3Qg bmV4dCB0byB6ZXJvIHJlc3BvbnNlIGJhY2suDQo+Pj4+PiANCj4+Pj4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9lY3JpdC9jdXJyZW50L21zZzA4ODIzLmh0bWwNCj4+Pj4+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9lY3JpdC9jdXJyZW50L21zZzA4 ODI3Lmh0bWwNCj4+Pj4+IA0KPj4+Pj4gVGhlIHNwZWNpZmljYXRpb24gdGhhdCBpcyBkZXBlbmRl bnQgb24gYSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gaGFzDQo+Pj4+PiBhIG1pbGVzdG9uZSBz ZXQgZm9yIGVuZCBvZiAxSDE1Lg0KPj4+Pj4gVGhlcmUgc2ltcGx5IGlzbqn2dCB0aW1lIHRvIGhh dmUgYSAzIG1vbnRoIG1haWxpbmcgbGlzdCBkZWJhdGUgb24gdGhpcw0KPj4+Pj4gdG9waWMgYW5k IHRoZW4gqfhtYXliZan3IGhhdmUgc29tZXRoaW5nIHRoYXQgY2FuIGJlIGFkb3B0ZWQgaW4gdGhl DQo+Pj4+PiBub3YvZGVjIHRpbWVmcmFtZS4NCj4+Pj4+IElmIHRoaXMgdG9waWMgY2FuIG1vdmUg qfh2ZXJ5IHF1aWNrbHmp9yB0aGVuIEkgc2VlIHNvbWUgYmVuZWZpdCBpbg0KPj4+Pj4gY29udGlu dWluZyBhIGRpc2N1c3Npb24sIG90aGVyd2lzZSBJIHNlZSBsaXR0bGUgcG9pbnQgYXMgZGVjaXNp b25zIHRvDQo+Pj4+PiBhZGRyZXNzIHRoZSBuZWVkIHdpbGwgYmUgbWFkZSBlbHNld2hlcmUuDQo+ Pj4+PiANCj4+Pj4+IENoZWVycw0KPj4+Pj4gSmFtZXMNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAN Cj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+Pj4+IEVjcml0QGlldGYub3JnDQo+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pj4+IA0KPj4+IA0KPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gRWNy aXQgbWFpbGluZyBsaXN0DQo+Pj4gRWNyaXRAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+PiANCj4NCg0K From nobody Mon Jul 28 14:38:52 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732211A024F for ; Mon, 28 Jul 2014 14:38:50 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOoK6cI8GNif for ; Mon, 28 Jul 2014 14:38:46 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6FD1A01D9 for ; Mon, 28 Jul 2014 14:38:45 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id lj1so11185635pab.19 for ; Mon, 28 Jul 2014 14:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=J0jowtHxRfs6SXEFlXGk43m/87uCDOHFFIoxuO1JvWE=; b=o8SjbgBWOoshYHL0d5z3v5jPPgxkncjX7UEK+szlV5W2s9HlFlMdiVkoSjYNteWkeD +5gLTRNcvxBlH7RI0cJQUF80tCaDIJdMA6FBwRwEyW+eXHGc37IkWyvgS78CHe1CWIx7 uJOR3H7Kc59v7gu8+Ae6aPu0ovMie1IkixOdKcUM0xD/DsRoZlgkPnkcSkm1F7ve1Ljl zwR6JwhCWv2tYAWtcDw2aE943Yn9zrCCTaEtFeDXbOQB+PPs1K2KHbKcfpkKxGEsE/Ic MmIADSFNOti3JJK8L1QwsEs78b5Ix0E5wsPT5A+pziPWBWrgKeSf9svxAfu5b5j7PONC m6hg== X-Received: by 10.66.66.166 with SMTP id g6mr41241819pat.108.1406583525614; Mon, 28 Jul 2014 14:38:45 -0700 (PDT) Received: from [192.168.1.10] (124-168-198-48.dyn.iinet.net.au. [124.168.198.48]) by mx.google.com with ESMTPSA id pc10sm11986738pdb.1.2014.07.28.14.38.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 14:38:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_45A53BE9-ECE9-48C6-9D37-9036E461FC1F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: Date: Tue, 29 Jul 2014 07:38:38 +1000 Message-Id: <7B2C4A6C-6220-4C28-B5DB-C87A20811FC4@gmail.com> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> <5FB89935-D6BA-46CF-A2AB-116F8DA9DCB4@gmail.com> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/0L5tu4lxkmFV5pUFo58jKXF3tVA Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:38:50 -0000 --Apple-Mail=_45A53BE9-ECE9-48C6-9D37-9036E461FC1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 29 Jul 2014, at 7:22 am, Rosen, Brian = wrote: > Inline >=20 > From: James Winterbottom > Date: Monday, July 28, 2014 at 4:59 PM > To: Brian Rosen > Cc: "ecrit_ietf.org" > Subject: Re: [Ecrit] Discussion on = draft-winterbottom-ecrit-priv-loc-04 >=20 > inline: >=20 > On 29 Jul 2014, at 6:44 am, Rosen, Brian = wrote: >=20 >> Anyone who has access to the document is welcome to make their own >> judgement on what I said. >>=20 >> LbyR in LoST allows the VSP to acquire an endpoint location reference = and >> obtain routing information to the correct ESRP. It does=B9t require = a trust >> relationship between the LS and the VSP. > [AJW] Huh?? Which LoST server does the VSP contact in your scenario? = The ANP won=92t have put any record into the DNS for its domain and even = if it did that domain span several geographic areas LbyR in LoST can=92t = recurse or redirect.. BREAK.. The only way that it could work would = require the ANP to establish its own LoST server and simply spit back = the records from the LS anyway. Why is this being made as two queries = again? >=20 >
The VSP contacts any LoST server. Using recursion or iteration, = it gets to the authoritative one. If LoST does LbyR, then the VSP gets = an LbyR by querying the LS. It then queries any LoST server to get = route. > [AJW] FAIL=85 How does the LoST server know where to go? It only has a = location URI and doesn=92t have permission to dereference it so it can=92t= determine where the authoritative server is using either recursion or = redirect. The model is broken. >=20 > =20 >>=20 >> LoST using LbyR would work just fine with forest guides. The forest = guide >> would have to accept LbyR, but since it uses LoST as its interface, = no >> problem if that=B9s the way we decide to do it. > [AJW] This means that any forest guide anywhere in the world is = allowed to get location from any LS in the world using an LbyR. This has = huge security and privacy implications apart from the fact imposing = certain constraints in countries that may well not want or need these = constraints. > The problem with deciding to it that was is that you will end up in = the same position as with rough location after 2 years of debate, by = which time an alternative will have been found an used. >
Spare me the polemics. Yes, the route infrastructure has to be = trusted. The LS can return something appropriately rough, with no = standardization, to an FG or a LoST server it doesn=92t recognize, if it = wants to. Any point in the country, for example. Recursion would = probably be required if everyone was paranoid about location. Note that = the VSP can figure out location to a country with the route URI, no = leakage there. [AJW] So you are re-advocating rough location? Hmm.. I though that that = option was just dropped. This doesn=92t provide the same benefits at all = of what is in the draft I proposed. The proposal in the draft only = requires the ANP, PSAP or entities inside the emergency network to have = access to location values. Requiring a global route server network to = have access to this is simply not join to meet the security/privacy = requirements in some countries. >=20 >=20 >=20 >>=20 >> You need an authoritative route server that accepts geo and civic >> addresses and returns SIP URIs. If your interface to that server = isn=B9t >> LoST, it has to be something that duplicates it pretty closely. > [AJW] No, we don=92t really need that. In the US you have = highly-structured civic addresses, for most of the rest of the world = they don=92t. In countries like German, ESRP addresses will be based on = who the ANP is, not necessarily the area served by the ANP. In the = mobile case, point of attachment is good enough usually to get to the = ESRP, again, I don=92t need a complex route server, just a table.=20 >
In the US, like most places, you route by cell and sector, but the = way that is mechanized is the cell and sector is turned into some kind = of location =96 a civic or a geo. The LoST database can be a simple = table if you only have a small range of addresses. We=92re discussing = the protocol, not the complexity of the data. [AJW] You conflating the route issue and the location display issue. I = don=92t need to turn the cell-id to location at routing time, the route = was predetermined. I only need a table, this cell-id maps to this URI. = Whether the PSAP gets the cell-id and then converts that into a area to = display, or it gets an area from the GMLC is immaterial. I only need a = table for routing. >=20 > I=92ll agree that if the VSP has the entire route table for all the = jurisdictions it operates in, then it doesn=92t need LoST for query and = could use something proprietary. Not sure what will happen in 3GPP, = which is taking that approach. I think that is a big mistake, but you = still need a protocol that is queried with location and delivers URI. >=20 >>=20 >> Routes should not be static. Things can change, and especially, in >> disaster situations, routes can change with no notice. The route you = get >> at validation may not be the route you get when you query at call = time. >> LoST provides a TTL, but its a TTL on the binding, not the = validation. > [AJW] Is this or is this not used by servers that cache the data and = can return a response? >
Yes, but the route server determines the binding TTL. If it=92s = set for 15 minutes, it can change routes in a disaster situation = reasonably promptly. As long as the cache is invalidated after the = binding TTL, everything works. You described a scenario where route was = cached at validation. That=92s fine, as long as the binding TTL is = respected. >=20 >=20 >> Civic addresses validation can change, and the fact that we don=B9t = have a >> way to push a change from the validation server back to the entity = that >> validated is a problem. -planned-changes addresses that. Of course, = you >> are only discussing civic addresses (geos don=B9t get validated), so = using >> the validation query to obtain route doesn=B9t work with geos. > [AJW] The route is no more static in the proposal I have made than it = would using forest guides or ached data sets. >
If you accept the binding time as the validation period, okay, but = I don=92t think that is what you meant. [AJW] You are right, I didn=92t. But in most cases the kind of = catastrophe you describe can and will be done using a different = approach. >>=20 >> None of this changes anything. LoST LbyR is as least as good of a >> solution as HELD-returns-route. HELD-returns-route has to have the = TTL, >> the boundary, and the other LoST return things to be useful. >>=20 > [AJW] See above, I have still not heard from anyone how the will work = despite having asked a number of times. [AJW] Question still answered, I provided the failure in LbyR for LoST = and it has not been addressed. >=20 >> Brian >>=20 >> On 7/28/14, 4:27 PM, "James Winterbottom" = >> wrote: >>=20 >>> I totally disagree with your opening statement Brian. >>>=20 >>> The IETF approach allows a VSP to acquire the endpoint location and >>> obtain routing information to the correct ESRP. This option allows >>> exactly this, but it adds the advantages or being a single query AND >>> allowing not requiring a trust relationship between the LS and the = VSP. >>> If anything it enhances the security of the ECRIT proposal. >>>=20 >>> LoST with LbyR is not going to meet the European needs, and on top = of >>> this LoST using LbyR breaks the moment you introduce forest guides = or >>> don=B9t have the authoritative server at the get-go. Which, you = won=B9t. >>> Please don=B9t try and push this solution, it won=B9t address what = is needed >>> and any work done will go the way of rough location. There really is = not >>> time for a 5 year debate on this topic only for the IETF to come = around >>> in the end like other protocol suggestions that I won=B9t name! >>>=20 >>> Let=B9s be clear about a LIS holding civic address record EVEN in a >>> LoST-based environment. If, the LIS is required to validate records = then, >>> if it ued LoST to do this it has EXACTLY and same informant that any >>> public LoST server would have, including the expiry times for the >>> bindings. Quite simply it has everything you need. What possible >>> conceivable benefits are there is forcing a to query approach except = that >>> you want to delay the call from getting through or want to divulge >>> location values to entities that may not be entitled to see them? >>>=20 >>> This debate should have happened 2 years ago. LbyR for LoST simply >>> doesn=B9t work.=20 >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 28 Jul 2014, at 11:19 pm, Rosen, Brian = wrote: >>>=20 >>>> The milestone you are referring to is a document so far from the = IETF >>>> approach on emergency calls that I fail to see the benefit of = getting >>>> one protocol, HELD, used by the group pushing this architecture. >>>>=20 >>>> I am convinced we will need to support an environment where it is = not >>>> acceptable to have the end device in the path for location. The = level >>>> of paranoia about that is so high, if we want to make progress in = the >>>> countries where it exists, we need to do something. In some of = these >>>> environments, it=B9s unacceptable to have the CSP get location. = Using >>>> HELD with some non-IP identifier to get location by reference works >>>> okay. What is needed is a way for routing to work. This can be = done in >>>> two ways. One is allowing HELD to return route, which is how this = doc >>>> does it. The other is to allow LoST to do LbyR. I prefer the = latter, >>>> but would be willing to go along with the HELD mechanism if = consensus >>>> was to do it that way. Please don=B9t use the =B3one less query=B2 = argument. >>>> It just moves the route query from the CSP to the LIS. >>>>=20 >>>> Brian >>>>=20 >>>> On Jul 24, 2014, at 7:02 PM, James Winterbottom >>>> wrote: >>>>=20 >>>>> Hi All, >>>>>=20 >>>>> This is a bit of rant, for which I am only partially apologetic >>>>> because Laura and I first presented the need for this draft more = than >>>>> years ago when there was time for a debate. I think that that time = has >>>>> largely passed now. I sent emails to the list at the end of May = and the >>>>> start of June asking for feedback on this draft and again stated = why it >>>>> was needed and got next to zero response back. >>>>>=20 >>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html >>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html >>>>>=20 >>>>> The specification that is dependent on a solution to this problem = has >>>>> a milestone set for end of 1H15. >>>>> There simply isn=B9t time to have a 3 month mailing list debate on = this >>>>> topic and then =B3maybe=B2 have something that can be adopted in = the >>>>> nov/dec timeframe. >>>>> If this topic can move =B3very quickly=B2 then I see some benefit = in >>>>> continuing a discussion, otherwise I see little point as decisions = to >>>>> address the need will be made elsewhere. >>>>>=20 >>>>> Cheers >>>>> James >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_45A53BE9-ECE9-48C6-9D37-9036E461FC1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 29 Jul 2014, at 7:22 am, Rosen, = Brian <Brian.Rosen@neustar.biz> = wrote:

Inline

From: James Winterbottom <a.james.winterbottom@gmail.= com>
Date: Monday, July 28, 2014 at = 4:59 PM
To: Brian Rosen <brian.rosen@neustar.biz> Cc: "ecrit_ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] Discussion = on draft-winterbottom-ecrit-priv-loc-04

inline:

On 29 Jul 2014, at 6:44 am, Rosen, Brian <Brian.Rosen@neustar.biz> = wrote:

Anyone who has access to the document is = welcome to make their own
judgement on what I said.

LbyR in LoST allows the VSP to acquire an endpoint location reference = and
obtain routing information to the correct ESRP.  It does=B9t = require a trust
relationship between the LS and the VSP.
[AJW] Huh??  Which LoST server does = the VSP contact in your scenario? The ANP won=92t have put any record = into the DNS for its domain and even if it did that domain span several = geographic areas LbyR in LoST can=92t recurse or redirect.. BREAK.. The only way that it could work would require the ANP to = establish its own LoST server and simply spit back the records from the = LS anyway. Why is this being made as two queries again?

<br>The VSP contacts any LoST server.  Using recursion or = iteration, it gets to the authoritative one.  If LoST does LbyR, = then the VSP gets an LbyR by querying the LS.  It then queries any = LoST server to get route.
[AJW] FAIL=85 How does the LoST server know = where to go? It only has a location URI and doesn=92t have permission to = dereference it so it can=92t determine where the authoritative = server is using either recursion or redirect. The model is = broken.

 

LoST using LbyR would work just fine with forest guides.  The = forest guide
would have to accept LbyR, but since it uses LoST as its interface, = no
problem if that=B9s the way we decide to do it.
[AJW] This means that any forest = guide anywhere in the world is allowed to get location from any LS = in the world using an LbyR. This has huge security and privacy = implications apart from the fact imposing certain constraints in countries that may well not want or need these = constraints.
The problem with deciding to it that was = is that you will end up in the same position as with rough location = after 2 years of debate, by which time an alternative will have been = found an used.
<br>Spare me the polemics.  Yes, the route infrastructure has = to be trusted.  The LS can return something appropriately rough, = with no standardization, to an FG or a LoST server it doesn=92t = recognize, if it wants to.  Any point in the country, for example. =  Recursion would probably be required if everyone was paranoid about location. =  Note that the VSP can figure out location to a country with the = route URI, no leakage = there.
[AJW] So you are re-advocating rough location? Hmm.. I = though that that option was just dropped. This doesn=92t provide = the same benefits at all of what is in the draft I proposed. The = proposal in the draft only requires the ANP, PSAP or entities inside the = emergency network to have access to location values. Requiring = a global route server network to have access to this is simply = not join to meet the security/privacy requirements in = some countries.




You need an authoritative route server that accepts geo and civic
addresses and returns SIP URIs.  If your interface to that server = isn=B9t
LoST, it has to be something that duplicates it pretty closely.
[AJW] No, we don=92t really need that. = In the US you have highly-structured civic addresses, for most of the = rest of the world they don=92t. In countries like German, ESRP = addresses will be based on who the ANP is, not necessarily the area served by the ANP. In the mobile case, point of attachment is = good enough usually to get to the ESRP, again, I don=92t need = a complex route server, just a table. 
<br>In the US, like most places, you route by cell and sector, but = the way that is mechanized is the cell and sector is turned into some = kind of location =96 a civic or a geo.  The LoST database can be a = simple table if you only have a small range of addresses.  We=92re discussing the protocol, not the complexity of the = data.
[AJW] You conflating the route issue and the location = display issue. I don=92t need to turn the cell-id to location at routing = time, the route was predetermined. I only need a table, this cell-id = maps to this URI. Whether the PSAP gets the cell-id and then converts = that into a area to display, or it gets an area from the GMLC = is immaterial. I only need a table for = routing.

I=92ll = agree that if the VSP has the entire route table for all the = jurisdictions it operates in, then it doesn=92t need LoST for query and = could use something proprietary.  Not sure what will happen in = 3GPP, which is taking that approach.  I think that is a big mistake, but you still need a protocol that is queried with = location and delivers URI.


Routes should not be static.  Things can change, and especially, = in
disaster situations, routes can change with no notice.  The route = you get
at validation may not be the route you get when you query at call = time.
LoST provides a TTL, but its a TTL on the binding, not the = validation.
[AJW] Is this or is this not used by = servers that cache the data and can return a = response?
<br>Yes, but the route server determines the binding TTL.  If = it=92s set for 15 minutes, it can change routes in a disaster situation = reasonably promptly.  As long as the cache is invalidated after the = binding TTL, everything works.  You described a scenario where route was cached at validation.  That=92s fine, as long as = the binding TTL is respected.


Civic addresses validation can change, and the = fact that we don=B9t have a
way to push a change from the validation server back to the entity = that
validated is a problem.  -planned-changes addresses that.  Of = course, you
are only discussing civic addresses (geos don=B9t get validated), so = using
the validation query to obtain route doesn=B9t work with geos.
[AJW] The route is no more static = in the proposal I have made than it would using forest guides or ached = data sets.
<br>If you accept the binding time as the validation period, okay, = but I don=92t think that is what you = meant.

[AJW] You are right, I didn=92t. But in most cases the = kind of catastrophe you describe can and will be done using a = different approach.



None of this changes anything.  LoST LbyR is as least as good of = a
solution as HELD-returns-route.  HELD-returns-route has to have the = TTL,
the boundary, and the other LoST return things to be useful.

[AJW] See above, I have still not heard = from anyone how the will work despite having asked a number of = times.
<= div>
[AJW] Question still = answered, I provided the failure in LbyR for LoST and it has not been = addressed.


Brian

On 7/28/14, 4:27 PM, "James Winterbottom" <a.james.winterbottom@gmail.= com>
wrote:

I totally disagree with your opening statement = Brian.

The IETF approach allows a VSP to acquire the endpoint location and
obtain routing information to the correct ESRP. This option allows
exactly this, but it adds the advantages or being a single query AND
allowing not requiring a trust relationship between the LS and the = VSP.
If anything it enhances the security of the ECRIT proposal.

LoST with LbyR is not going to meet the European needs, and on top = of
this LoST using LbyR breaks the moment you introduce forest guides = or
don=B9t have the authoritative server at the get-go. Which, you = won=B9t.
Please don=B9t try and push this solution, it won=B9t address what is = needed
and any work done will go the way of rough location. There really is = not
time for a 5 year debate on this topic only for the IETF to come = around
in the end like other protocol suggestions that I won=B9t name!

Let=B9s be clear about a LIS holding civic address record EVEN in a
LoST-based environment. If, the LIS is required to validate records = then,
if it ued LoST to do this it has EXACTLY and same informant that any
public LoST server would have, including the expiry times for the
bindings. Quite simply it has everything you need. What possible
conceivable benefits are there is forcing a to query approach except = that
you want to delay the call from getting through or want to divulge
location values to entities that may not be entitled to see them?

This debate should have happened 2 years ago. LbyR for LoST simply
doesn=B9t work.

Cheers
James





On 28 Jul 2014, at 11:19 pm, Rosen, Brian <Brian.Rosen@neustar.biz> = wrote:

The milestone you are referring to is a = document so far from the IETF
approach on emergency calls that I fail to see the benefit of = getting
one protocol, HELD, used by the group pushing this architecture.

I am convinced we will need to support an environment where it is = not
acceptable to have the end device in the path for location.  The = level
of paranoia about that is so high, if we want to make progress in = the
countries where it exists, we need to do something.  In some of = these
environments, it=B9s unacceptable to have the CSP get location. =  Using
HELD with some non-IP identifier to get location by reference works
okay.  What is needed is a way for routing to work.  This can = be done in
two ways.  One is allowing HELD to return route, which is how this = doc
does it.  The other is to allow LoST to do LbyR.  I prefer the = latter,
but would be willing to go along with the HELD mechanism if = consensus
was to do it that way.  Please don=B9t use the =B3one less query=B2 = argument.
It just moves the route query from the CSP to the LIS.

Brian

On Jul 24, 2014, at 7:02 PM, James Winterbottom
<a.james.winterbottom@gmail.= com> wrote:

Hi All,

This is a bit of rant, for which I am only partially apologetic
because Laura and I first presented the need for this draft more = than
years ago when there was time for a debate. I think that that time = has
largely passed now. I sent emails to the list at the end of May and = the
start of June asking for feedback on this draft and again stated why = it
was needed and got next to zero response back.

= http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html
= http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html

The specification that is dependent on a solution to this problem = has
a milestone set for end of 1H15.
There simply isn=B9t time to have a 3 month mailing list debate on = this
topic and then =B3maybe=B2 have something that can be adopted in the
nov/dec timeframe.
If this topic can move =B3very quickly=B2 then I see some benefit in
continuing a discussion, otherwise I see little point as decisions = to
address the need will be made elsewhere.

Cheers
James



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

= --Apple-Mail=_45A53BE9-ECE9-48C6-9D37-9036E461FC1F-- From nobody Mon Jul 28 14:39:52 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD3F1B280C for ; Mon, 28 Jul 2014 14:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRaVPLJ4f0lJ for ; Mon, 28 Jul 2014 14:39:47 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376241A0336 for ; Mon, 28 Jul 2014 14:39:47 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rd3so11203098pab.14 for ; Mon, 28 Jul 2014 14:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/YSxdbHFU/5DhTZqNjpow8itTVrSiu6aG9lZzxGQ6V8=; b=hvKn+LatYmLeK6Tf77MaTJ3tB3Rmv1pjiwMt3L8/YqdPgdlCD+57vP3x/dS7B56Zf7 UZV3s7+0UINbF6Qp9IXOr1+BGPa7v3lFXoeGpC5535WGF+m/rhaEIjtfSqjmPn1aLPby EJKZWKY4uyVIwr2UpKvxJ8Xs/xA3LpIPO1IqVz6VPJd7R4msnMm1KE/01nH96nErm9fM 7ggw0CwiULZwplt2ZysUe2nPM77LwJb4Od/RV/MqCgtB+o+6xBThNQiU5Jta05StHMO4 97kSZaG6FORQKvqj2XI4wb4sYiXuJpXHedIDWL527ZUkADgVWY0G9IVFoipIhVVg0fIv /uGw== X-Received: by 10.68.201.134 with SMTP id ka6mr5522732pbc.157.1406583586686; Mon, 28 Jul 2014 14:39:46 -0700 (PDT) Received: from [192.168.1.10] (124-168-198-48.dyn.iinet.net.au. [124.168.198.48]) by mx.google.com with ESMTPSA id pc10sm11986738pdb.1.2014.07.28.14.39.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 14:39:45 -0700 (PDT) Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: Date: Tue, 29 Jul 2014 07:39:43 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> To: "Marc Linsner (mlinsner)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/hllosF-PMMRvUCtx_LH-p6mt5hs Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:39:49 -0000 I don=A1=AFt think that I said it had to come form the ANP, I think I = said that it can. When it can, why do two queries? Cheers James On 29 Jul 2014, at 7:30 am, Marc Linsner (mlinsner) = wrote: > James, >=20 > In the ECRIT architecture, location does not have to come from the = ANP, > the end-device can supply location to it=A1=AFs VSP. >=20 > -----Original Message----- > From: James Winterbottom > Date: Monday, July 28, 2014 at 5:04 PM > To: Marc Linsner > Cc: "ecrit_ietf.org" > Subject: Re: [Ecrit] Discussion on = draft-winterbottom-ecrit-priv-loc-04 >=20 >> Hi Marc, >>=20 >> The IETF architecture already quasi-requires them to do this. >> They need to put a UNAPTR record for their domain into the DNS to = enable >> LoST to work for their domain. >=20 > I don=A1=AFt understand, LbyR points to the LS, what is UNAPTR for? >=20 >=20 >> They need to ensure that civic address information will work with the >> LoST server so that the call gets to the right ESRP. >>=20 >> These are quasi-routing requirements placed on the ANP. >=20 > No, if the ANP is providing location, it needs to provide the data in = a > form adhering to local standards. I don=A1=AFt consider that call = routing. >=20 >=20 >>=20 >> If you introduce LbyR to LoST then you now require them to have a = LoST >> server interface too. >=20 > No, dereferencing LbyR doesn=A1=AFt require LoST. >=20 >>=20 >> So quite honestly, I think it is a real stretch to say that we don=A1=AF= t >> place routing requirements on ANPs today. >>=20 >> Cheers >> James >>=20 >>=20 >>=20 >> On 29 Jul 2014, at 6:58 am, Marc Linsner (mlinsner) = >> wrote: >>=20 >>> James, >>>=20 >>> (with wg chair hat off) >>>=20 >>> The IETF ECRIT architecture is designed to provide a clean approach = to >>> enabling emergency calls in the multi-layered Internet, by allowing = the >>> service provider of each layer to perform functions reasonably = adaptable >>> to their discipline. Forcing a L2/L3 provider to be responsible for >>> emergency call routing is a "layer violation" that we normally = don=A9=F6t go >>> out of our way to support. >>>=20 >>> Reverse-engineering requirements to the benefit of a non-layered >>> solution >>> will be temporary at best. >>>=20 >>> -Marc- >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: James Winterbottom >>> Date: Monday, July 28, 2014 at 4:27 PM >>> To: "Rosen, Brian" >>> Cc: "ecrit_ietf.org" >>> Subject: Re: [Ecrit] Discussion on = draft-winterbottom-ecrit-priv-loc-04 >>>=20 >>>> I totally disagree with your opening statement Brian. >>>>=20 >>>> The IETF approach allows a VSP to acquire the endpoint location and >>>> obtain routing information to the correct ESRP. This option allows >>>> exactly this, but it adds the advantages or being a single query = AND >>>> allowing not requiring a trust relationship between the LS and the = VSP. >>>> If anything it enhances the security of the ECRIT proposal. >>>>=20 >>>> LoST with LbyR is not going to meet the European needs, and on top = of >>>> this LoST using LbyR breaks the moment you introduce forest guides = or >>>> don=A9=F6t have the authoritative server at the get-go. Which, you = won=A9=F6t. >>>> Please don=A9=F6t try and push this solution, it won=A9=F6t address = what is >>>> needed >>>> and any work done will go the way of rough location. There really = is >>>> not >>>> time for a 5 year debate on this topic only for the IETF to come = around >>>> in the end like other protocol suggestions that I won=A9=F6t name! >>>>=20 >>>> Let=A9=F6s be clear about a LIS holding civic address record EVEN = in a >>>> LoST-based environment. If, the LIS is required to validate records >>>> then, >>>> if it ued LoST to do this it has EXACTLY and same informant that = any >>>> public LoST server would have, including the expiry times for the >>>> bindings. Quite simply it has everything you need. What possible >>>> conceivable benefits are there is forcing a to query approach = except >>>> that >>>> you want to delay the call from getting through or want to divulge >>>> location values to entities that may not be entitled to see them? >>>>=20 >>>> This debate should have happened 2 years ago. LbyR for LoST simply >>>> doesn=A9=F6t work.=20 >>>>=20 >>>> Cheers >>>> James >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 28 Jul 2014, at 11:19 pm, Rosen, Brian >>>> wrote: >>>>=20 >>>>> The milestone you are referring to is a document so far from the = IETF >>>>> approach on emergency calls that I fail to see the benefit of = getting >>>>> one protocol, HELD, used by the group pushing this architecture. >>>>>=20 >>>>> I am convinced we will need to support an environment where it is = not >>>>> acceptable to have the end device in the path for location. The = level >>>>> of paranoia about that is so high, if we want to make progress in = the >>>>> countries where it exists, we need to do something. In some of = these >>>>> environments, it=A9=F6s unacceptable to have the CSP get location. = Using >>>>> HELD with some non-IP identifier to get location by reference = works >>>>> okay. What is needed is a way for routing to work. This can be = done >>>>> in >>>>> two ways. One is allowing HELD to return route, which is how this = doc >>>>> does it. The other is to allow LoST to do LbyR. I prefer the = latter, >>>>> but would be willing to go along with the HELD mechanism if = consensus >>>>> was to do it that way. Please don=A9=F6t use the =A9=F8one less = query=A9=F7 >>>>> argument. >>>>> It just moves the route query from the CSP to the LIS. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Jul 24, 2014, at 7:02 PM, James Winterbottom >>>>> wrote: >>>>>=20 >>>>>> Hi All, >>>>>>=20 >>>>>> This is a bit of rant, for which I am only partially apologetic >>>>>> because Laura and I first presented the need for this draft more = than >>>>>> years ago when there was time for a debate. I think that that = time >>>>>> has >>>>>> largely passed now. I sent emails to the list at the end of May = and >>>>>> the >>>>>> start of June asking for feedback on this draft and again stated = why >>>>>> it >>>>>> was needed and got next to zero response back. >>>>>>=20 >>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html >>>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html >>>>>>=20 >>>>>> The specification that is dependent on a solution to this problem = has >>>>>> a milestone set for end of 1H15. >>>>>> There simply isn=A9=F6t time to have a 3 month mailing list = debate on this >>>>>> topic and then =A9=F8maybe=A9=F7 have something that can be = adopted in the >>>>>> nov/dec timeframe. >>>>>> If this topic can move =A9=F8very quickly=A9=F7 then I see some = benefit in >>>>>> continuing a discussion, otherwise I see little point as = decisions to >>>>>> address the need will be made elsewhere. >>>>>>=20 >>>>>> Cheers >>>>>> James >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >=20 From nobody Mon Jul 28 14:49:40 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2331A0262 for ; Mon, 28 Jul 2014 14:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZ3kndWQpR5P for ; Mon, 28 Jul 2014 14:49:35 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A11C1A0252 for ; Mon, 28 Jul 2014 14:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11228; q=dns/txt; s=iport; t=1406584176; x=1407793776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fJ7gok6sF4Dp5yn1jrWEC76v3ymcx2me50I2vyyjO7Q=; b=j84AtNeLZsomY1HgWjXaa92N2kYN3t3eYu3Kh8lkZvaMx0L/ZbOxfsWp CuM4u0prsZ9dKN0vuAM4R7rvnebWP+p5XeW2Ix2kddRMnsBFfrW4gBPkT TdcWAFyBvCytbYZB0X4MtmdnHNEp4h0SYm1u2+xg9Cj+f+ijj7HlexAtr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FADXF1lOtJA2G/2dsb2JhbABZgw5SVwSCdMkNCodFARl5FneEAwEBAQQBAQExFSUEBwwEAgEIDgMBAgECAQQoAgIfBgsXBggCBA4FCRIEiA8DEQ2KXZwoBpASDYcTF4EmiFmDIIFcAQEkKwcCAgKCbYFXBZlHggWMH4IKhiODSWwBgQICBxcEAhw X-IronPort-AV: E=Sophos;i="5.01,751,1400025600"; d="scan'208";a="64698999" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 28 Jul 2014 21:49:32 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6SLnVZt021240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 21:49:31 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 16:49:30 -0500 From: "Marc Linsner (mlinsner)" To: James Winterbottom Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPp5Nv4tqyEK5JTUai44qlt9Y0P5u10emAgAB3lgD//8WEgIAARKaA///ETYCAAEWXgP//v6sA Date: Mon, 28 Jul 2014 21:49:30 +0000 Message-ID: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.98] Content-Type: text/plain; charset="euc-kr" Content-ID: <0717D0CAE9D435429BB220B8AF3258B5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/DVqEvftLKggzbr5vNdt7XitpG0s Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:49:38 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKYW1lcyBXaW50ZXJib3R0b20g PGEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbT4NCkRhdGU6IE1vbmRheSwgSnVseSAyOCwg MjAxNCBhdCA1OjM5IFBNDQpUbzogTWFyYyBMaW5zbmVyIDxtbGluc25lckBjaXNjby5jb20+DQpD YzogImVjcml0X2lldGYub3JnIiA8ZWNyaXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Vjcml0 XSBEaXNjdXNzaW9uIG9uIGRyYWZ0LXdpbnRlcmJvdHRvbS1lY3JpdC1wcml2LWxvYy0wNA0KDQo+ SSBkb26hr3QgdGhpbmsgdGhhdCBJIHNhaWQgaXQgaGFkIHRvIGNvbWUgZm9ybSB0aGUgQU5QLCBJ IHRoaW5rIEkgc2FpZA0KPnRoYXQgaXQgY2FuLg0KPldoZW4gaXQgY2FuLCB3aHkgZG8gdHdvIHF1 ZXJpZXM/DQoNCg0KRm9yIHRoZSBzYW1lIHJlYXNvbiBhIEROUyBxdWVyeSBmb3Igd3d3LmZvby5i YXIgZG9lc26hr3QgYXV0b21hZ2ljYWxseSBnaXZlDQp5b3UgZm9vYmFyJ3Mgd2VicGFnZS4gIFR3 byBmdW5jdGlvbnMsIHR3byBkaWZmZXJlbnQgcmVzcG9uc2liaWxpdGllcy4NCg0KLU1hcmMtDQoN Cg0KDQoNCj4NCj5DaGVlcnMNCj5KYW1lcw0KPg0KPk9uIDI5IEp1bCAyMDE0LCBhdCA3OjMwIGFt LCBNYXJjIExpbnNuZXIgKG1saW5zbmVyKSA8bWxpbnNuZXJAY2lzY28uY29tPg0KPndyb3RlOg0K Pg0KPj4gSmFtZXMsDQo+PiANCj4+IEluIHRoZSBFQ1JJVCBhcmNoaXRlY3R1cmUsIGxvY2F0aW9u IGRvZXMgbm90IGhhdmUgdG8gY29tZSBmcm9tIHRoZSBBTlAsDQo+PiB0aGUgZW5kLWRldmljZSBj YW4gc3VwcGx5IGxvY2F0aW9uIHRvIGl0oa9zIFZTUC4NCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+IEZyb206IEphbWVzIFdpbnRlcmJvdHRvbSA8YS5qYW1lcy53aW50ZXJi b3R0b21AZ21haWwuY29tPg0KPj4gRGF0ZTogTW9uZGF5LCBKdWx5IDI4LCAyMDE0IGF0IDU6MDQg UE0NCj4+IFRvOiBNYXJjIExpbnNuZXIgPG1saW5zbmVyQGNpc2NvLmNvbT4NCj4+IENjOiAiZWNy aXRfaWV0Zi5vcmciIDxlY3JpdEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIERp c2N1c3Npb24gb24gZHJhZnQtd2ludGVyYm90dG9tLWVjcml0LXByaXYtbG9jLTA0DQo+PiANCj4+ PiBIaSBNYXJjLA0KPj4+IA0KPj4+IFRoZSBJRVRGIGFyY2hpdGVjdHVyZSBhbHJlYWR5IHF1YXNp LXJlcXVpcmVzIHRoZW0gdG8gZG8gdGhpcy4NCj4+PiBUaGV5IG5lZWQgdG8gcHV0IGEgVU5BUFRS IHJlY29yZCBmb3IgdGhlaXIgZG9tYWluIGludG8gdGhlIEROUyB0bw0KPj4+ZW5hYmxlDQo+Pj4g TG9TVCB0byB3b3JrIGZvciB0aGVpciBkb21haW4uDQo+PiANCj4+IEkgZG9uoa90IHVuZGVyc3Rh bmQsIExieVIgcG9pbnRzIHRvIHRoZSBMUywgd2hhdCBpcyBVTkFQVFIgZm9yPw0KPj4gDQo+PiAN Cj4+PiBUaGV5IG5lZWQgdG8gZW5zdXJlIHRoYXQgY2l2aWMgYWRkcmVzcyBpbmZvcm1hdGlvbiB3 aWxsIHdvcmsgd2l0aCB0aGUNCj4+PiBMb1NUIHNlcnZlciBzbyB0aGF0IHRoZSBjYWxsIGdldHMg dG8gdGhlIHJpZ2h0IEVTUlAuDQo+Pj4gDQo+Pj4gVGhlc2UgYXJlIHF1YXNpLXJvdXRpbmcgcmVx dWlyZW1lbnRzIHBsYWNlZCBvbiB0aGUgQU5QLg0KPj4gDQo+PiBObywgaWYgdGhlIEFOUCBpcyBw cm92aWRpbmcgbG9jYXRpb24sIGl0IG5lZWRzIHRvIHByb3ZpZGUgdGhlIGRhdGEgaW4gYQ0KPj4g Zm9ybSBhZGhlcmluZyB0byBsb2NhbCBzdGFuZGFyZHMuICBJIGRvbqGvdCBjb25zaWRlciB0aGF0 IGNhbGwgcm91dGluZy4NCj4+IA0KPj4gDQo+Pj4gDQo+Pj4gSWYgeW91IGludHJvZHVjZSBMYnlS IHRvIExvU1QgdGhlbiB5b3Ugbm93IHJlcXVpcmUgdGhlbSB0byBoYXZlIGEgTG9TVA0KPj4+IHNl cnZlciBpbnRlcmZhY2UgdG9vLg0KPj4gDQo+PiBObywgZGVyZWZlcmVuY2luZyBMYnlSIGRvZXNu oa90IHJlcXVpcmUgTG9TVC4NCj4+IA0KPj4+IA0KPj4+IFNvIHF1aXRlIGhvbmVzdGx5LCBJIHRo aW5rIGl0IGlzIGEgcmVhbCBzdHJldGNoIHRvIHNheSB0aGF0IHdlIGRvbqGvdA0KPj4+IHBsYWNl IHJvdXRpbmcgcmVxdWlyZW1lbnRzIG9uIEFOUHMgdG9kYXkuDQo+Pj4gDQo+Pj4gQ2hlZXJzDQo+ Pj4gSmFtZXMNCj4+PiANCj4+PiANCj4+PiANCj4+PiBPbiAyOSBKdWwgMjAxNCwgYXQgNjo1OCBh bSwgTWFyYyBMaW5zbmVyIChtbGluc25lcikNCj4+PjxtbGluc25lckBjaXNjby5jb20+DQo+Pj4g d3JvdGU6DQo+Pj4gDQo+Pj4+IEphbWVzLA0KPj4+PiANCj4+Pj4gKHdpdGggd2cgY2hhaXIgaGF0 IG9mZikNCj4+Pj4gDQo+Pj4+IFRoZSBJRVRGIEVDUklUIGFyY2hpdGVjdHVyZSBpcyBkZXNpZ25l ZCB0byBwcm92aWRlIGEgY2xlYW4gYXBwcm9hY2ggdG8NCj4+Pj4gZW5hYmxpbmcgZW1lcmdlbmN5 IGNhbGxzIGluIHRoZSBtdWx0aS1sYXllcmVkIEludGVybmV0LCBieSBhbGxvd2luZw0KPj4+PnRo ZQ0KPj4+PiBzZXJ2aWNlIHByb3ZpZGVyIG9mIGVhY2ggbGF5ZXIgdG8gcGVyZm9ybSBmdW5jdGlv bnMgcmVhc29uYWJseQ0KPj4+PmFkYXB0YWJsZQ0KPj4+PiB0byB0aGVpciBkaXNjaXBsaW5lLiAg Rm9yY2luZyBhIEwyL0wzIHByb3ZpZGVyIHRvIGJlIHJlc3BvbnNpYmxlIGZvcg0KPj4+PiBlbWVy Z2VuY3kgY2FsbCByb3V0aW5nIGlzIGEgImxheWVyIHZpb2xhdGlvbiIgdGhhdCB3ZSBub3JtYWxs eSBkb26p9nQNCj4+Pj5nbw0KPj4+PiBvdXQgb2Ygb3VyIHdheSB0byBzdXBwb3J0Lg0KPj4+PiAN Cj4+Pj4gUmV2ZXJzZS1lbmdpbmVlcmluZyByZXF1aXJlbWVudHMgdG8gdGhlIGJlbmVmaXQgb2Yg YSBub24tbGF5ZXJlZA0KPj4+PiBzb2x1dGlvbg0KPj4+PiB3aWxsIGJlIHRlbXBvcmFyeSBhdCBi ZXN0Lg0KPj4+PiANCj4+Pj4gLU1hcmMtDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogSmFtZXMgV2lu dGVyYm90dG9tIDxhLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20+DQo+Pj4+IERhdGU6IE1v bmRheSwgSnVseSAyOCwgMjAxNCBhdCA0OjI3IFBNDQo+Pj4+IFRvOiAiUm9zZW4sIEJyaWFuIiA8 QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+DQo+Pj4+IENjOiAiZWNyaXRfaWV0Zi5vcmciIDxlY3Jp dEBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFtFY3JpdF0gRGlzY3Vzc2lvbiBvbg0KPj4+ PmRyYWZ0LXdpbnRlcmJvdHRvbS1lY3JpdC1wcml2LWxvYy0wNA0KPj4+PiANCj4+Pj4+IEkgdG90 YWxseSBkaXNhZ3JlZSB3aXRoIHlvdXIgb3BlbmluZyBzdGF0ZW1lbnQgQnJpYW4uDQo+Pj4+PiAN Cj4+Pj4+IFRoZSBJRVRGIGFwcHJvYWNoIGFsbG93cyBhIFZTUCB0byBhY3F1aXJlIHRoZSBlbmRw b2ludCBsb2NhdGlvbiBhbmQNCj4+Pj4+IG9idGFpbiByb3V0aW5nIGluZm9ybWF0aW9uIHRvIHRo ZSBjb3JyZWN0IEVTUlAuIFRoaXMgb3B0aW9uIGFsbG93cw0KPj4+Pj4gZXhhY3RseSB0aGlzLCBi dXQgaXQgYWRkcyB0aGUgYWR2YW50YWdlcyBvciBiZWluZyBhIHNpbmdsZSBxdWVyeSBBTkQNCj4+ Pj4+IGFsbG93aW5nIG5vdCByZXF1aXJpbmcgYSB0cnVzdCByZWxhdGlvbnNoaXAgYmV0d2VlbiB0 aGUgTFMgYW5kIHRoZQ0KPj4+Pj5WU1AuDQo+Pj4+PiBJZiBhbnl0aGluZyBpdCBlbmhhbmNlcyB0 aGUgc2VjdXJpdHkgb2YgdGhlIEVDUklUIHByb3Bvc2FsLg0KPj4+Pj4gDQo+Pj4+PiBMb1NUIHdp dGggTGJ5UiBpcyBub3QgZ29pbmcgdG8gbWVldCB0aGUgRXVyb3BlYW4gbmVlZHMsIGFuZCBvbiB0 b3Agb2YNCj4+Pj4+IHRoaXMgTG9TVCB1c2luZyBMYnlSIGJyZWFrcyB0aGUgbW9tZW50IHlvdSBp bnRyb2R1Y2UgZm9yZXN0IGd1aWRlcyBvcg0KPj4+Pj4gZG9uqfZ0IGhhdmUgdGhlIGF1dGhvcml0 YXRpdmUgc2VydmVyIGF0IHRoZSBnZXQtZ28uIFdoaWNoLCB5b3Ugd29uqfZ0Lg0KPj4+Pj4gUGxl YXNlIGRvbqn2dCB0cnkgYW5kIHB1c2ggdGhpcyBzb2x1dGlvbiwgaXQgd29uqfZ0IGFkZHJlc3Mg d2hhdCBpcw0KPj4+Pj4gbmVlZGVkDQo+Pj4+PiBhbmQgYW55IHdvcmsgZG9uZSB3aWxsIGdvIHRo ZSB3YXkgb2Ygcm91Z2ggbG9jYXRpb24uIFRoZXJlIHJlYWxseSBpcw0KPj4+Pj4gbm90DQo+Pj4+ PiB0aW1lIGZvciBhIDUgeWVhciBkZWJhdGUgb24gdGhpcyB0b3BpYyBvbmx5IGZvciB0aGUgSUVU RiB0byBjb21lDQo+Pj4+PmFyb3VuZA0KPj4+Pj4gaW4gdGhlIGVuZCBsaWtlIG90aGVyIHByb3Rv Y29sIHN1Z2dlc3Rpb25zIHRoYXQgSSB3b26p9nQgbmFtZSENCj4+Pj4+IA0KPj4+Pj4gTGV0qfZz IGJlIGNsZWFyIGFib3V0IGEgTElTIGhvbGRpbmcgY2l2aWMgYWRkcmVzcyByZWNvcmQgRVZFTiBp biBhDQo+Pj4+PiBMb1NULWJhc2VkIGVudmlyb25tZW50LiBJZiwgdGhlIExJUyBpcyByZXF1aXJl ZCB0byB2YWxpZGF0ZSByZWNvcmRzDQo+Pj4+PiB0aGVuLA0KPj4+Pj4gaWYgaXQgdWVkIExvU1Qg dG8gZG8gdGhpcyBpdCBoYXMgRVhBQ1RMWSBhbmQgc2FtZSBpbmZvcm1hbnQgdGhhdCBhbnkNCj4+ Pj4+IHB1YmxpYyBMb1NUIHNlcnZlciB3b3VsZCBoYXZlLCBpbmNsdWRpbmcgdGhlIGV4cGlyeSB0 aW1lcyBmb3IgdGhlDQo+Pj4+PiBiaW5kaW5ncy4gUXVpdGUgc2ltcGx5IGl0IGhhcyBldmVyeXRo aW5nIHlvdSBuZWVkLiBXaGF0IHBvc3NpYmxlDQo+Pj4+PiBjb25jZWl2YWJsZSBiZW5lZml0cyBh cmUgdGhlcmUgaXMgZm9yY2luZyBhIHRvIHF1ZXJ5IGFwcHJvYWNoIGV4Y2VwdA0KPj4+Pj4gdGhh dA0KPj4+Pj4geW91IHdhbnQgdG8gZGVsYXkgdGhlIGNhbGwgZnJvbSBnZXR0aW5nIHRocm91Z2gg b3Igd2FudCB0byBkaXZ1bGdlDQo+Pj4+PiBsb2NhdGlvbiB2YWx1ZXMgdG8gZW50aXRpZXMgdGhh dCBtYXkgbm90IGJlIGVudGl0bGVkIHRvIHNlZSB0aGVtPw0KPj4+Pj4gDQo+Pj4+PiBUaGlzIGRl YmF0ZSBzaG91bGQgaGF2ZSBoYXBwZW5lZCAyIHllYXJzIGFnby4gTGJ5UiBmb3IgTG9TVCBzaW1w bHkNCj4+Pj4+IGRvZXNuqfZ0IHdvcmsuDQo+Pj4+PiANCj4+Pj4+IENoZWVycw0KPj4+Pj4gSmFt ZXMNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBPbiAyOCBK dWwgMjAxNCwgYXQgMTE6MTkgcG0sIFJvc2VuLCBCcmlhbiA8QnJpYW4uUm9zZW5AbmV1c3Rhci5i aXo+DQo+Pj4+PiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IFRoZSBtaWxlc3RvbmUgeW91IGFyZSBy ZWZlcnJpbmcgdG8gaXMgYSBkb2N1bWVudCBzbyBmYXIgZnJvbSB0aGUNCj4+Pj4+PklFVEYNCj4+ Pj4+PiBhcHByb2FjaCBvbiBlbWVyZ2VuY3kgY2FsbHMgdGhhdCBJIGZhaWwgdG8gc2VlIHRoZSBi ZW5lZml0IG9mDQo+Pj4+Pj5nZXR0aW5nDQo+Pj4+Pj4gb25lIHByb3RvY29sLCBIRUxELCB1c2Vk IGJ5IHRoZSBncm91cCBwdXNoaW5nIHRoaXMgYXJjaGl0ZWN0dXJlLg0KPj4+Pj4+IA0KPj4+Pj4+ IEkgYW0gY29udmluY2VkIHdlIHdpbGwgbmVlZCB0byBzdXBwb3J0IGFuIGVudmlyb25tZW50IHdo ZXJlIGl0IGlzDQo+Pj4+Pj5ub3QNCj4+Pj4+PiBhY2NlcHRhYmxlIHRvIGhhdmUgdGhlIGVuZCBk ZXZpY2UgaW4gdGhlIHBhdGggZm9yIGxvY2F0aW9uLiAgVGhlDQo+Pj4+Pj5sZXZlbA0KPj4+Pj4+ IG9mIHBhcmFub2lhIGFib3V0IHRoYXQgaXMgc28gaGlnaCwgaWYgd2Ugd2FudCB0byBtYWtlIHBy b2dyZXNzIGluDQo+Pj4+Pj50aGUNCj4+Pj4+PiBjb3VudHJpZXMgd2hlcmUgaXQgZXhpc3RzLCB3 ZSBuZWVkIHRvIGRvIHNvbWV0aGluZy4gIEluIHNvbWUgb2YNCj4+Pj4+PnRoZXNlDQo+Pj4+Pj4g ZW52aXJvbm1lbnRzLCBpdKn2cyB1bmFjY2VwdGFibGUgdG8gaGF2ZSB0aGUgQ1NQIGdldCBsb2Nh dGlvbi4gIFVzaW5nDQo+Pj4+Pj4gSEVMRCB3aXRoIHNvbWUgbm9uLUlQIGlkZW50aWZpZXIgdG8g Z2V0IGxvY2F0aW9uIGJ5IHJlZmVyZW5jZSB3b3Jrcw0KPj4+Pj4+IG9rYXkuICBXaGF0IGlzIG5l ZWRlZCBpcyBhIHdheSBmb3Igcm91dGluZyB0byB3b3JrLiAgVGhpcyBjYW4gYmUNCj4+Pj4+PmRv bmUNCj4+Pj4+PiBpbg0KPj4+Pj4+IHR3byB3YXlzLiAgT25lIGlzIGFsbG93aW5nIEhFTEQgdG8g cmV0dXJuIHJvdXRlLCB3aGljaCBpcyBob3cgdGhpcw0KPj4+Pj4+ZG9jDQo+Pj4+Pj4gZG9lcyBp dC4gIFRoZSBvdGhlciBpcyB0byBhbGxvdyBMb1NUIHRvIGRvIExieVIuICBJIHByZWZlciB0aGUN Cj4+Pj4+PmxhdHRlciwNCj4+Pj4+PiBidXQgd291bGQgYmUgd2lsbGluZyB0byBnbyBhbG9uZyB3 aXRoIHRoZSBIRUxEIG1lY2hhbmlzbSBpZg0KPj4+Pj4+Y29uc2Vuc3VzDQo+Pj4+Pj4gd2FzIHRv IGRvIGl0IHRoYXQgd2F5LiAgUGxlYXNlIGRvbqn2dCB1c2UgdGhlIKn4b25lIGxlc3MgcXVlcnmp 9w0KPj4+Pj4+IGFyZ3VtZW50Lg0KPj4+Pj4+IEl0IGp1c3QgbW92ZXMgdGhlIHJvdXRlIHF1ZXJ5 IGZyb20gdGhlIENTUCB0byB0aGUgTElTLg0KPj4+Pj4+IA0KPj4+Pj4+IEJyaWFuDQo+Pj4+Pj4g DQo+Pj4+Pj4gT24gSnVsIDI0LCAyMDE0LCBhdCA3OjAyIFBNLCBKYW1lcyBXaW50ZXJib3R0b20N Cj4+Pj4+PiA8YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPiB3cm90ZToNCj4+Pj4+PiAN Cj4+Pj4+Pj4gSGkgQWxsLA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhpcyBpcyBhIGJpdCBvZiByYW50 LCBmb3Igd2hpY2ggSSBhbSBvbmx5IHBhcnRpYWxseSBhcG9sb2dldGljDQo+Pj4+Pj4+IGJlY2F1 c2UgTGF1cmEgYW5kIEkgZmlyc3QgcHJlc2VudGVkIHRoZSBuZWVkIGZvciB0aGlzIGRyYWZ0IG1v cmUNCj4+Pj4+Pj50aGFuDQo+Pj4+Pj4+IHllYXJzIGFnbyB3aGVuIHRoZXJlIHdhcyB0aW1lIGZv ciBhIGRlYmF0ZS4gSSB0aGluayB0aGF0IHRoYXQgdGltZQ0KPj4+Pj4+PiBoYXMNCj4+Pj4+Pj4g bGFyZ2VseSBwYXNzZWQgbm93LiBJIHNlbnQgZW1haWxzIHRvIHRoZSBsaXN0IGF0IHRoZSBlbmQg b2YgTWF5IGFuZA0KPj4+Pj4+PiB0aGUNCj4+Pj4+Pj4gc3RhcnQgb2YgSnVuZSBhc2tpbmcgZm9y IGZlZWRiYWNrIG9uIHRoaXMgZHJhZnQgYW5kIGFnYWluIHN0YXRlZA0KPj4+Pj4+PndoeQ0KPj4+ Pj4+PiBpdA0KPj4+Pj4+PiB3YXMgbmVlZGVkIGFuZCBnb3QgbmV4dCB0byB6ZXJvIHJlc3BvbnNl IGJhY2suDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvZWNyaXQvY3VycmVudC9tc2cwODgyMy5odG1sDQo+Pj4+Pj4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9lY3JpdC9jdXJyZW50L21zZzA4ODI3Lmh0bWwNCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IFRoZSBzcGVjaWZpY2F0aW9uIHRoYXQgaXMgZGVwZW5kZW50IG9uIGEgc29s dXRpb24gdG8gdGhpcyBwcm9ibGVtDQo+Pj4+Pj4+aGFzDQo+Pj4+Pj4+IGEgbWlsZXN0b25lIHNl dCBmb3IgZW5kIG9mIDFIMTUuDQo+Pj4+Pj4+IFRoZXJlIHNpbXBseSBpc26p9nQgdGltZSB0byBo YXZlIGEgMyBtb250aCBtYWlsaW5nIGxpc3QgZGViYXRlIG9uDQo+Pj4+Pj4+dGhpcw0KPj4+Pj4+ PiB0b3BpYyBhbmQgdGhlbiCp+G1heWJlqfcgaGF2ZSBzb21ldGhpbmcgdGhhdCBjYW4gYmUgYWRv cHRlZCBpbiB0aGUNCj4+Pj4+Pj4gbm92L2RlYyB0aW1lZnJhbWUuDQo+Pj4+Pj4+IElmIHRoaXMg dG9waWMgY2FuIG1vdmUgqfh2ZXJ5IHF1aWNrbHmp9yB0aGVuIEkgc2VlIHNvbWUgYmVuZWZpdCBp bg0KPj4+Pj4+PiBjb250aW51aW5nIGEgZGlzY3Vzc2lvbiwgb3RoZXJ3aXNlIEkgc2VlIGxpdHRs ZSBwb2ludCBhcyBkZWNpc2lvbnMNCj4+Pj4+Pj50bw0KPj4+Pj4+PiBhZGRyZXNzIHRoZSBuZWVk IHdpbGwgYmUgbWFkZSBlbHNld2hlcmUuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBDaGVlcnMNCj4+Pj4+ Pj4gSmFtZXMNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gRWNyaXQgbWFp bGluZyBsaXN0DQo+Pj4+Pj4+IEVjcml0QGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IEVjcml0 IG1haWxpbmcgbGlzdA0KPj4+Pj4gRWNyaXRAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+Pj4gDQo+Pj4gDQo+PiANCj4NCg0K From nobody Mon Jul 28 14:51:40 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF051A0262 for ; Mon, 28 Jul 2014 14:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3dmGdOtlJxb for ; Mon, 28 Jul 2014 14:51:32 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE741A0252 for ; Mon, 28 Jul 2014 14:51:32 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id et14so11115802pad.23 for ; Mon, 28 Jul 2014 14:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FrJNNeqW2NQaLDRyrM5j0MzGfRq1Gj8DrE5Q+wpFBDw=; b=mFXZUsLKjgiSt2p1mRk0WkhP9hLG4RbyFT3XGHbEbxfWLmRn7I7jBH4tQlT6J7Vvl7 69uaiUw7aJYkjO0Iy0UA9+9oLeKuTzwEs4hY1Z4FnYIOeHz5XUiv7LchhjoKmy4Ih7gE IBxgqbWuBT+8VCRNbLl21xHjEdAADlhyPDnx4X6bbnOrCIm/FFbjN6V97CFGVz6Kmhad IlAGqS+cK7CFF90dlYiYdKknfi/lShR1tHuKXy+VW5VcjBgYjUR0ZLKiNOumvaEWQNiK Qyo3y3uILGpexHPmpra6eZY3ipxjPhbfnQp6djicJ3UBzDoXmDuX2vUI+b2b0vnQCVJP vmpA== X-Received: by 10.70.52.101 with SMTP id s5mr22187918pdo.83.1406584292118; Mon, 28 Jul 2014 14:51:32 -0700 (PDT) Received: from [192.168.1.10] (124-168-198-48.dyn.iinet.net.au. [124.168.198.48]) by mx.google.com with ESMTPSA id ui8sm645958pbc.84.2014.07.28.14.51.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 14:51:31 -0700 (PDT) Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: Date: Tue, 29 Jul 2014 07:51:29 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <69BE9441-72BA-400E-9EB6-38D955A5F0EF@gmail.com> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> To: "Marc Linsner (mlinsner)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/ZFa7K4jkfh52nAyqV4oDPJsBmYU Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:51:35 -0000 Hardly time critical! On 29 Jul 2014, at 7:49 am, Marc Linsner (mlinsner) = wrote: >=20 >=20 > -----Original Message----- > From: James Winterbottom > Date: Monday, July 28, 2014 at 5:39 PM > To: Marc Linsner > Cc: "ecrit_ietf.org" > Subject: Re: [Ecrit] Discussion on = draft-winterbottom-ecrit-priv-loc-04 >=20 >> I don=A1=AFt think that I said it had to come form the ANP, I think I = said >> that it can. >> When it can, why do two queries? >=20 >=20 > For the same reason a DNS query for www.foo.bar doesn=A1=AFt = automagically give > you foobar's webpage. Two functions, two different responsibilities. >=20 > -Marc- >=20 >=20 >=20 >=20 >>=20 >> Cheers >> James >>=20 >> On 29 Jul 2014, at 7:30 am, Marc Linsner (mlinsner) = >> wrote: >>=20 >>> James, >>>=20 >>> In the ECRIT architecture, location does not have to come from the = ANP, >>> the end-device can supply location to it=A1=AFs VSP. >>>=20 >>> -----Original Message----- >>> From: James Winterbottom >>> Date: Monday, July 28, 2014 at 5:04 PM >>> To: Marc Linsner >>> Cc: "ecrit_ietf.org" >>> Subject: Re: [Ecrit] Discussion on = draft-winterbottom-ecrit-priv-loc-04 >>>=20 >>>> Hi Marc, >>>>=20 >>>> The IETF architecture already quasi-requires them to do this. >>>> They need to put a UNAPTR record for their domain into the DNS to >>>> enable >>>> LoST to work for their domain. >>>=20 >>> I don=A1=AFt understand, LbyR points to the LS, what is UNAPTR for? >>>=20 >>>=20 >>>> They need to ensure that civic address information will work with = the >>>> LoST server so that the call gets to the right ESRP. >>>>=20 >>>> These are quasi-routing requirements placed on the ANP. >>>=20 >>> No, if the ANP is providing location, it needs to provide the data = in a >>> form adhering to local standards. I don=A1=AFt consider that call = routing. >>>=20 >>>=20 >>>>=20 >>>> If you introduce LbyR to LoST then you now require them to have a = LoST >>>> server interface too. >>>=20 >>> No, dereferencing LbyR doesn=A1=AFt require LoST. >>>=20 >>>>=20 >>>> So quite honestly, I think it is a real stretch to say that we = don=A1=AFt >>>> place routing requirements on ANPs today. >>>>=20 >>>> Cheers >>>> James >>>>=20 >>>>=20 >>>>=20 >>>> On 29 Jul 2014, at 6:58 am, Marc Linsner (mlinsner) >>>> >>>> wrote: >>>>=20 >>>>> James, >>>>>=20 >>>>> (with wg chair hat off) >>>>>=20 >>>>> The IETF ECRIT architecture is designed to provide a clean = approach to >>>>> enabling emergency calls in the multi-layered Internet, by = allowing >>>>> the >>>>> service provider of each layer to perform functions reasonably >>>>> adaptable >>>>> to their discipline. Forcing a L2/L3 provider to be responsible = for >>>>> emergency call routing is a "layer violation" that we normally = don=A9=F6t >>>>> go >>>>> out of our way to support. >>>>>=20 >>>>> Reverse-engineering requirements to the benefit of a non-layered >>>>> solution >>>>> will be temporary at best. >>>>>=20 >>>>> -Marc- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: James Winterbottom >>>>> Date: Monday, July 28, 2014 at 4:27 PM >>>>> To: "Rosen, Brian" >>>>> Cc: "ecrit_ietf.org" >>>>> Subject: Re: [Ecrit] Discussion on >>>>> draft-winterbottom-ecrit-priv-loc-04 >>>>>=20 >>>>>> I totally disagree with your opening statement Brian. >>>>>>=20 >>>>>> The IETF approach allows a VSP to acquire the endpoint location = and >>>>>> obtain routing information to the correct ESRP. This option = allows >>>>>> exactly this, but it adds the advantages or being a single query = AND >>>>>> allowing not requiring a trust relationship between the LS and = the >>>>>> VSP. >>>>>> If anything it enhances the security of the ECRIT proposal. >>>>>>=20 >>>>>> LoST with LbyR is not going to meet the European needs, and on = top of >>>>>> this LoST using LbyR breaks the moment you introduce forest = guides or >>>>>> don=A9=F6t have the authoritative server at the get-go. Which, = you won=A9=F6t. >>>>>> Please don=A9=F6t try and push this solution, it won=A9=F6t = address what is >>>>>> needed >>>>>> and any work done will go the way of rough location. There really = is >>>>>> not >>>>>> time for a 5 year debate on this topic only for the IETF to come >>>>>> around >>>>>> in the end like other protocol suggestions that I won=A9=F6t = name! >>>>>>=20 >>>>>> Let=A9=F6s be clear about a LIS holding civic address record EVEN = in a >>>>>> LoST-based environment. If, the LIS is required to validate = records >>>>>> then, >>>>>> if it ued LoST to do this it has EXACTLY and same informant that = any >>>>>> public LoST server would have, including the expiry times for the >>>>>> bindings. Quite simply it has everything you need. What possible >>>>>> conceivable benefits are there is forcing a to query approach = except >>>>>> that >>>>>> you want to delay the call from getting through or want to = divulge >>>>>> location values to entities that may not be entitled to see them? >>>>>>=20 >>>>>> This debate should have happened 2 years ago. LbyR for LoST = simply >>>>>> doesn=A9=F6t work. >>>>>>=20 >>>>>> Cheers >>>>>> James >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 28 Jul 2014, at 11:19 pm, Rosen, Brian = >>>>>> wrote: >>>>>>=20 >>>>>>> The milestone you are referring to is a document so far from the >>>>>>> IETF >>>>>>> approach on emergency calls that I fail to see the benefit of >>>>>>> getting >>>>>>> one protocol, HELD, used by the group pushing this architecture. >>>>>>>=20 >>>>>>> I am convinced we will need to support an environment where it = is >>>>>>> not >>>>>>> acceptable to have the end device in the path for location. The >>>>>>> level >>>>>>> of paranoia about that is so high, if we want to make progress = in >>>>>>> the >>>>>>> countries where it exists, we need to do something. In some of >>>>>>> these >>>>>>> environments, it=A9=F6s unacceptable to have the CSP get = location. Using >>>>>>> HELD with some non-IP identifier to get location by reference = works >>>>>>> okay. What is needed is a way for routing to work. This can be >>>>>>> done >>>>>>> in >>>>>>> two ways. One is allowing HELD to return route, which is how = this >>>>>>> doc >>>>>>> does it. The other is to allow LoST to do LbyR. I prefer the >>>>>>> latter, >>>>>>> but would be willing to go along with the HELD mechanism if >>>>>>> consensus >>>>>>> was to do it that way. Please don=A9=F6t use the =A9=F8one less = query=A9=F7 >>>>>>> argument. >>>>>>> It just moves the route query from the CSP to the LIS. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Jul 24, 2014, at 7:02 PM, James Winterbottom >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> This is a bit of rant, for which I am only partially apologetic >>>>>>>> because Laura and I first presented the need for this draft = more >>>>>>>> than >>>>>>>> years ago when there was time for a debate. I think that that = time >>>>>>>> has >>>>>>>> largely passed now. I sent emails to the list at the end of May = and >>>>>>>> the >>>>>>>> start of June asking for feedback on this draft and again = stated >>>>>>>> why >>>>>>>> it >>>>>>>> was needed and got next to zero response back. >>>>>>>>=20 >>>>>>>> = http://www.ietf.org/mail-archive/web/ecrit/current/msg08823.html >>>>>>>> = http://www.ietf.org/mail-archive/web/ecrit/current/msg08827.html >>>>>>>>=20 >>>>>>>> The specification that is dependent on a solution to this = problem >>>>>>>> has >>>>>>>> a milestone set for end of 1H15. >>>>>>>> There simply isn=A9=F6t time to have a 3 month mailing list = debate on >>>>>>>> this >>>>>>>> topic and then =A9=F8maybe=A9=F7 have something that can be = adopted in the >>>>>>>> nov/dec timeframe. >>>>>>>> If this topic can move =A9=F8very quickly=A9=F7 then I see some = benefit in >>>>>>>> continuing a discussion, otherwise I see little point as = decisions >>>>>>>> to >>>>>>>> address the need will be made elsewhere. >>>>>>>>=20 >>>>>>>> Cheers >>>>>>>> James >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From nobody Mon Jul 28 14:57:25 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3DE1A0262 for ; Mon, 28 Jul 2014 14:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgdLv7MvCa8H for ; Mon, 28 Jul 2014 14:57:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304491A024F for ; Mon, 28 Jul 2014 14:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1303; q=dns/txt; s=iport; t=1406584643; x=1407794243; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zEar4cA+tHySvVuC4+Dl8TUz2ag2oOvW/0wvr/u93dY=; b=QfaRU9r3ZIRAWNhGDeZ0AicXNv78iPikAh6gmTUTec09KdJ8g6P9kwrE gCuAASwSxTnNmBbx2if8/vADdxsMspP37XULtbENulanWSEGcq2SHezvZ v4ci5xhURJ8LpO3fQrpEByitSzzvzW7+Mq+CFeCzrU2FvU/cbgj70+YGA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAJnG1lOtJV2Z/2dsb2JhbABZgw5SVwTMA4dNAYESFneEAwEBAQRJMAwEAgEIDgMDAQIvIREdCAIEDgWILgMRtyQNhxMXjR+CLQcGhEQBBJlHggWOKYYjg0lsAYFE X-IronPort-AV: E=Sophos;i="5.01,751,1400025600"; d="scan'208";a="343242713" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 28 Jul 2014 21:57:22 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6SLvMbK027116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 21:57:22 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 16:57:22 -0500 From: "Marc Linsner (mlinsner)" To: James Winterbottom Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPp5Nv4tqyEK5JTUai44qlt9Y0P5u10emAgAB3lgD//8WEgIAARKaA///ETYCAAEWXgP//v6sAAAhz5ID//76UAA== Date: Mon, 28 Jul 2014 21:57:21 +0000 Message-ID: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> <69BE9441-72BA-400E-9EB6-38D955A5F0EF@gmail.com> In-Reply-To: <69BE9441-72BA-400E-9EB6-38D955A5F0EF@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.98] Content-Type: text/plain; charset="Windows-1252" Content-ID: <439A2842682D7C4698CAFE87D6454B40@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/QZfEAw1dF_cAiJbcQj1sIxnj0IM Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 21:57:24 -0000 James, -----Original Message----- From: James Winterbottom Date: Monday, July 28, 2014 at 5:51 PM To: Marc Linsner Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 >Hardly time critical! My only response to this is WOW! And you=B9re advocating how many DNS queries to discover the ANP LS???? At least 3, mostly likely 4 or 5. -Marc- > >On 29 Jul 2014, at 7:49 am, Marc Linsner (mlinsner) >wrote: > >>=20 >>=20 >> -----Original Message----- >> From: James Winterbottom >> Date: Monday, July 28, 2014 at 5:39 PM >> To: Marc Linsner >> Cc: "ecrit_ietf.org" >> Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 >>=20 >>> I don=B9t think that I said it had to come form the ANP, I think I said >>> that it can. >>> When it can, why do two queries? >>=20 >>=20 >> For the same reason a DNS query for www.foo.bar doesn=B9t automagically >>give >> you foobar's webpage. Two functions, two different responsibilities. >>=20 >> -Marc- >>=20 >>=20 >>=20 >>=20 >>>=20 >>> Cheers >>> James >>>=20 >>> =8A.snip=8A. >>> From nobody Mon Jul 28 15:12:07 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188051A01E6 for ; Mon, 28 Jul 2014 15:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ega71lmy2pcE for ; Mon, 28 Jul 2014 15:11:55 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955021A0080 for ; Mon, 28 Jul 2014 15:11:55 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa1so11343595pad.27 for ; Mon, 28 Jul 2014 15:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=PAJjNLcG29YvEoWrl13EkoJtbw9s56sqzKpMt/2Mekw=; b=giZQlZrSBnGTUJAr55scgYpjnqaqSF1Yi0vmVjaIxKMSKZ8D9JCsE+oppzznp2gexO csb4FHVTZDoyHbJKWWv6YkZS/nAnhljBff3pGA5wX7vmU3Xc1f8rSU3Dpm90ApLWVB5c X3G3Ma+bkQyTcSo/8KuvXD7kcPbNGhjRsfArKN3pZrPh1E3a5VU+Xhtmy0ZH4TIurTSc Vdzs8OQSZOhj5rbq93ZQoROW/9CcPxUpiPH0FPq/g2Am/dXajH4QAhiOg1CkCnxmf8PO PgjmN86YAOlm1Y8O8lTrgHVLtPwYOb4P/HObVlP608zBU+06OZU9SKr0c8FfqHOy9aSe 0f2Q== X-Received: by 10.70.27.161 with SMTP id u1mr1075077pdg.6.1406585515276; Mon, 28 Jul 2014 15:11:55 -0700 (PDT) Received: from [192.168.1.11] (124-168-198-48.dyn.iinet.net.au. [124.168.198.48]) by mx.google.com with ESMTPSA id gu4sm18712359pbb.54.2014.07.28.15.11.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 15:11:54 -0700 (PDT) References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> <69BE9441-72BA-400E-9EB6-38D955A5F0EF@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8D761DD2-F3D2-4B50-8797-D3FDABF7DE80@gmail.com> X-Mailer: iPhone Mail (11D201) From: James Winterbottom Date: Tue, 29 Jul 2014 08:11:51 +1000 To: "Marc Linsner (mlinsner)" Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/24Kz3x1bkl-2pvaUMj5y2GcCyL4 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 22:12:05 -0000 And you would advocate that many again and then add LoST recurs ion or redir= ect on top of it. Triple WOW! Sent from my iPhone > On 29 Jul 2014, at 7:57 am, "Marc Linsner (mlinsner)" = wrote: >=20 > James, >=20 > -----Original Message----- > From: James Winterbottom > Date: Monday, July 28, 2014 at 5:51 PM > To: Marc Linsner > Cc: "ecrit_ietf.org" > Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 >=20 >> Hardly time critical! >=20 > My only response to this is WOW! >=20 > And you=C2=B9re advocating how many DNS queries to discover the ANP LS????= >=20 > At least 3, mostly likely 4 or 5. >=20 > -Marc- >=20 >=20 >>=20 >> On 29 Jul 2014, at 7:49 am, Marc Linsner (mlinsner) >> wrote: >>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: James Winterbottom >>> Date: Monday, July 28, 2014 at 5:39 PM >>> To: Marc Linsner >>> Cc: "ecrit_ietf.org" >>> Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 >>>=20 >>>> I don=C2=B9t think that I said it had to come form the ANP, I think I s= aid >>>> that it can. >>>> When it can, why do two queries? >>>=20 >>>=20 >>> For the same reason a DNS query for www.foo.bar doesn=C2=B9t automagical= ly >>> give >>> you foobar's webpage. Two functions, two different responsibilities. >>>=20 >>> -Marc- >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Cheers >>>> James >=20 >=20 > =C5=A0.snip=C5=A0. >=20 >=20 From nobody Mon Jul 28 16:34:42 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7771A03E2 for ; Mon, 28 Jul 2014 16:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mvzSaEbewve for ; Mon, 28 Jul 2014 16:34:39 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53E11A03E0 for ; Mon, 28 Jul 2014 16:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1406590479; x=1438126479; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=Y7dWiSvVHBpMQuyM8QMFwoxFrA1QtmdwNnbu4BDmJqM=; b=aIbtEGP8KYHCmG9Emj450t0NxaAITYH9O3hG3myw+5UT1XYugDxPUKua eTxJ1eyMTbmi/0AhpJVOOifNCWTcFRJJ2C0YU34prfQMP1g3tfjdAYPlM JSbQr+c5sQjIPaR83K0FPSjGgZEhLU5J5ZYk5veuSE/YX4bjqhl7J3H0j g=; X-IronPort-AV: E=McAfee;i="5600,1067,7513"; a="71949264" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 28 Jul 2014 16:34:38 -0700 X-IronPort-AV: E=Sophos;i="5.01,752,1400050800"; d="scan'208";a="30896142" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 Jul 2014 16:34:38 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 28 Jul 2014 16:34:37 -0700 Message-ID: In-Reply-To: <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> X-Mailer: Eudora for Mac OS X Date: Mon, 28 Jul 2014 16:27:47 -0700 To: "Rosen, Brian" , James Winterbottom From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/PTnlML9YDMOTvhiHQEvDcYCDPv4 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 23:34:41 -0000 At 1:19 PM +0000 7/28/14, Brian Rosen wrote: > I am convinced we will need to support an environment where it is > not acceptable to have the end device in the path for location. We already do support such environments. In the cellular world, it's more likely that the operator will obtain location (usually with cooperation of the device, but that's besides the point) and routing. The operator might use LoST, but might not, at least in the short to medium term. > The level of paranoia about that is so high, if we want to make > progress in the countries where it exists, we need to do something. We already permit proxies to do this. That's what made the cellular world compliant. > In some of these environments, it's unacceptable to have the CSP > get location. Using HELD with some non-IP identifier to get > location by reference works okay. What is needed is a way for > routing to work. This can be done in two ways. One is allowing > HELD to return route, which is how this doc does it. The other is > to allow LoST to do LbyR. I prefer the latter, but would be > willing to go along with the HELD mechanism if consensus was to do > it that way. Please don't use the "one less query" argument. It > just moves the route query from the CSP to the LIS. Right, it's a query no matter which entity does it, or which protocol is used. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Oh, dear, where can the matter be When it's converted to energy? There is a slight loss of parity. Johnny's so long at the fair. From nobody Mon Jul 28 17:59:01 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762301A03E6; Mon, 28 Jul 2014 17:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AX_ORYiVKF5M; Mon, 28 Jul 2014 17:58:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB181A03BD; Mon, 28 Jul 2014 17:58:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140729005854.19970.23038.idtracker@ietfa.amsl.com> Date: Mon, 28 Jul 2014 17:58:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/dS7b_gaE2ATEwJRX1pdHzgOYuUg Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-trustworthy-location-14.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 00:58:55 -0000 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 : Trustworthy Location Authors : Hannes Tschofenig Henning Schulzrinne Bernard Aboba Filename : draft-ietf-ecrit-trustworthy-location-14.txt Pages : 29 Date : 2014-07-28 Abstract: The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance. This document describes threats relating to conveyance of location in an emergency call, and describes techniques that improve the reliability and security of location information conveyed in a IP- based emergency service call. It also provides guidelines for assessing the trustworthiness of location information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-trustworthy-location-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-trustworthy-location-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 29 05:45:01 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E431A03EF for ; Tue, 29 Jul 2014 05:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id US82oZxM-uL7 for ; Tue, 29 Jul 2014 05:44:57 -0700 (PDT) Received: from mx0a-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C11781A039D for ; Tue, 29 Jul 2014 05:44:57 -0700 (PDT) Received: from pps.filterd (m0049402.ppops.net [127.0.0.1]) by m0049402.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s6TChJRJ009067; Tue, 29 Jul 2014 08:44:56 -0400 Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by m0049402.ppops.net-0018ba01. with ESMTP id 1ne0670vpu-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Jul 2014 08:44:56 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc10.cis.neustar.com ([169.254.4.169]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 08:44:54 -0400 From: "Rosen, Brian" To: Randall Gellens Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqmafuI7FAtqYZUKte6fVQPTeRw== Date: Tue, 29 Jul 2014 12:44:54 +0000 Message-ID: <1C1D0F18-2C06-4152-A686-BE61F9CBB425@neustar.biz> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8DF88135B765044EBD3844A377EEA01C@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7513 signatures=670489 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/nwB8r6EYOdHYbOa5o_iFck2A4Ms Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 12:44:59 -0000 >=20 >> I am convinced we will need to support an environment where it is not ac= ceptable to have the end device in the path for location. >=20 > We already do support such environments. In the cellular world, it's mor= e likely that the operator will obtain location (usually with cooperation o= f the device, but that's besides the point) and routing. The operator might= use LoST, but might not, at least in the short to medium term. Yes, but that only works if the access network =3D communications network. = The work that James is really hot about includes nomadic VoIP over ISP pro= vided access networks. =20 >=20 >> The level of paranoia about that is so high, if we want to make progres= s in the countries where it exists, we need to do something. >=20 > We already permit proxies to do this. That's what made the cellular worl= d compliant. Agree, but see above >=20 >> In some of these environments, it's unacceptable to have the CSP get loc= ation. Using HELD with some non-IP identifier to get location by reference= works okay. What is needed is a way for routing to work. This can be don= e in two ways. One is allowing HELD to return route, which is how this doc= does it. The other is to allow LoST to do LbyR. I prefer the latter, but= would be willing to go along with the HELD mechanism if consensus was to d= o it that way. Please don't use the "one less query" argument. It just mo= ves the route query from the CSP to the LIS. >=20 > Right, it's a query no matter which entity does it, or which protocol is = used. Yeah. That=92s why even though I have a preference for LoST-does-LbyR, I a= m not really against HELD-returns-route. =20 Brian From nobody Tue Jul 29 06:00:50 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20031B2830 for ; Tue, 29 Jul 2014 06:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCE04Yx4jX5p for ; Tue, 29 Jul 2014 06:00:43 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231CD1A0154 for ; Tue, 29 Jul 2014 06:00:36 -0700 (PDT) Received: from pps.filterd (m0049367.ppops.net [127.0.0.1]) by m0049367.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s6TCwr4w000483; Tue, 29 Jul 2014 09:00:34 -0400 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by m0049367.ppops.net-0018ba01. with ESMTP id 1ne068s4bj-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Jul 2014 09:00:34 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 09:00:33 -0400 From: "Rosen, Brian" To: James Winterbottom Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqmafuI7FAtqYZUKte6fVQPTeRw== Date: Tue, 29 Jul 2014 13:00:33 +0000 Message-ID: <17BA0E6B-9047-46FE-85FE-C9D882C5A5C7@neustar.biz> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <4E9B21E8-ECBB-4AAB-98F1-62BA4DE8E601@gmail.com> <5FB89935-D6BA-46CF-A2AB-116F8DA9DCB4@gmail.com> <7B2C4A6C-6220-4C28-B5DB-C87A20811FC4@gmail.com> In-Reply-To: <7B2C4A6C-6220-4C28-B5DB-C87A20811FC4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.12] Content-Type: multipart/alternative; boundary="_000_17BA0E6B904746FE85FEC9D882C5A5C7neustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7513 signatures=670489 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/wNiPXHOAGcUA-lqoM_EsetSTQQ4 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 13:00:48 -0000 --_000_17BA0E6B904746FE85FEC9D882C5A5C7neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Getting a bit deep, but I=92ll keep playing along. \LbyR in LoST allows the VSP to acquire an endpoint location reference and obtain routing information to the correct ESRP. It does=B9t require a trus= t relationship between the LS and the VSP. [AJW] Huh?? Which LoST server does the VSP contact in your scenario? The A= NP won=92t have put any record into the DNS for its domain and even if it d= id that domain span several geographic areas LbyR in LoST can=92t recurse o= r redirect.. BREAK.. The only way that it could work would require the ANP = to establish its own LoST server and simply spit back the records from the = LS anyway. Why is this being made as two queries again?
The VSP contacts any LoST server. Using recursion or iteration, it get= s to the authoritative one. If LoST does LbyR, then the VSP gets an LbyR b= y querying the LS. It then queries any LoST server to get route. [AJW] FAIL=85 How does the LoST server know where to go? It only has a loca= tion URI and doesn=92t have permission to dereference it so it can=92t dete= rmine where the authoritative server is using either recursion or redirect.= The model is broken. This is the fundamental way LoST works. The LbyR has to return something (= country is okay), if the result is within it=92s authoritative area, it can= return the response. If not, it has a path to get resolution (up it=92s l= ocal tree, across the forest via FG, down the authoritative tree. You remind me of arguments against DNS. DNS does work right? You have hea= rd all the =93security in obscurity=94 stuff about knowing IP addresses of = various things, right? For those who still have these fears, they have ext= ernal resolution trees that have public addresses so the query can get to s= omething that gives them an externally accessible address. This is directl= y analogous to how that=92s done. LoST using LbyR would work just fine with forest guides. The forest guide would have to accept LbyR, but since it uses LoST as its interface, no problem if that=B9s the way we decide to do it. [AJW] This means that any forest guide anywhere in the world is allowed to = get location from any LS in the world using an LbyR. This has huge security= and privacy implications apart from the fact imposing certain constraints = in countries that may well not want or need these constraints. The problem with deciding to it that was is that you will end up in the sam= e position as with rough location after 2 years of debate, by which time an= alternative will have been found an used.
Spare me the polemics. Yes, the route infrastructure has to be trusted= . The LS can return something appropriately rough, with no standardization= , to an FG or a LoST server it doesn=92t recognize, if it wants to. Any po= int in the country, for example. Recursion would probably be required if e= veryone was paranoid about location. Note that the VSP can figure out loca= tion to a country with the route URI, no leakage there. [AJW] So you are re-advocating rough location? Hmm.. I though that that opt= ion was just dropped. This doesn=92t provide the same benefits at all of wh= at is in the draft I proposed. The proposal in the draft only requires the = ANP, PSAP or entities inside the emergency network to have access to locati= on values. Requiring a global route server network to have access to this i= s simply not join to meet the security/privacy requirements in some countri= es. Rough location was dropped because we could not come up with an algorithm t= o return a rough location that would not leak actual location. Here, we=92= re only trying to get to the authoritative FG, and country is okay. That l= eaks information, but country is readily determined by existing methods. I= f nothing else, domain of route would provide such information. You need an authoritative route server that accepts geo and civic addresses and returns SIP URIs. If your interface to that server isn=B9t LoST, it has to be something that duplicates it pretty closely. [AJW] No, we don=92t really need that. In the US you have highly-structured= civic addresses, for most of the rest of the world they don=92t. In countr= ies like German, ESRP addresses will be based on who the ANP is, not necess= arily the area served by the ANP. In the mobile case, point of attachment i= s good enough usually to get to the ESRP, again, I don=92t need a complex r= oute server, just a table.
In the US, like most places, you route by cell and sector, but the way = that is mechanized is the cell and sector is turned into some kind of locat= ion =96 a civic or a geo. The LoST database can be a simple table if you o= nly have a small range of addresses. We=92re discussing the protocol, not = the complexity of the data. [AJW] You conflating the route issue and the location display issue. I don= =92t need to turn the cell-id to location at routing time, the route was pr= edetermined. I only need a table, this cell-id maps to this URI. Whether th= e PSAP gets the cell-id and then converts that into a area to display, or i= t gets an area from the GMLC is immaterial. I only need a table for routing= . No. The ROUTE is determined by looking up a cell-associated location in a = location database. The location is selected so that it is within the servi= ce area of the PSAP that serves it. In some systems, the route query is do= ne in advance of the call, but in others, it=92s done at call time. I=92ll agree that if the VSP has the entire route table for all the jurisdi= ctions it operates in, then it doesn=92t need LoST for query and could use = something proprietary. Not sure what will happen in 3GPP, which is taking = that approach. I think that is a big mistake, but you still need a protoco= l that is queried with location and delivers URI. Civic addresses validation can change, and the fact that we don=B9t have a way to push a change from the validation server back to the entity that validated is a problem. -planned-changes addresses that. Of course, you are only discussing civic addresses (geos don=B9t get validated), so using the validation query to obtain route doesn=B9t work with geos. [AJW] The route is no more static in the proposal I have made than it would= using forest guides or ached data sets.
If you accept the binding time as the validation period, okay, but I do= n=92t think that is what you meant. [AJW] You are right, I didn=92t. But in most cases the kind of catastrophe = you describe can and will be done using a different approach. In emergency calling =93most=94 is a word we use to describe optimization. = We don=92t design systems that literally fail a small percentage of the ti= me. Static routes fail often enough in the real world that you should not = depend on the ability to manipulate the destination of the static route. F= ailure here is not misroute, it=92s failure to be able to get to someone th= at can help. None of this changes anything. LoST LbyR is as least as good of a solution as HELD-returns-route. HELD-returns-route has to have the TTL, the boundary, and the other LoST return things to be useful. [AJW] See above, I have still not heard from anyone how the will work despi= te having asked a number of times. [AJW] Question still answered, I provided the failure in LbyR for LoST and = it has not been addressed. Don=92t agree. See above. --_000_17BA0E6B904746FE85FEC9D882C5A5C7neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Getting a bit deep, but I=92ll keep playing along.

\LbyR in LoST allows the = VSP to acquire an endpoint location reference and
obtain = routing information to the correct ESRP.  It does=B9t require a trust<= /span>
relatio= nship between the LS and the VSP.
[AJW] Huh??  Which LoST server does the VSP contact = in your scenario? The ANP won=92t have put any record into the DNS for its = domain and even if it did that domain span several geographic areas LbyR in LoST can=92t recurse or redirect.. BREAK.= . The only way that it could work would require the ANP to establish i= ts own LoST server and simply spit back the records from the LS anyway. Why= is this being made as two queries again?

<br&= gt;The VSP contacts any LoST server.  Using recursion or iteration, it= gets to the authoritative one.  If LoST does LbyR, then the VSP gets = an LbyR by querying the LS.  It then queries any LoST server to get route.
[AJW] FAIL=85 How does the LoST server know where to go?= It only has a location URI and doesn=92t have permission to dereference it= so it can=92t determine where the authoritative server is using either recursion or redirect. The model is broken.<= /font>
This is the fundamental way LoST works.  The LbyR has to return someth= ing (country is okay), if the result is within it=92s authoritative area, i= t can return the response.  If not, it has a path to get resolution (u= p it=92s local tree, across the forest via FG, down the authoritative tree.

You remind me of arguments against DNS.  DNS does work right? &nb= sp;You have heard all the =93security in obscurity=94 stuff about knowing I= P addresses of various things, right?  For those who still have these = fears, they have external resolution trees that have public addresses so the query can get to something that gives them an exte= rnally accessible address.  This is directly analogous to how that=92s= done.  


 

LoST using LbyR would work just fine with forest guides.  The forest g= uide
would have to accept LbyR, but since it uses LoST as its interface, no
problem if that=B9s the way we decide to do it.
[AJW] This means that any forest guide=  anywhere in the world is allowed to get location from any LS in the w= orld using an LbyR. This has huge security and privacy implications ap= art from the fact imposing certain constraints in countries that may well not want or need these constraints.
The problem with deciding to it that was is= that you will end up in the same position as with rough location after 2 y= ears of debate, by which time an alternative will have been found an used.<= /font>
<br>Spare me the polemics.  Yes, the route infrastructure has to= be trusted.  The LS can return something appropriately rough, with no= standardization, to an FG or a LoST server it doesn=92t recognize, if it w= ants to.  Any point in the country, for example.  Recursion would probably be required if everyone was paranoid about location.  = Note that the VSP can figure out location to a country with the route URI, = no leakage there.
[AJW] So you are re-advocating rough location? H= mm.. I though that that option was just dropped. This doesn=92t provid= e the same benefits at all of what is in the draft I proposed. The proposal= in the draft only requires the ANP, PSAP or entities inside the emergency network to have access to location v= alues. Requiring a global route server network to have access to this = is simply not join to meet the security/privacy requirements in s= ome countries.
Rough location was dropped because we could not come up with an algorithm t= o return a rough location that would not leak actual location.  Here, = we=92re only trying to get to the authoritative FG, and country is okay. &n= bsp;That leaks information, but country is readily determined by existing methods.  If nothing else, domain of route wou= ld provide such information.




You need an authoritative route server that accepts geo and civic
addresses and returns SIP URIs.  If your interface to that server isn= =B9t
LoST, it has to be something that duplicates it pretty closely.
[AJW] No, we don=92t really need that. In t= he US you have highly-structured civic addresses, for most of the rest of t= he world they don=92t. In countries like German, ESRP addresses will b= e based on who the ANP is, not necessarily the area served by the ANP. In the mobile case, point of attachment is goo= d enough usually to get to the ESRP, again, I don=92t need a complex r= oute server, just a table. 
<br>In the US, like most places, you route by cell and sector, but th= e way that is mechanized is the cell and sector is turned into some kind of= location =96 a civic or a geo.  The LoST database can be a simple tab= le if you only have a small range of addresses.  We=92re discussing the protocol, not the complexity of the data.
[AJW] You conflating the route issue and the loc= ation display issue. I don=92t need to turn the cell-id to location at rout= ing time, the route was predetermined. I only need a table, this cell-id ma= ps to this URI. Whether the PSAP gets the cell-id and then converts that into a area to display, or it gets an a= rea from the GMLC is immaterial. I only need a table for routing.
No.  The ROUTE is determined by looking up a cell-associated location = in a location database.  The location is selected so that it is within= the service area of the PSAP that serves it.  In some systems, the ro= ute query is done in advance of the call, but in others, it=92s done at call time.

I=92ll ag= ree that if the VSP has the entire route table for all the jurisdictions it= operates in, then it doesn=92t need LoST for query and could use something= proprietary.  Not sure what will happen in 3GPP, which is taking that approach.  I think that is a big mistak= e, but you still need a protocol that is queried with location and delivers= URI.

Civic addresses validation can change, and the fa= ct that we don=B9t have a
way to push a change from the validation server b= ack to the entity that
validated is a problem.  -planned-changes addresses that.  Of cou= rse, you
are only discussing civic addresses (geos don=B9t get validated), so using<= br> the validation query to obtain route doesn=B9t work with geos.
[AJW] The route is no more static in t= he proposal I have made than it would using forest guides or ached data set= s.
<br>If you accept the binding time as the validation period, okay, bu= t I don=92t think that is what you meant.

[AJW] You are right, I didn=92t. But in mos= t cases the kind of catastrophe you describe can and will be done usin= g a different approach.
In emergency calling =93most=94 is a word we use to describe optimization. =  We don=92t design systems that literally fail a small percentage of t= he time.  Static routes fail often enough in the real world that you s= hould not depend on the ability to manipulate the destination of the static route.  Failure here is not misroute, it=92= s failure to be able to get to someone that can help.




None of this changes anything.  LoST LbyR is as least as good of a
solution as HELD-returns-route.  HELD-returns-route has to have the TT= L,
the boundary, and the other LoST return things to be useful.

[AJW] See above, I have still not heard fro= m anyone how the will work despite having asked a number of times= .

[AJW] Question still answered, I provided t= he failure in LbyR for LoST and it has not been addressed.
Don=92t agree.  See above.


--_000_17BA0E6B904746FE85FEC9D882C5A5C7neustarbiz_-- From nobody Tue Jul 29 13:58:36 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96E11A011F for ; Tue, 29 Jul 2014 13:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvvWlgkt_o7O for ; Tue, 29 Jul 2014 13:58:31 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3287E1A016A for ; Tue, 29 Jul 2014 13:58:31 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so245728pab.30 for ; Tue, 29 Jul 2014 13:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=559yc/SM+6lCyA1t70YN2EhBppIZ1DngZiZwLgRtnPc=; b=hK9NoDj3LMXyexya30DXx1qUnQ5lqZiyvM9tQcwC4PoOByrLufQHjPKl7XQWu+XlTa PlOCyuR+vWJx8t7Zqax5HfWwWTFTmZbZ5KjO7uWnKCCfYcB9vcMalN/PqXGk7HLeuhQp KUiJ5gJXyrRvvCLB4UQRbjYBVo56ikU168MEpQRcOpIFUTAMlawMIfFaVLJ/5CJumAlp h2tpBpor+gkQjUJwfEvGwhqvrvApssr4Rg3XCvcxZDBphkL0ITjRP4lUNg9vr5OAYdla jjjGtWTw+YHUzwP4xdz87OzxIY6HMvW/4a2HiOSgPlolBXHSylD8Jwqm30EGr3fjGNp8 4B3w== X-Received: by 10.66.253.170 with SMTP id ab10mr4548488pad.53.1406667510860; Tue, 29 Jul 2014 13:58:30 -0700 (PDT) Received: from [192.168.1.10] (124-168-62-139.dyn.iinet.net.au. [124.168.62.139]) by mx.google.com with ESMTPSA id fe8sm124551pdb.16.2014.07.29.13.58.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 13:58:30 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: <1C1D0F18-2C06-4152-A686-BE61F9CBB425@neustar.biz> Date: Wed, 30 Jul 2014 06:58:26 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <1C1D0F18-2C06-4152-A686-BE61F9CBB425@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/SiSHaYLu7xEm3_WYckJi7yoxkJI Cc: Randall Gellens , "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 20:58:32 -0000 Brian, If this really is your sentiment then why are we having this debate? By your own admission LbyR in LoST requires at least some rough = location, this doesn=92t meet the requirements we have outlined. The routing returned in HELD will meet the requirements in Europe, can=92t= we just get on with producing a spec please? Cheers James >>=20 >>=20 >> Right, it's a query no matter which entity does it, or which protocol = is used. > Yeah. That=92s why even though I have a preference for = LoST-does-LbyR, I am not really against HELD-returns-route. =20 >=20 > Brian >=20 >=20 From nobody Tue Jul 29 14:13:11 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADA71ABB2C for ; Tue, 29 Jul 2014 14:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P4DZgFqWg78 for ; Tue, 29 Jul 2014 14:13:08 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4D8A1A0142 for ; Tue, 29 Jul 2014 14:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1314; q=dns/txt; s=iport; t=1406668388; x=1407877988; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=024OGzqbKeG3pE4gjfc7+sblaC5Gw/rw73IbJKFQfuo=; b=kGb1TsB17KKcioJPo+5fywK0QrhmnPpDYNxvuxwqagEkKTMJsx8Pq9EI DVsc1bFhS4KMB6qc9VPXaSqjDDZhjhykmHpVjcnKpv2cJEWsbyDsfL4XP gwf55JRiMS1+TZRRhREBOEci3ZOjS8Iqsyh4BkwSi/0b5DT+AteTjvhYJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAK8N2FOtJV2c/2dsb2JhbABagw5SVwTLbQqHSwGBEhZ3hAMBAQEEAQEBawsMBAIBCA4DAwECLyEGCx0IAgQOBYguAxENuDMNhwkXjR+BeggrBwaERAWKOI8SggWOKYYlg0lsAYFE X-IronPort-AV: E=Sophos;i="5.01,759,1400025600"; d="scan'208";a="64978239" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 29 Jul 2014 21:13:07 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6TLD7Ft024312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 21:13:07 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 16:13:07 -0500 From: "Marc Linsner (mlinsner)" To: James Winterbottom Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPp5Nv4tqyEK5JTUai44qlt9Y0P5u10emAgACp1oCAAN62AIAAieQA///BB4A= Date: Tue, 29 Jul 2014 21:13:06 +0000 Message-ID: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <1C1D0F18-2C06-4152-A686-BE61F9CBB425@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.80.187] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/vwbs3_w2Sc3fNZYjP2LCNADjTmU Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:13:10 -0000 -----Original Message----- From: James Winterbottom Date: Tuesday, July 29, 2014 at 4:58 PM To: "Rosen, Brian" Cc: Randall Gellens , "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 >Brian, > >If this really is your sentiment then why are we having this debate? >By your own admission LbyR in LoST requires at least some rough location, >this doesn=B9t meet the requirements we have outlined. >The routing returned in HELD will meet the requirements in Europe, can=B9t >we just get on with producing a spec please? The problem is the requirements are for the most part fallacious. When queried why the VSP can=B9t have LbyV if it=B9s covered by their EULA, the answer is, in that case they can have LbyV. -Marc- > >Cheers >James > > >>>=20 >>>=20 >>> Right, it's a query no matter which entity does it, or which protocol >>>is used. >> Yeah. That=B9s why even though I have a preference for LoST-does-LbyR, = I >>am not really against HELD-returns-route. >>=20 >> Brian >>=20 >>=20 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Jul 29 15:38:01 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABF51B292E for ; Tue, 29 Jul 2014 15:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpwjjoV2th_W for ; Tue, 29 Jul 2014 15:37:56 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C661B2863 for ; Tue, 29 Jul 2014 15:37:56 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id eu11so370258pac.4 for ; Tue, 29 Jul 2014 15:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t7xWwL1U6SvMSKaQoXOUz3A6lW3ISxkUKXs6vci7H30=; b=V26A44TmIYGSc7l1Bhf6HH0B7whSbaZeWIuSYxoDQVKe/+10d+b3VE4lco08hliVPv EwarrKPbwWHigyTAOzYNlXLqpL2o/VXJ4PoiAUATaCnj9SvU4to8eJlHut8LKH2eeaCZ 5SM3DlNbjf9FCnsUWNnrRdurXq66dME7H+oqvyGvAtP4REJw/4zjcXEh/Iu+0CjGGToN Ft6sXsqT0lzUgTty6PyJyopUMOijYLAOAGjK1XiktqbQykQVfIh6g5mezdt4dCxfv6OP /Bua40GvSb5SbHpyWIizdn36RR+5QrVmIGJWq+VoV+ZGhYbXX2VKpcfiFng3w5zOa88k UvXw== X-Received: by 10.68.213.34 with SMTP id np2mr4912544pbc.167.1406673475910; Tue, 29 Jul 2014 15:37:55 -0700 (PDT) Received: from [192.168.1.100] ([120.153.186.55]) by mx.google.com with ESMTPSA id tg9sm202120pbc.29.2014.07.29.15.37.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 15:37:55 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: <1C2CE0AD-5D2F-4EF3-BBFF-E0067E22A82B@neustar.biz> Date: Wed, 30 Jul 2014 08:37:51 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <429A12E4-0ECD-4331-A6AB-FA1D6FB8F646@gmail.com> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <1C1D0F18-2C06-4152-A686-BE61F9CBB425@neustar.biz> <1C2CE0AD-5D2F-4EF3-BBFF-E0067E22A82B@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/E6VRGW4P0Qd9eLzu9XFwyH2HQLc Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 22:37:58 -0000 Brain, Like NENA i3, on thick the EENA architecture is based, anything outside = the ESInet is out of scope. As a consequence, how the call arrives at = the ESInet is also out of scope. If the ESInet deploys LoST internally = great, for sure in some networks it will and for sure in others it = won=92t. The ETSI architecture doesn=92t bet either way. Cheers James On 30 Jul 2014, at 8:22 am, Rosen, Brian = wrote: > Let=92s also qualify that =93In Europe=94 is this specific ETSI work. = There is other work (EENA) that uses the IETF approach holistically. It = may be that the ETSI work succeeds and is deployed in some countries for = some time, but I would not recommend betting against the EENA approach = long term. >=20 > Brian >=20 > On Jul 29, 2014, at 5:13 PM, Marc Linsner (mlinsner) = wrote: >=20 >>=20 >>=20 >> -----Original Message----- >> From: James Winterbottom >> Date: Tuesday, July 29, 2014 at 4:58 PM >> To: "Rosen, Brian" >> Cc: Randall Gellens , "ecrit_ietf.org" >> >> Subject: Re: [Ecrit] Discussion on = draft-winterbottom-ecrit-priv-loc-04 >>=20 >>> Brian, >>>=20 >>> If this really is your sentiment then why are we having this debate? >>> By your own admission LbyR in LoST requires at least some rough = location, >>> this doesn=B9t meet the requirements we have outlined. >>> The routing returned in HELD will meet the requirements in Europe, = can=B9t >>> we just get on with producing a spec please? >>=20 >>=20 >> The problem is the requirements are for the most part fallacious. >>=20 >> When queried why the VSP can=B9t have LbyV if it=B9s covered by their = EULA, >> the answer is, in that case they can have LbyV. >>=20 >> -Marc- >>=20 >>=20 >>=20 >>>=20 >>> Cheers >>> James >>>=20 >>>=20 >>>>>=20 >>>>>=20 >>>>> Right, it's a query no matter which entity does it, or which = protocol >>>>> is used. >>>> Yeah. That=B9s why even though I have a preference for = LoST-does-LbyR, I >>>> am not really against HELD-returns-route. >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From nobody Tue Jul 29 15:54:48 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1231B2977 for ; Tue, 29 Jul 2014 15:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EUZGeB3eTbV for ; Tue, 29 Jul 2014 15:54:44 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D5A1B28B5 for ; Tue, 29 Jul 2014 15:54:43 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id fp1so374489pdb.13 for ; Tue, 29 Jul 2014 15:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F/NNYYMbQBaKl+Mt8n5V7mqDSg5o8+fZa18rxok7Ih4=; b=Hzha317G6PnNNtdJLzmXtf3pxDehuJIdnHG0flX5yPSqY4jKj4NtcEYUKfJBWgoIA+ WivubTKAR5091oZfbr3mfAOiayMIWgPQc+UCR5YoUCOJvk6rnLJlBhPRDor7/4Fi/ajn tpxQ5jfRUpWRDyIaYRlRZj9YxpBZ5zzI28Kqu09rk1JgwbDKvX5fs9y4slG9naunxJvJ MGaEgJ+EIpPJw9M9KLgD7tpHmtAiOPYAMQY9x75Z2Oo41r7nhdnz4IW7Fp4P46P/Fjnf FMx6IOwp8T7MM4iKt/WBqEAOKSzQk0KFqw5q7sA85+F7eWIRq908BCMVMPGLOL6wrR57 11ag== X-Received: by 10.68.197.65 with SMTP id is1mr48059pbc.125.1406674483466; Tue, 29 Jul 2014 15:54:43 -0700 (PDT) Received: from [192.168.1.100] ([120.153.186.55]) by mx.google.com with ESMTPSA id kj6sm383673pdb.89.2014.07.29.15.54.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 15:54:42 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: Date: Wed, 30 Jul 2014 08:54:39 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <2663C1A1-DC17-4E77-95E6-F27276D400EB@gmail.com> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <1C1D0F18-2C06-4152-A686-BE61F9CBB425@neustar.biz> To: "Marc Linsner (mlinsner)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/AxYuokdUAjHpXXOWySNU17KNTD8 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 22:54:46 -0000 Marc, Hannes and I pointed out what was going on in that WG to you and others = well over 2 years ago, and the preliminary work in EMTEL even longer ago = than that. I have made suggestions on what you might do to evolve the ETSI = architecture to fit your needs, but I have also pointed out the issue = you likely to face trying to that in this release. I believe that the = best course of action is request a new work item some time next year to = perform this evolution. In the mean time trying to drive a solution in = the IETF that your most likely customers don=92t want is an exercise in = futility. I have stated why pure LbyR in LoST doesn=92t work, and Brian has = confirmed this. Nobody has said why returning routing information in = HELD won=92t work. Responses to the list question are 2 for this proposal and 2 against. = Hardly consensus in either direction. It is likely that I will not be = able convince you or Brian of the merits of this proposal or the = possible outcomes of doing something else, so I am not going to continue = to try. It would be good to have a few more people expressing on the list the = direction they wish to take as I think that this will provide a better = indication of the overall mood of the WG on this topic. Cheers James On 30 Jul 2014, at 7:13 am, Marc Linsner (mlinsner) = wrote: >=20 >=20 > -----Original Message----- > From: James Winterbottom > Date: Tuesday, July 29, 2014 at 4:58 PM > To: "Rosen, Brian" > Cc: Randall Gellens , "ecrit_ietf.org" > > Subject: Re: [Ecrit] Discussion on = draft-winterbottom-ecrit-priv-loc-04 >=20 >> Brian, >>=20 >> If this really is your sentiment then why are we having this debate? >> By your own admission LbyR in LoST requires at least some rough = location, >> this doesn=B9t meet the requirements we have outlined. >> The routing returned in HELD will meet the requirements in Europe, = can=B9t >> we just get on with producing a spec please? >=20 >=20 > The problem is the requirements are for the most part fallacious. >=20 > When queried why the VSP can=B9t have LbyV if it=B9s covered by their = EULA, > the answer is, in that case they can have LbyV. >=20 > -Marc- >=20 >=20 >=20 >>=20 >> Cheers >> James >>=20 >>=20 >>>>=20 >>>>=20 >>>> Right, it's a query no matter which entity does it, or which = protocol >>>> is used. >>> Yeah. That=B9s why even though I have a preference for = LoST-does-LbyR, I >>> am not really against HELD-returns-route. >>>=20 >>> Brian >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From nobody Tue Jul 29 15:56:44 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09141B2977 for ; Tue, 29 Jul 2014 15:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEGClZDMNJvp for ; Tue, 29 Jul 2014 15:56:41 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7330B1B28E1 for ; Tue, 29 Jul 2014 15:56:41 -0700 (PDT) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id s6TMJMvK015496; Tue, 29 Jul 2014 18:22:16 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1ne067jdfc-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Jul 2014 18:22:16 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 18:22:16 -0400 From: "Rosen, Brian" To: Marc Linsner Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqmafuI7FAtqYZUKte6fVQPTeRw== Date: Tue, 29 Jul 2014 22:22:16 +0000 Message-ID: <1C2CE0AD-5D2F-4EF3-BBFF-E0067E22A82B@neustar.biz> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <1C1D0F18-2C06-4152-A686-BE61F9CBB425@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.12] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7514 signatures=670489 X-Proofpoint-Spam-Reason: safe Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/grGI7dj1cofb52j4w4omrnYTd8c Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 22:56:43 -0000 Let=92s also qualify that =93In Europe=94 is this specific ETSI work. Ther= e is other work (EENA) that uses the IETF approach holistically. It may be= that the ETSI work succeeds and is deployed in some countries for some tim= e, but I would not recommend betting against the EENA approach long term. Brian On Jul 29, 2014, at 5:13 PM, Marc Linsner (mlinsner) w= rote: >=20 >=20 > -----Original Message----- > From: James Winterbottom > Date: Tuesday, July 29, 2014 at 4:58 PM > To: "Rosen, Brian" > Cc: Randall Gellens , "ecrit_ietf.org" > > Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 >=20 >> Brian, >>=20 >> If this really is your sentiment then why are we having this debate? >> By your own admission LbyR in LoST requires at least some rough location= , >> this doesn=B9t meet the requirements we have outlined. >> The routing returned in HELD will meet the requirements in Europe, can= =B9t >> we just get on with producing a spec please? >=20 >=20 > The problem is the requirements are for the most part fallacious. >=20 > When queried why the VSP can=B9t have LbyV if it=B9s covered by their EUL= A, > the answer is, in that case they can have LbyV. >=20 > -Marc- >=20 >=20 >=20 >>=20 >> Cheers >> James >>=20 >>=20 >>>>=20 >>>>=20 >>>> Right, it's a query no matter which entity does it, or which protocol >>>> is used. >>> Yeah. That=B9s why even though I have a preference for LoST-does-LbyR,= I >>> am not really against HELD-returns-route. >>>=20 >>> Brian >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Jul 29 16:31:29 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C931B2A1A for ; Tue, 29 Jul 2014 16:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRIrquDbZFE4 for ; Tue, 29 Jul 2014 16:31:25 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DA81B286F for ; Tue, 29 Jul 2014 16:31:25 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id s6TNVGGm003970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 29 Jul 2014 16:31:16 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.252]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0195.001; Tue, 29 Jul 2014 16:31:16 -0700 From: Roger Marshall To: "Rosen, Brian" , Marc Linsner Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPp5Nv7Zh/vKnQs0eXMhwHES05HZu183CAgAGdLEuAAHldAIAAE1MA//+Z3GA= Date: Tue, 29 Jul 2014 23:31:15 +0000 Message-ID: References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <1C1D0F18-2C06-4152-A686-BE61F9CBB425@neustar.biz> <1C2CE0AD-5D2F-4EF3-BBFF-E0067E22A82B@neustar.biz> In-Reply-To: <1C2CE0AD-5D2F-4EF3-BBFF-E0067E22A82B@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/YDoQ9rYcpdw8Hn2Wymv1JP7lnig Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 23:31:27 -0000 I'm a believer in the discrete query model. It's basic, it's ECRIT std. 1. Query for location, then=20 2. Query for routing This two-query approach can be done (including from the VSP to the ASP) by = reusing the existing ECRIT model: a. from the VSP, a HELD query to the LS to retrieve location information (L= byV) or retrieve Location URI (LbyR) b. from the VSP, a Routing query (you can reuse LoST here) with either -- Location Info payload (RFC 5222) to a LoST server (this could be a n= ew ETSI contribution), or -- Location by Reference sent in a LoST query (if you don't want the VS= P to ever "see" the location info, though this would require an extension t= o RFC5222) The ASP's LS could simply be a LoST Server containing a table, or GIS data = layers - and if not found, it could recurse to a different LoST server/FG. -roger. -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian Sent: Tuesday, July 29, 2014 3:22 PM To: Marc Linsner Cc: ecrit_ietf.org Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Let's also qualify that "In Europe" is this specific ETSI work. There is o= ther work (EENA) that uses the IETF approach holistically. It may be that = the ETSI work succeeds and is deployed in some countries for some time, but= I would not recommend betting against the EENA approach long term. Brian On Jul 29, 2014, at 5:13 PM, Marc Linsner (mlinsner) w= rote: >=20 >=20 > -----Original Message----- > From: James Winterbottom > Date: Tuesday, July 29, 2014 at 4:58 PM > To: "Rosen, Brian" > Cc: Randall Gellens , "ecrit_ietf.org" > > Subject: Re: [Ecrit] Discussion on=20 > draft-winterbottom-ecrit-priv-loc-04 >=20 >> Brian, >>=20 >> If this really is your sentiment then why are we having this debate? >> By your own admission LbyR in LoST requires at least some rough=20 >> location, this doesn=B9t meet the requirements we have outlined. >> The routing returned in HELD will meet the requirements in Europe,=20 >> can=B9t we just get on with producing a spec please? >=20 >=20 > The problem is the requirements are for the most part fallacious. >=20 > When queried why the VSP can=B9t have LbyV if it=B9s covered by their=20 > EULA, the answer is, in that case they can have LbyV. >=20 > -Marc- >=20 >=20 >=20 >>=20 >> Cheers >> James >>=20 >>=20 >>>>=20 >>>>=20 >>>> Right, it's a query no matter which entity does it, or which=20 >>>> protocol is used. >>> Yeah. That=B9s why even though I have a preference for=20 >>> LoST-does-LbyR, I am not really against HELD-returns-route. >>>=20 >>> Brian >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From nobody Tue Jul 29 18:07:49 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F361B29F3 for ; Tue, 29 Jul 2014 18:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtJhGRMV9HrK for ; Tue, 29 Jul 2014 18:07:46 -0700 (PDT) Received: from BLU004-OMC2S25.hotmail.com (blu004-omc2s25.hotmail.com [65.55.111.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FF11B2A26 for ; Tue, 29 Jul 2014 18:07:46 -0700 (PDT) Received: from BLU406-EAS199 ([65.55.111.73]) by BLU004-OMC2S25.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Tue, 29 Jul 2014 18:07:45 -0700 X-TMN: [jRDs9XRMdNr6yn6UZd3UAL/tcE4w0YaYdem4X6tE+xs=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <1C1D0F18-2C06-4152-A686-BE61F9CBB425@neustar.biz> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Tue, 29 Jul 2014 18:07:40 -0700 To: "Marc Linsner (mlinsner)" X-OriginalArrivalTime: 30 Jul 2014 01:07:45.0535 (UTC) FILETIME=[ABF1A8F0:01CFAB92] Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/vUgezuWOjvV_talD_j0lRcz9WNI Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 01:07:47 -0000 VGhlcmUgYXJlIG11bHRpcGxlIGlzc3VlcyB3aXRoIExieVYsIHRob3VnaC4gSXQgaXNuJ3QganVz dCBhYm91dCB0aGUgVlNQIChhZ3JlZSB0aGF0IHRoaXMgaXMgcHJvYmFibHkgYm9ndXMpLCBvciBl dmVuIHRydXN0d29ydGhpbmVzcy4gU29tZSBsYXJnZSBBTlBzIGFyZSBqdXN0IG5vdCBpbmNsaW5l ZCB0byBwcm92aWRlIGl0IGZvciBidXNpbmVzcyByZWFzb25zLg0KDQo+IE9uIEp1bCAyOSwgMjAx NCwgYXQgMjoxMyBQTSwgIk1hcmMgTGluc25lciAobWxpbnNuZXIpIiA8bWxpbnNuZXJAY2lzY28u Y29tPiB3cm90ZToNCg0KPiBUaGUgcHJvYmxlbSBpcyB0aGUgcmVxdWlyZW1lbnRzIGFyZSBmb3Ig dGhlIG1vc3QgcGFydCBmYWxsYWNpb3VzLg0KPiANCj4gV2hlbiBxdWVyaWVkIHdoeSB0aGUgVlNQ IGNhbsK5dCBoYXZlIExieVYgaWYgaXTCuXMgY292ZXJlZCBieSB0aGVpciBFVUxBLCB0aGUgYW5z d2VyIGlzLCBpbiB0aGF0IGNhc2UgdGhleSBjYW4gaGF2ZSBMYnlWLg0KPiANCj4gLU1hcmMtDQo+ IA0KPiANCj4gDQo+PiANCj4+IENoZWVycw0KPj4gSmFtZXMNCj4+IA0KPj4gDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gUmlnaHQsIGl0J3MgYSBxdWVyeSBubyBtYXR0ZXIgd2hpY2ggZW50aXR5IGRvZXMg aXQsIG9yIHdoaWNoIHByb3RvY29sDQo+Pj4+IGlzIHVzZWQuDQo+Pj4gWWVhaC4gIFRoYXTCuXMg d2h5IGV2ZW4gdGhvdWdoIEkgaGF2ZSBhIHByZWZlcmVuY2UgZm9yIExvU1QtZG9lcy1MYnlSLCBJ DQo+Pj4gYW0gbm90IHJlYWxseSBhZ2FpbnN0IEhFTEQtcmV0dXJucy1yb3V0ZS4NCj4+PiANCj4+ PiBCcmlhbg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+PiBFY3JpdEBpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGluZyBs aXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQNCg== From nobody Tue Jul 29 19:01:48 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B881B2A43 for ; Tue, 29 Jul 2014 19:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wC4BLtv6NobO for ; Tue, 29 Jul 2014 19:01:44 -0700 (PDT) Received: from BLU004-OMC2S6.hotmail.com (blu004-omc2s6.hotmail.com [65.55.111.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5111B2A41 for ; Tue, 29 Jul 2014 19:01:44 -0700 (PDT) Received: from BLU406-EAS361 ([65.55.111.73]) by BLU004-OMC2S6.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Tue, 29 Jul 2014 19:01:43 -0700 X-TMN: [EY4hiUJQK4y5NLugzihxbgRdZ/cDsVGRK35ePveSKpk=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_fadc033c-214d-4848-bd19-3cc3f0e15772_" References: <3B7C55D6-CE28-4B95-80D2-11AA101C53C2@gmail.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <3B7C55D6-CE28-4B95-80D2-11AA101C53C2@gmail.com> Date: Tue, 29 Jul 2014 19:01:36 -0700 To: James Winterbottom X-OriginalArrivalTime: 30 Jul 2014 02:01:43.0715 (UTC) FILETIME=[360CB730:01CFAB9A] Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/Y3OeweVShJLoUTIc9t7lfB8-N6E Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 02:01:47 -0000 --_fadc033c-214d-4848-bd19-3cc3f0e15772_ Content-Type: multipart/alternative; boundary="Apple-Mail-84D9EF20-6984-41D2-8431-E8AEB2A88443" Content-Transfer-Encoding: 7bit --Apple-Mail-84D9EF20-6984-41D2-8431-E8AEB2A88443 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBhbHNvIGZhdm9yICMxLCBiYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIG9mIGN1cnJl bnQgZGVwbG95bWVudCBwbGFucy4NCg0KQlRXLCBkbyB3ZSBoYXZlIGEgbGlhaXNvbnMgZnJvbSBT RE9zIHNheWluZyB0aGV5IHdvdWxkIHVzZSB0aGlzPyBJZiBub3QsIGNhbiB0aGUgRUNSSVQgV0cg c2VuZCBsaWFpc29ucyBhc2tpbmcgaWYgaXQgd291bGQgYmUgdXNlZD8gDQoNCj4gT24gSnVsIDI4 LCAyMDE0LCBhdCAxOjMwIFBNLCAiSmFtZXMgV2ludGVyYm90dG9tIiA8YS5qYW1lcy53aW50ZXJi b3R0b21AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEkgYW0gZ29pbmcgZm9yICMxLg0KPiANCj4g DQo+IA0KPj4gT24gMjggSnVsIDIwMTQsIGF0IDExOjIyIHBtLCBNYXJjIExpbnNuZXIgKG1saW5z bmVyKSA8bWxpbnNuZXJAY2lzY28uY29tPiB3cm90ZToNCj4+IA0KPj4gQWxsLA0KPj4gDQo+PiBU aGlzIGRyYWZ0IHdhcyBwcmVzZW50ZWQgaW4gYSBjb21wcmVzc2VkIHRpbWUgc2xvdCBhdCB0aGUg VG9yb250byBtZWV0aW5nIGxhc3Qgd2Vlay4gIEphbWVzIFcuIGhhcyBpbmRpY2F0ZWQgYW4gdXJn ZW5jeSB0byBtb3ZlIHRoaXMgd29yayBmb3J3YXJkLiAgVGhlIGNoYWlycyBhcmUgYXNraW5nIGV2 ZXJ5b25lIHRvIHJldmlldyB0aGlzIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGFkb3B0aW5nIHRo aXMgZHJhZnQgYXMgYSB3ZyBpdGVtLiAgU28sIHBsZWFzZSByZXZpZXcgdGhpcyBmcm9tIHRoZSBv dmVyYWxsIGFyY2hpdGVjdHVyYWwgdmFsdWUgb2YgcHJvdmlkaW5nIGVtZXJnZW5jeSBjYWxsIHJv dXRpbmcgd2l0aGluIGEgSEVMRCByZXEvcmVzcG9uc2UgKHByb3RvY29sIGRldGFpbHMgYW5kIHdv cmQgc21pdGhpbmcgY2FuIGJlIGRvbmUgYWZ0ZXIgaXQgYmVjb21lcyBhIHdnIGl0ZW0pLg0KPj4g DQo+PiBTaW5jZSBKYW1lcyBoYXMgaW5kaWNhdGVkIHRoaXMgd29yayB3aWxsIGJlIHVzZWQgYnkg b3RoZXIgU0RPcywgYW5kIGNvdXBsZWQgd2l0aCB0aGUgc3RhdGVkIHVyZ2VuY3ksIHRoZSBjaGFp cnMgcmVxdWVzdCB0aGF0IHlvdSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBpbmRpY2F0ZSB0byB0aGUg bGlzdCBieSBDT0IgV2VkbmVzZGF5IEF1Z3VzdCA2LCAyMDE0IHlvdXIgb3BpbmlvbjoNCj4+IEkg YmVsaWV2ZSB0aGlzIHdvcmsgc2hvdWxkIG1vdmUgZm9yd2FyZCBpbiBFQ1JJVA0KPj4gSeKAmW0g YWdub3N0aWMgdG8gdGhpcyB3b3JrIGFuZCBkb27igJl0IGNhcmUgZWl0aGVyIHdheQ0KPj4gSeKA mW0gb3Bwb3NlZCB0byB0aGlzIGFyY2hpdGVjdHVyYWwgY2hhbmdlIHRvIHRoZSBFQ1JJVCBtb2Rl bCBhbmQgYmVsaWV2ZSB0aGlzIHdvcmsgc2hvdWxkIG5vdCBiZSBhZG9wdGVkLg0KPj4gDQo+PiBB IGluZGljYXRpb24gb2YgIzIgdGVsbHMgdGhlIGNoYWlycyB0aGF0IHlvdSBhcmUgYXdhcmUgb2Yg dGhlIHdvcmsgYW5kIHRydWx5IGRvbuKAmXQgaGF2ZSBhbiBvcGluaW9uLCBpdCBoZWxwcyB1cyBp biBkZXRlcm1pbmluZyB3aGF0IHBlcmNlbnRhZ2Ugb2YgdGhlIHdnIHBhcnRpY2lwYW50cyBoYXZl IHJlYWQgdGhlIGRyYWZ0Lg0KPj4gDQo+PiBUaGFua3MsDQo+PiANCj4+IE1hcmMgJiBSb2dlcg0K Pj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+IEVjcml0QGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QN Cj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9lY3JpdA0K --Apple-Mail-84D9EF20-6984-41D2-8431-E8AEB2A88443 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SSB3b3Vs ZCBhbHNvIGZhdm9yICMxLCBiYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIG9mIGN1cnJlbnQgZGVw bG95bWVudCBwbGFucy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkJUVywgZG8gd2UgaGF2ZSBh IGxpYWlzb25zIGZyb20gU0RPcyBzYXlpbmcgdGhleSB3b3VsZCB1c2UgdGhpcz8gSWYgbm90LCBj YW4gdGhlIEVDUklUIFdHIHNlbmQgbGlhaXNvbnMgYXNraW5nIGlmIGl0IHdvdWxkIGJlIHVzZWQ/ Jm5ic3A7PC9kaXY+PGRpdj48YnI+T24gSnVsIDI4LCAyMDE0LCBhdCAxOjMwIFBNLCAiSmFtZXMg V2ludGVyYm90dG9tIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmEuamFtZXMud2ludGVyYm90dG9tQGdt YWlsLmNvbSI+YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJy Pjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sIGNoYXJzZXQ9d2luZG93cy0xMjUyIj5J IGFtIGdvaW5nIGZvciAjMS48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48 ZGl2PjxkaXY+T24gMjggSnVsIDIwMTQsIGF0IDExOjIyIHBtLCBNYXJjIExpbnNuZXIgKG1saW5z bmVyKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1saW5zbmVyQGNpc2NvLmNvbSI+bWxpbnNuZXJAY2lz Y28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29u dGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9V2luZG93cy0xMjUyIj4NCg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGZvbnQtc2l6ZTogMTRw eDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+QWxsLDwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBkcmFmdCB3YXMgcHJlc2VudGVkIGluIGEgY29t cHJlc3NlZCB0aW1lIHNsb3QgYXQgdGhlIFRvcm9udG8gbWVldGluZyBsYXN0IHdlZWsuICZuYnNw O0phbWVzIFcuIGhhcyBpbmRpY2F0ZWQgYW4gdXJnZW5jeSB0byBtb3ZlIHRoaXMgd29yayBmb3J3 YXJkLiAmbmJzcDtUaGUgY2hhaXJzIGFyZSBhc2tpbmcgZXZlcnlvbmUgdG8gcmV2aWV3IHRoaXMg ZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgYWRvcHRpbmcgdGhpcyBkcmFmdCBhcyBhIHdnIGl0ZW0u DQogJm5ic3A7U28sIHBsZWFzZSByZXZpZXcgdGhpcyBmcm9tIHRoZSBvdmVyYWxsIGFyY2hpdGVj dHVyYWwgdmFsdWUgb2YgcHJvdmlkaW5nIGVtZXJnZW5jeSBjYWxsIHJvdXRpbmcgd2l0aGluIGEg SEVMRCByZXEvcmVzcG9uc2UgKHByb3RvY29sIGRldGFpbHMgYW5kIHdvcmQgc21pdGhpbmcgY2Fu IGJlIGRvbmUgYWZ0ZXIgaXQgYmVjb21lcyBhIHdnIGl0ZW0pLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+U2luY2UgSmFtZXMgaGFzIGluZGljYXRlZCB0aGlzIHdvcmsgd2lsbCBiZSB1 c2VkIGJ5IG90aGVyIFNET3MsIGFuZCBjb3VwbGVkIHdpdGggdGhlIHN0YXRlZCB1cmdlbmN5LCB0 aGUgY2hhaXJzIHJlcXVlc3QgdGhhdCB5b3UgcmV2aWV3IHRoZSBkcmFmdCBhbmQgaW5kaWNhdGUg dG8gdGhlIGxpc3QgYnkgQ09CIFdlZG5lc2RheSBBdWd1c3QgNiwgMjAxNCB5b3VyIG9waW5pb246 PC9kaXY+DQo8b2w+DQo8bGk+SSBiZWxpZXZlIHRoaXMgd29yayBzaG91bGQgbW92ZSBmb3J3YXJk IGluIEVDUklUPC9saT48bGk+SeKAmW0gYWdub3N0aWMgdG8gdGhpcyB3b3JrIGFuZCBkb27igJl0 IGNhcmUgZWl0aGVyIHdheTwvbGk+PGxpPknigJltIG9wcG9zZWQgdG8gdGhpcyBhcmNoaXRlY3R1 cmFsIGNoYW5nZSB0byB0aGUgRUNSSVQgbW9kZWwgYW5kIGJlbGlldmUgdGhpcyB3b3JrIHNob3Vs ZCBub3QgYmUgYWRvcHRlZC48L2xpPjwvb2w+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BIGlu ZGljYXRpb24gb2YgIzIgdGVsbHMgdGhlIGNoYWlycyB0aGF0IHlvdSBhcmUgYXdhcmUgb2YgdGhl IHdvcmsgYW5kIHRydWx5IGRvbuKAmXQgaGF2ZSBhbiBvcGluaW9uLCBpdCBoZWxwcyB1cyBpbiBk ZXRlcm1pbmluZyB3aGF0IHBlcmNlbnRhZ2Ugb2YgdGhlIHdnIHBhcnRpY2lwYW50cyBoYXZlIHJl YWQgdGhlIGRyYWZ0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TWFyYyAmYW1wOyBSb2dlcjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+RWNyaXQgbWFpbGluZyBsaXN0PGJy PjxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+PGJyPjwvYmxvY2txdW90 ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188L3NwYW4+PGJyPjxzcGFuPkVjcml0IG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+ PGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYub3JnIj5FY3JpdEBpZXRmLm9yZzwvYT48L3NwYW4+ PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZWNyaXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+PC9z cGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-84D9EF20-6984-41D2-8431-E8AEB2A88443-- --_fadc033c-214d-4848-bd19-3cc3f0e15772_ 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 --_fadc033c-214d-4848-bd19-3cc3f0e15772_-- From nobody Tue Jul 29 19:05:30 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF41C1B2A47 for ; Tue, 29 Jul 2014 19:05:28 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ef9Y1G-v2tBA for ; Tue, 29 Jul 2014 19:05:26 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9801B2A43 for ; Tue, 29 Jul 2014 19:05:26 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id lj1so618400pab.33 for ; Tue, 29 Jul 2014 19:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=rwTGhoILEoVms001UTQvAMKX1ACOgEQe79bQDhJ0kgM=; b=aCGbTons1ch036mN8SWluLdn+qyeipEvK6qLz1yQSiJZqpIW3Kd6gEJ6A1TaLUK07e 03aV4cjdwT+Ifbz/HncleACQp/nYNbVqdWq3zYs/AMuGoytF09TT4LuNjMvbNEPZfSkC nZ0THW99sBqKnlNSOf1L5QyI6+FhOKkm1VYt5YbVsxU34S0QrLo8ay1IzPqXqRvpBgXj RFJ3iYbUFuzoNwPLXi0Il2bdr05DaAP0d9XkpkbnqFTKaIJ3Ok+y570VU3r622PBIUOS q91wvszYvVzkXcM+O8PkSlnlsdY/WUeqghdSPMM+cbhzMzUPAEG6Lif1BvAW6wGrcgqK zyJw== X-Received: by 10.70.64.225 with SMTP id r1mr117101pds.167.1406685926205; Tue, 29 Jul 2014 19:05:26 -0700 (PDT) Received: from [192.168.1.100] ([120.159.24.15]) by mx.google.com with ESMTPSA id qf3sm893444pdb.60.2014.07.29.19.05.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jul 2014 19:05:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_958E4EEE-71D6-4480-84DC-C1A66DD12D88" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: James Winterbottom In-Reply-To: Date: Wed, 30 Jul 2014 12:05:17 +1000 Message-Id: <1114AFF3-AC52-4F91-95F0-23312F16A83B@gmail.com> References: <3B7C55D6-CE28-4B95-80D2-11AA101C53C2@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/XAm5FnvDkMx7p3LTjwRTuhzutpc Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 02:05:29 -0000 --Apple-Mail=_958E4EEE-71D6-4480-84DC-C1A66DD12D88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The only thing we have the ES 203 178 which is in draft outlining the = ESTI M/493 functional architecture. The stage-3 work isn=92t generally open, but this method is currently = list front runner. Would you like me to see if I can get ETSI to send an LS? This may take a couple of weeks because I think that many people from = the WG are currently in leave. Cheers James On 30 Jul 2014, at 12:01 pm, Bernard Aboba = wrote: > I would also favor #1, based on my understanding of current deployment = plans. >=20 > BTW, do we have a liaisons from SDOs saying they would use this? If = not, can the ECRIT WG send liaisons asking if it would be used?=20 >=20 > On Jul 28, 2014, at 1:30 PM, "James Winterbottom" = wrote: >=20 >> I am going for #1. >>=20 >>=20 >>=20 >> On 28 Jul 2014, at 11:22 pm, Marc Linsner (mlinsner) = wrote: >>=20 >>> All, >>>=20 >>> This draft was presented in a compressed time slot at the Toronto = meeting last week. James W. has indicated an urgency to move this work = forward. The chairs are asking everyone to review this from the = perspective of adopting this draft as a wg item. So, please review this = from the overall architectural value of providing emergency call routing = within a HELD req/response (protocol details and word smithing can be = done after it becomes a wg item). >>>=20 >>> Since James has indicated this work will be used by other SDOs, and = coupled with the stated urgency, the chairs request that you review the = draft and indicate to the list by COB Wednesday August 6, 2014 your = opinion: >>> I believe this work should move forward in ECRIT >>> I=92m agnostic to this work and don=92t care either way >>> I=92m opposed to this architectural change to the ECRIT model and = believe this work should not be adopted. >>>=20 >>> A indication of #2 tells the chairs that you are aware of the work = and truly don=92t have an opinion, it helps us in determining what = percentage of the wg participants have read the draft. >>>=20 >>> Thanks, >>>=20 >>> Marc & Roger >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > --Apple-Mail=_958E4EEE-71D6-4480-84DC-C1A66DD12D88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
The only thing we have the ES 203 178 which is = in draft outlining the ESTI M/493 functional architecture.
The = stage-3 work isn=92t generally open, but this method is currently list = front runner.

Would you like me to see if I can = get ETSI to send an LS?
This may take a couple of weeks = because I think that many people from the WG are currently in = leave.

Cheers
James




On 30 Jul 2014, at 12:01 = pm, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

I would also favor #1, based on = my understanding of current deployment = plans.

BTW, do we have a liaisons from SDOs = saying they would use this? If not, can the ECRIT WG send liaisons = asking if it would be used? 

On Jul 28, 2014, at 1:30 = PM, "James Winterbottom" <a.james.winterbottom@gmail.= com> wrote:

I= am going for #1.



On 28 = Jul 2014, at 11:22 pm, Marc Linsner (mlinsner) <mlinsner@cisco.com> = wrote:

All,

This draft was presented in a compressed time slot at the Toronto = meeting last week.  James W. has indicated an urgency to move this = work forward.  The chairs are asking everyone to review this from = the perspective of adopting this draft as a wg item.  So, please review this from the overall architectural value of = providing emergency call routing within a HELD req/response (protocol = details and word smithing can be done after it becomes a wg item).

Since James has indicated this work will be used by other SDOs, and = coupled with the stated urgency, the chairs request that you review the = draft and indicate to the list by COB Wednesday August 6, 2014 your = opinion:
  1. I believe this work should move forward in ECRIT
  2. I=92m = agnostic to this work and don=92t care either way
  3. I=92m opposed = to this architectural change to the ECRIT model and believe this work = should not be adopted.

A indication of #2 tells the chairs that you are aware of the work = and truly don=92t have an opinion, it helps us in determining what = percentage of the wg participants have read the draft.

Thanks,

Marc & Roger


_______________________________________________
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
<Mail = Attachment.txt>

= --Apple-Mail=_958E4EEE-71D6-4480-84DC-C1A66DD12D88-- From nobody Tue Jul 29 19:08:49 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894571B2A4F for ; Tue, 29 Jul 2014 19:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwF1T0BqUmLB for ; Tue, 29 Jul 2014 19:08:45 -0700 (PDT) Received: from BLU004-OMC2S36.hotmail.com (blu004-omc2s36.hotmail.com [65.55.111.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635A81B2A45 for ; Tue, 29 Jul 2014 19:08:45 -0700 (PDT) Received: from BLU406-EAS339 ([65.55.111.72]) by BLU004-OMC2S36.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Tue, 29 Jul 2014 19:08:44 -0700 X-TMN: [c1eE6lETblAjJLFsNRV6ZMN9u5LyUhYg3tuyfipkQOg=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-2371F7AD-7883-4C4F-AA3E-E04EAD6B6BE7" Content-Transfer-Encoding: 7bit References: <3B7C55D6-CE28-4B95-80D2-11AA101C53C2@gmail.com> <1114AFF3-AC52-4F91-95F0-23312F16A83B@gmail.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <1114AFF3-AC52-4F91-95F0-23312F16A83B@gmail.com> Date: Tue, 29 Jul 2014 19:08:38 -0700 To: James Winterbottom X-OriginalArrivalTime: 30 Jul 2014 02:08:44.0377 (UTC) FILETIME=[30C8A490:01CFAB9B] Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/fETawQRmuqzpJQGG9E-GWm-5PhY Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 02:08:47 -0000 --Apple-Mail-2371F7AD-7883-4C4F-AA3E-E04EAD6B6BE7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uZmlybWF0aW9uIHRoYXQgU0RPcyB3b3VsZCB1c2UgdGhlIHByb3Bvc2VkIHdvcmsgKGFuZCB0 aGF0IHRoZXkgd291bGQgcHJlZmVyIGl0IHRvIGFsdGVybmF0aXZlcykgd291bGQgYmUgaGVscGZ1 bC4gQW5kIHRoYXQgd291bGQgYXBwbHkgYmV5b25kIEVUU0kgaWYgdGhlcmUgYXJlIG90aGVyIFNE T3MgaW4gdGhlIHNhbWUgYm9hdC4gDQoNCj4gT24gSnVsIDI5LCAyMDE0LCBhdCA3OjA1IFBNLCAi SmFtZXMgV2ludGVyYm90dG9tIiA8YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPiB3cm90 ZToNCj4gDQo+IFRoZSBvbmx5IHRoaW5nIHdlIGhhdmUgdGhlIEVTIDIwMyAxNzggd2hpY2ggaXMg aW4gZHJhZnQgb3V0bGluaW5nIHRoZSBFU1RJIE0vNDkzIGZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJl Lg0KPiBUaGUgc3RhZ2UtMyB3b3JrIGlzbuKAmXQgZ2VuZXJhbGx5IG9wZW4sIGJ1dCB0aGlzIG1l dGhvZCBpcyBjdXJyZW50bHkgbGlzdCBmcm9udCBydW5uZXIuDQo+IA0KPiBXb3VsZCB5b3UgbGlr ZSBtZSB0byBzZWUgaWYgSSBjYW4gZ2V0IEVUU0kgdG8gc2VuZCBhbiBMUz8NCj4gVGhpcyBtYXkg dGFrZSBhIGNvdXBsZSBvZiB3ZWVrcyBiZWNhdXNlIEkgdGhpbmsgdGhhdCBtYW55IHBlb3BsZSBm cm9tIHRoZSBXRyBhcmUgY3VycmVudGx5IGluIGxlYXZlLg0KPiANCj4gQ2hlZXJzDQo+IEphbWVz DQo+IA0KPiANCj4gDQo+IA0KPj4gT24gMzAgSnVsIDIwMTQsIGF0IDEyOjAxIHBtLCBCZXJuYXJk IEFib2JhIDxiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tPiB3cm90ZToNCj4+IA0KPj4gSSB3b3Vs ZCBhbHNvIGZhdm9yICMxLCBiYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nIG9mIGN1cnJlbnQgZGVw bG95bWVudCBwbGFucy4NCj4+IA0KPj4gQlRXLCBkbyB3ZSBoYXZlIGEgbGlhaXNvbnMgZnJvbSBT RE9zIHNheWluZyB0aGV5IHdvdWxkIHVzZSB0aGlzPyBJZiBub3QsIGNhbiB0aGUgRUNSSVQgV0cg c2VuZCBsaWFpc29ucyBhc2tpbmcgaWYgaXQgd291bGQgYmUgdXNlZD8gDQo+PiANCj4+PiBPbiBK dWwgMjgsIDIwMTQsIGF0IDE6MzAgUE0sICJKYW1lcyBXaW50ZXJib3R0b20iIDxhLmphbWVzLndp bnRlcmJvdHRvbUBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEkgYW0gZ29pbmcgZm9yICMx Lg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+PiBPbiAyOCBKdWwgMjAxNCwgYXQgMTE6MjIgcG0sIE1h cmMgTGluc25lciAobWxpbnNuZXIpIDxtbGluc25lckBjaXNjby5jb20+IHdyb3RlOg0KPj4+PiAN Cj4+Pj4gQWxsLA0KPj4+PiANCj4+Pj4gVGhpcyBkcmFmdCB3YXMgcHJlc2VudGVkIGluIGEgY29t cHJlc3NlZCB0aW1lIHNsb3QgYXQgdGhlIFRvcm9udG8gbWVldGluZyBsYXN0IHdlZWsuICBKYW1l cyBXLiBoYXMgaW5kaWNhdGVkIGFuIHVyZ2VuY3kgdG8gbW92ZSB0aGlzIHdvcmsgZm9yd2FyZC4g IFRoZSBjaGFpcnMgYXJlIGFza2luZyBldmVyeW9uZSB0byByZXZpZXcgdGhpcyBmcm9tIHRoZSBw ZXJzcGVjdGl2ZSBvZiBhZG9wdGluZyB0aGlzIGRyYWZ0IGFzIGEgd2cgaXRlbS4gIFNvLCBwbGVh c2UgcmV2aWV3IHRoaXMgZnJvbSB0aGUgb3ZlcmFsbCBhcmNoaXRlY3R1cmFsIHZhbHVlIG9mIHBy b3ZpZGluZyBlbWVyZ2VuY3kgY2FsbCByb3V0aW5nIHdpdGhpbiBhIEhFTEQgcmVxL3Jlc3BvbnNl IChwcm90b2NvbCBkZXRhaWxzIGFuZCB3b3JkIHNtaXRoaW5nIGNhbiBiZSBkb25lIGFmdGVyIGl0 IGJlY29tZXMgYSB3ZyBpdGVtKS4NCj4+Pj4gDQo+Pj4+IFNpbmNlIEphbWVzIGhhcyBpbmRpY2F0 ZWQgdGhpcyB3b3JrIHdpbGwgYmUgdXNlZCBieSBvdGhlciBTRE9zLCBhbmQgY291cGxlZCB3aXRo IHRoZSBzdGF0ZWQgdXJnZW5jeSwgdGhlIGNoYWlycyByZXF1ZXN0IHRoYXQgeW91IHJldmlldyB0 aGUgZHJhZnQgYW5kIGluZGljYXRlIHRvIHRoZSBsaXN0IGJ5IENPQiBXZWRuZXNkYXkgQXVndXN0 IDYsIDIwMTQgeW91ciBvcGluaW9uOg0KPj4+PiBJIGJlbGlldmUgdGhpcyB3b3JrIHNob3VsZCBt b3ZlIGZvcndhcmQgaW4gRUNSSVQNCj4+Pj4gSeKAmW0gYWdub3N0aWMgdG8gdGhpcyB3b3JrIGFu ZCBkb27igJl0IGNhcmUgZWl0aGVyIHdheQ0KPj4+PiBJ4oCZbSBvcHBvc2VkIHRvIHRoaXMgYXJj aGl0ZWN0dXJhbCBjaGFuZ2UgdG8gdGhlIEVDUklUIG1vZGVsIGFuZCBiZWxpZXZlIHRoaXMgd29y ayBzaG91bGQgbm90IGJlIGFkb3B0ZWQuDQo+Pj4+IA0KPj4+PiBBIGluZGljYXRpb24gb2YgIzIg dGVsbHMgdGhlIGNoYWlycyB0aGF0IHlvdSBhcmUgYXdhcmUgb2YgdGhlIHdvcmsgYW5kIHRydWx5 IGRvbuKAmXQgaGF2ZSBhbiBvcGluaW9uLCBpdCBoZWxwcyB1cyBpbiBkZXRlcm1pbmluZyB3aGF0 IHBlcmNlbnRhZ2Ugb2YgdGhlIHdnIHBhcnRpY2lwYW50cyBoYXZlIHJlYWQgdGhlIGRyYWZ0Lg0K Pj4+PiANCj4+Pj4gVGhhbmtzLA0KPj4+PiANCj4+Pj4gTWFyYyAmIFJvZ2VyDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+Pj4+IEVjcml0QGlldGYub3JnDQo+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+PiANCj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEVjcml0IG1haWxp bmcgbGlzdA0KPj4+IEVjcml0QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9lY3JpdA0KPj4gPE1haWwgQXR0YWNobWVudC50eHQ+DQo+IA0K --Apple-Mail-2371F7AD-7883-4C4F-AA3E-E04EAD6B6BE7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+Q29uZmly bWF0aW9uIHRoYXQgU0RPcyB3b3VsZCB1c2UgdGhlIHByb3Bvc2VkIHdvcmsgKGFuZCB0aGF0IHRo ZXkgd291bGQgcHJlZmVyIGl0IHRvIGFsdGVybmF0aXZlcykgd291bGQgYmUgaGVscGZ1bC4gQW5k IHRoYXQgd291bGQgYXBwbHkgYmV5b25kIEVUU0kgaWYgdGhlcmUgYXJlIG90aGVyIFNET3MgaW4g dGhlIHNhbWUgYm9hdC4mbmJzcDs8L2Rpdj48ZGl2Pjxicj5PbiBKdWwgMjksIDIwMTQsIGF0IDc6 MDUgUE0sICJKYW1lcyBXaW50ZXJib3R0b20iICZsdDs8YSBocmVmPSJtYWlsdG86YS5qYW1lcy53 aW50ZXJib3R0b21AZ21haWwuY29tIj5hLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWwgY2hhcnNldD13 aW5kb3dzLTEyNTIiPjxkaXY+VGhlIG9ubHkgdGhpbmcgd2UgaGF2ZSB0aGUgRVMgMjAzIDE3OCB3 aGljaCBpcyBpbiBkcmFmdCBvdXRsaW5pbmcgdGhlIEVTVEkgTS80OTMgZnVuY3Rpb25hbCBhcmNo aXRlY3R1cmUuPC9kaXY+PGRpdj5UaGUgc3RhZ2UtMyB3b3JrIGlzbuKAmXQgZ2VuZXJhbGx5IG9w ZW4sIGJ1dCB0aGlzIG1ldGhvZCBpcyBjdXJyZW50bHkgbGlzdCBmcm9udCBydW5uZXIuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5Xb3VsZCB5b3UgbGlrZSBtZSB0byBzZWUgaWYgSSBjYW4gZ2V0 IEVUU0kgdG8gc2VuZCBhbiBMUz88L2Rpdj48ZGl2PlRoaXMgbWF5IHRha2UgYSBjb3VwbGUgb2Yg d2Vla3MgYmVjYXVzZSBJIHRoaW5rIHRoYXQgbWFueSBwZW9wbGUgZnJvbSB0aGUgV0cgYXJlIGN1 cnJlbnRseSBpbiBsZWF2ZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkNoZWVyczwvZGl2Pjxk aXY+SmFtZXM8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rp dj48YnI+PGRpdj48ZGl2Pk9uIDMwIEp1bCAyMDE0LCBhdCAxMjowMSBwbSwgQmVybmFyZCBBYm9i YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb20iPmJlcm5hcmRf YWJvYmFAaG90bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxtZXRhIGh0dHAtZXF1 aXY9ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48ZGl2 IGRpcj0iYXV0byI+PGRpdj5JIHdvdWxkIGFsc28gZmF2b3IgIzEsIGJhc2VkIG9uIG15IHVuZGVy c3RhbmRpbmcgb2YgY3VycmVudCBkZXBsb3ltZW50IHBsYW5zLjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+QlRXLCBkbyB3ZSBoYXZlIGEgbGlhaXNvbnMgZnJvbSBTRE9zIHNheWluZyB0aGV5IHdv dWxkIHVzZSB0aGlzPyBJZiBub3QsIGNhbiB0aGUgRUNSSVQgV0cgc2VuZCBsaWFpc29ucyBhc2tp bmcgaWYgaXQgd291bGQgYmUgdXNlZD8mbmJzcDs8L2Rpdj48ZGl2Pjxicj5PbiBKdWwgMjgsIDIw MTQsIGF0IDE6MzAgUE0sICJKYW1lcyBXaW50ZXJib3R0b20iICZsdDs8YSBocmVmPSJtYWlsdG86 YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tIj5hLmphbWVzLndpbnRlcmJvdHRvbUBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sIGNoYXJz ZXQ9d2luZG93cy0xMjUyIj5JIGFtIGdvaW5nIGZvciAjMS48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2Pjxicj48ZGl2PjxkaXY+T24gMjggSnVsIDIwMTQsIGF0IDExOjIyIHBtLCBN YXJjIExpbnNuZXIgKG1saW5zbmVyKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1saW5zbmVyQGNpc2Nv LmNvbSI+bWxpbnNuZXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+PGJyIGNsYXNzPSJB cHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCg0KPG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9 V2luZG93cy0xMjUyIj4NCg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4N CjxkaXY+QWxsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBkcmFmdCB3YXMg cHJlc2VudGVkIGluIGEgY29tcHJlc3NlZCB0aW1lIHNsb3QgYXQgdGhlIFRvcm9udG8gbWVldGlu ZyBsYXN0IHdlZWsuICZuYnNwO0phbWVzIFcuIGhhcyBpbmRpY2F0ZWQgYW4gdXJnZW5jeSB0byBt b3ZlIHRoaXMgd29yayBmb3J3YXJkLiAmbmJzcDtUaGUgY2hhaXJzIGFyZSBhc2tpbmcgZXZlcnlv bmUgdG8gcmV2aWV3IHRoaXMgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgYWRvcHRpbmcgdGhpcyBk cmFmdCBhcyBhIHdnIGl0ZW0uDQogJm5ic3A7U28sIHBsZWFzZSByZXZpZXcgdGhpcyBmcm9tIHRo ZSBvdmVyYWxsIGFyY2hpdGVjdHVyYWwgdmFsdWUgb2YgcHJvdmlkaW5nIGVtZXJnZW5jeSBjYWxs IHJvdXRpbmcgd2l0aGluIGEgSEVMRCByZXEvcmVzcG9uc2UgKHByb3RvY29sIGRldGFpbHMgYW5k IHdvcmQgc21pdGhpbmcgY2FuIGJlIGRvbmUgYWZ0ZXIgaXQgYmVjb21lcyBhIHdnIGl0ZW0pLjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2luY2UgSmFtZXMgaGFzIGluZGljYXRlZCB0 aGlzIHdvcmsgd2lsbCBiZSB1c2VkIGJ5IG90aGVyIFNET3MsIGFuZCBjb3VwbGVkIHdpdGggdGhl IHN0YXRlZCB1cmdlbmN5LCB0aGUgY2hhaXJzIHJlcXVlc3QgdGhhdCB5b3UgcmV2aWV3IHRoZSBk cmFmdCBhbmQgaW5kaWNhdGUgdG8gdGhlIGxpc3QgYnkgQ09CIFdlZG5lc2RheSBBdWd1c3QgNiwg MjAxNCB5b3VyIG9waW5pb246PC9kaXY+DQo8b2w+DQo8bGk+SSBiZWxpZXZlIHRoaXMgd29yayBz aG91bGQgbW92ZSBmb3J3YXJkIGluIEVDUklUPC9saT48bGk+SeKAmW0gYWdub3N0aWMgdG8gdGhp cyB3b3JrIGFuZCBkb27igJl0IGNhcmUgZWl0aGVyIHdheTwvbGk+PGxpPknigJltIG9wcG9zZWQg dG8gdGhpcyBhcmNoaXRlY3R1cmFsIGNoYW5nZSB0byB0aGUgRUNSSVQgbW9kZWwgYW5kIGJlbGll dmUgdGhpcyB3b3JrIHNob3VsZCBub3QgYmUgYWRvcHRlZC48L2xpPjwvb2w+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5BIGluZGljYXRpb24gb2YgIzIgdGVsbHMgdGhlIGNoYWlycyB0aGF0IHlv dSBhcmUgYXdhcmUgb2YgdGhlIHdvcmsgYW5kIHRydWx5IGRvbuKAmXQgaGF2ZSBhbiBvcGluaW9u LCBpdCBoZWxwcyB1cyBpbiBkZXRlcm1pbmluZyB3aGF0IHBlcmNlbnRhZ2Ugb2YgdGhlIHdnIHBh cnRpY2lwYW50cyBoYXZlIHJlYWQgdGhlIGRyYWZ0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TWFyYyAmYW1wOyBS b2dlcjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+RWNy aXQgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRA aWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8 L2E+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5FY3JpdCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJy PjxzcGFuPjxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRAaWV0Zi5vcmc8L2E+ PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Vjcml0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0 PC9hPjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2PjxzcGFuPiZsdDtNYWlsIEF0dGFjaG1l bnQudHh0Jmd0Ozwvc3Bhbj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvYmxvY2txdW90 ZT48L2JvZHk+PC9odG1sPg== --Apple-Mail-2371F7AD-7883-4C4F-AA3E-E04EAD6B6BE7-- From nobody Wed Jul 30 05:41:37 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177611A001E for ; Wed, 30 Jul 2014 05:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPhrkW593RUF for ; Wed, 30 Jul 2014 05:41:35 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E241A000B for ; Wed, 30 Jul 2014 05:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1609; q=dns/txt; s=iport; t=1406724095; x=1407933695; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DFKaHpbkhPsjHocBDogTvlQKq7u96mWVufmBLm5ugoQ=; b=KmuYuiswIIXe9CiXXPsZMYbnIwDWDQxuTvYQQmi1FTzDDSSDTJ4JtRk7 SJOM6Dpu2qHbCU1FrkBoZmZgbKj7/VY6IE5KHKLgxWuJVrpMYZIOSThPS Umv1jGKEXso/IrjH0XPZWtKiyYXnK0/bK3z/rzg4DC6eo02yFjha+Rw/e E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFADXn2FOtJV2R/2dsb2JhbABZgkdHgS3TAwGBDxZ3g3oKAQEEeRACAQgDAUIyJQIEAQ2IR8AiF49MB4RKAQSbZJRTg0mCMQ X-IronPort-AV: E=Sophos;i="5.01,764,1400025600"; d="scan'208,217";a="343861644" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2014 12:41:34 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6UCfYaf028512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 12:41:34 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.152]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 07:41:34 -0500 From: "Marc Linsner (mlinsner)" To: Bernard Aboba , James Winterbottom Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqmcDQBOWz8idXUOAditSmLV3Jpu2RG4AgAHu+ACAAAEIgIAAAO8AgABtxYA= Date: Wed, 30 Jul 2014 12:41:33 +0000 Message-ID: References: <3B7C55D6-CE28-4B95-80D2-11AA101C53C2@gmail.com> <1114AFF3-AC52-4F91-95F0-23312F16A83B@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.248.165] Content-Type: multipart/alternative; boundary="_000_CFFE5FF85D771mlinsnerciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/VTR1w-YrCnT2t6g97wbs0Kg4i-Q Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 12:41:36 -0000 --_000_CFFE5FF85D771mlinsnerciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Confirmation that SDOs would use the proposed work (and that they would pre= fer it to alternatives) would be helpful. And that would apply beyond ETSI = if there are other SDOs in the same boat. +1 from the wg chairs POV also! -Marc- --_000_CFFE5FF85D771mlinsnerciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <409C67371B0654468480B8CF7C4064CC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


Confirmation that SDOs would use the proposed work (and that they woul= d prefer it to alternatives) would be helpful. And that would apply beyond = ETSI if there are other SDOs in the same boat. 

+1 from the wg chairs POV also!

-Marc-
--_000_CFFE5FF85D771mlinsnerciscocom_-- From nobody Wed Jul 30 07:32:06 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA4F1A00A6 for ; Wed, 30 Jul 2014 07:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MxI_FKbXfqb for ; Wed, 30 Jul 2014 07:32:01 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3689E1A00AD for ; Wed, 30 Jul 2014 07:32:01 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id v6so961028lbi.10 for ; Wed, 30 Jul 2014 07:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7iIZn7kp4R9DYc7BvjSQrGhHFQ5Yy0/uQg9uwIlsdyk=; b=hiwuKvbWTcf42w6xo8RtlUGv89c7LlyXNT+SC/jPr86dXXKxLu9TnZ3eU6XE+65/QW rCnq2K1VE+dvQ8pkdQC7/xKeB8oOIp4/vl5eRvHwdDeUJj8sWU26nKPmGY9m4yJu8NEb 1PPasERlPWgWtU6n69nFdlPsZWQ1+qioT695RND03k5ll6GZZWXQb4mSKWKTDJ1uIBm1 mZ2XaKy45eSIQAtr9MR3RAHIs4PbfFwWoct7ZPzOwD6cL6S8G8OOT5kOcMlt4Dh0YIIS Nr9ST//uAJgVTwRKUJQUdsIB1nc2jB7ubG6xllsNQpVqDGYQToygaw5NMKJuQ1+Vz9xO CRPA== MIME-Version: 1.0 X-Received: by 10.112.165.1 with SMTP id yu1mr4915829lbb.68.1406730719223; Wed, 30 Jul 2014 07:31:59 -0700 (PDT) Received: by 10.114.75.194 with HTTP; Wed, 30 Jul 2014 07:31:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Jul 2014 16:31:59 +0200 Message-ID: From: Laura Liess To: "Marc Linsner (mlinsner)" Content-Type: multipart/alternative; boundary=001a11345926d065bf04ff6a04ab Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/MmkbpzoalK9A17-KJaWwlCMeGd4 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:32:03 -0000 --001a11345926d065bf04ff6a04ab Content-Type: text/plain; charset=ISO-8859-1 I support #1 because LOST is not going to be deployed in some European countries. Additionaly, in countries with multiple emergency services providers, the proposal makes things easier for access network providers because they would need a trust relationship with only one emergency service provider. With LOST, they would need trust relationships with multiple emergency service providers. Thank you Laura 2014-07-28 15:22 GMT+02:00 Marc Linsner (mlinsner) : > All, > > This draft was presented in a compressed time slot at the Toronto > meeting last week. James W. has indicated an urgency to move this work > forward. The chairs are asking everyone to review this from the > perspective of adopting this draft as a wg item. So, please review this > from the overall architectural value of providing emergency call routing > within a HELD req/response (protocol details and word smithing can be done > after it becomes a wg item). > > Since James has indicated this work will be used by other SDOs, and > coupled with the stated urgency, the chairs request that you review the > draft and indicate to the list by COB Wednesday August 6, 2014 your opinion: > > 1. I believe this work should move forward in ECRIT > 2. I'm agnostic to this work and don't care either way > 3. I'm opposed to this architectural change to the ECRIT model and > believe this work should not be adopted. > > > A indication of #2 tells the chairs that you are aware of the work and > truly don't have an opinion, it helps us in determining what percentage of > the wg participants have read the draft. > > Thanks, > > Marc & Roger > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > --001a11345926d065bf04ff6a04ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support #1 because LOST is not going to be dep= loyed in some European countries.
Additionaly, in countries with multip= le  emergency services providers, the proposal makes things easier for= access network providers because they would need a trust relationship with= only one emergency service provider. With LOST, they would need  trus= t relationships with multiple emergency service providers. 
 
Thank you
Laura 


2014-07-28 15:22 GMT+02:00 Marc= Linsner (mlinsner) <mlinsner@cisco.com>:
All,

This draft was presented in a compressed time slot at the Toronto meet= ing last week.  James W. has indicated an urgency to move this work fo= rward.  The chairs are asking everyone to review this from the perspec= tive of adopting this draft as a wg item.  So, please review this from the overall architectural value of provi= ding emergency call routing within a HELD req/response (protocol details an= d word smithing can be done after it becomes a wg item).

Since James has indicated this work will be used by other SDOs, and co= upled with the stated urgency, the chairs request that you review the draft= and indicate to the list by COB Wednesday August 6, 2014 your opinion:
  1. I believe this work should move forward in ECRIT
  2. I’m agno= stic to this work and don’t care either way
  3. I’m opposed= to this architectural change to the ECRIT model and believe this work shou= ld not be adopted.

A indication of #2 tells the chairs that you are aware of the work and= truly don’t have an opinion, it helps us in determining what percent= age of the wg participants have read the draft.

Thanks,

Marc & Roger



_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ecrit


--001a11345926d065bf04ff6a04ab-- From nobody Wed Jul 30 07:50:56 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467B51A016D for ; Wed, 30 Jul 2014 07:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi101frMkkyh for ; Wed, 30 Jul 2014 07:50:42 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949751A00A7 for ; Wed, 30 Jul 2014 07:50:13 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id e1609d35.2aeb4d441940.131032.00-2482.369424.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 30 Jul 2014 14:50:06 +0000 (UTC) X-MXL-Hash: 53d9061e4d9423d0-78d60d1a90eec754ea099218c4f8470ad4d06950 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 31609d35.0.130918.00-2169.369127.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 30 Jul 2014 14:49:56 +0000 (UTC) X-MXL-Hash: 53d90614409b7754-99eee4e1a8fb0446000c048c1f5f145ac8f0be98 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6UEo1MX010520; Wed, 30 Jul 2014 10:50:02 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s6UEnt4h010380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2014 10:49:57 -0400 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 30 Jul 2014 14:49:46 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.50]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 10:49:46 -0400 From: "DOLLY, MARTIN C" To: Laura Liess , "Marc Linsner (mlinsner)" Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPrAMF/8htkPjEEkOQKe82SbAUUpu4slSA Date: Wed, 30 Jul 2014 14:49:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.81.106] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E83656031917A7MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=U/kl+5Xu c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=NX6IKKGed2YA:10 a=BuP23OHSGpEA:10 a=ofMgfj31e3cA:10 a=VHm] X-AnalysisOut: [NBksX17gA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=avFN9Llz0vSBe5q] X-AnalysisOut: [dTE4A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA] X-AnalysisOut: [:10 a=Mgs_jRke6sl28j_Q:21 a=oPcTfeIpcbYC2JZ_:21 a=yMhMjlub] X-AnalysisOut: [AAAA:8 a=SSmOFEACAAAA:8 a=jFyeaTpflAGWTO0f5_0A:9 a=gKO2Hq4] X-AnalysisOut: [RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hU] X-AnalysisOut: [A:10 a=tXsnliwV7b4A:10 a=UjqNRVz0_LTPrihA:21 a=IBFR7Few_wA] X-AnalysisOut: [CcaP6:21 a=wnXaEOkedJkARkL8:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/u5dbMUDpvRDS_lbbMAxp6S1TEfc Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:50:50 -0000 --_000_E42CCDDA6722744CB241677169E83656031917A7MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for option #1 From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Laura Liess Sent: Wednesday, July 30, 2014 10:32 AM To: Marc Linsner (mlinsner) Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 I support #1 because LOST is not going to be deployed in some European coun= tries. Additionaly, in countries with multiple emergency services providers, the = proposal makes things easier for access network providers because they woul= d need a trust relationship with only one emergency service provider. With = LOST, they would need trust relationships with multiple emergency service = providers. Thank you Laura 2014-07-28 15:22 GMT+02:00 Marc Linsner (mlinsner) >: All, This draft was presented in a compressed time slot at the Toronto meeting l= ast week. James W. has indicated an urgency to move this work forward. Th= e chairs are asking everyone to review this from the perspective of adoptin= g this draft as a wg item. So, please review this from the overall archite= ctural value of providing emergency call routing within a HELD req/response= (protocol details and word smithing can be done after it becomes a wg item= ). Since James has indicated this work will be used by other SDOs, and coupled= with the stated urgency, the chairs request that you review the draft and = indicate to the list by COB Wednesday August 6, 2014 your opinion: 1. I believe this work should move forward in ECRIT 2. I'm agnostic to this work and don't care either way 3. I'm opposed to this architectural change to the ECRIT model and belie= ve this work should not be adopted. A indication of #2 tells the chairs that you are aware of the work and trul= y don't have an opinion, it helps us in determining what percentage of the = wg participants have read the draft. Thanks, Marc & Roger _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_E42CCDDA6722744CB241677169E83656031917A7MISOUT7MSGUSRDB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for option #1=

 <= /p>

From: Ecrit [m= ailto:ecrit-bounces@ietf.org] On Behalf Of Laura Liess
Sent: Wednesday, July 30, 2014 10:32 AM
To: Marc Linsner (mlinsner)
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04=

 

I support #1 because LOST is not going to be deploye= d in some European countries.
Additionaly, in countries with multiple  emergency services providers,= the proposal makes things easier for access network providers because they= would need a trust relationship with only one emergency service provider. = With LOST, they would need  trust relationships with multiple emergency service providers. 
 

Thank you

Laura 

 

2014-07-28 15:22 GMT+02:00 Marc Linsner (mlinsne= r) <mlinsner@cis= co.com>:

All,

 

This draft was presented in= a compressed time slot at the Toronto meeting last week.  James W. ha= s indicated an urgency to move this work forward.  The chairs are asking everyone to review this from the perspective of adopting this d= raft as a wg item.  So, please review this from the overall architectu= ral value of providing emergency call routing within a HELD req/response (p= rotocol details and word smithing can be done after it becomes a wg item).

 

Since James has indicated t= his work will be used by other SDOs, and coupled with the stated urgency, t= he chairs request that you review the draft and indicate to the list by COB Wednesday August 6, 2014 your opinion:

  1. I believe this work should move forward in ECRIT
  2. I’m agnostic to this work and don’t care either wa= y
  3. I’m opposed to this architectural change to the ECRIT mo= del and believe this work should not be adopted.

    4.  

    A indication of #2 tells th= e chairs that you are aware of the work and truly don’t have an opini= on, it helps us in determining what percentage of the wg participants have read the draft.

     

    Thanks,

     

    Marc & Roger=

     

     


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ecrit

 

--_000_E42CCDDA6722744CB241677169E83656031917A7MISOUT7MSGUSRDB_-- From nobody Wed Jul 30 08:20:26 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995AC1A02A3 for ; Wed, 30 Jul 2014 08:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1p7UP-QmCai for ; Wed, 30 Jul 2014 08:20:14 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9561A027C for ; Wed, 30 Jul 2014 08:18:31 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id s6UFIMlb008628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 30 Jul 2014 08:18:22 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.252]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 08:18:21 -0700 From: Roger Marshall To: "Marc Linsner (mlinsner)" , Bernard Aboba , James Winterbottom Thread-Topic: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqmcDQBOWz8idXUOAditSmLV3Jpu2ZfUAgAHu+ACAAAEIgIAAAO8AgACw1oD//7YxoA== Date: Wed, 30 Jul 2014 15:18:20 +0000 Message-ID: References: <3B7C55D6-CE28-4B95-80D2-11AA101C53C2@gmail.com> <1114AFF3-AC52-4F91-95F0-23312F16A83B@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10201E5FSEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/sgTua2Omd69vdsSHZjyktMLNMK0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:20:17 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10201E5FSEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 agreed - ecrit would like to see confirmation of SDO use. From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner (mlin= sner) Sent: Wednesday, July 30, 2014 5:42 AM To: Bernard Aboba; James Winterbottom Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 Confirmation that SDOs would use the proposed work (and that they would pre= fer it to alternatives) would be helpful. And that would apply beyond ETSI = if there are other SDOs in the same boat. +1 from the wg chairs POV also! -Marc- CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10201E5FSEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 agreed – ecr= it would like to see confirmation of SDO use.

 <= /p>

From: Ecrit [m= ailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner (mlinsner)
Sent: Wednesday, July 30, 2014 5:42 AM
To: Bernard Aboba; James Winterbottom
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04=

 

 

 

Confirmation that SDOs woul= d use the proposed work (and that they would prefer it to alternatives) wou= ld be helpful. And that would apply beyond ETSI if there are other SDOs in the same boat. 

 

+1 from the wg chairs P= OV also!

 

-Marc-

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC10201E5FSEAEXMB2telecom_-- From nobody Thu Jul 31 05:11:05 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283951ABB22 for ; Thu, 31 Jul 2014 05:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDzFgzF_weGT for ; Thu, 31 Jul 2014 05:10:55 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2CB1B27A7 for ; Thu, 31 Jul 2014 05:09:29 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id EC9BC8081FF68; Thu, 31 Jul 2014 12:09:23 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6VC8l9m015002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jul 2014 14:09:26 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 31 Jul 2014 14:08:43 +0200 From: "DRAGE, Keith (Keith)" To: "Rosen, Brian" , Marc Linsner Thread-Topic: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPq2/hvul/7X6m4ESpjEJWFLKjPpu3a2AAgAATVACAAO5ocA== Date: Thu, 31 Jul 2014 12:08:42 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B2166BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <05074C92-4D02-48A6-83CC-C85CCB6ACADA@gmail.com> <96EF8E43-7039-4ADC-AB5B-1289EDD6F32C@neustar.biz> <1C1D0F18-2C06-4152-A686-BE61F9CBB425@neustar.biz> <1C2CE0AD-5D2F-4EF3-BBFF-E0067E22A82B@neustar.biz> In-Reply-To: <1C2CE0AD-5D2F-4EF3-BBFF-E0067E22A82B@neustar.biz> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/S_1Kvx_SIVKoluVFZ8sJ5yaXI64 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Discussion on draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 12:11:03 -0000 I'd ask why do you think you are in a better position to know. I supsect I could make the same assertion against the NENA work with much t= he same level of confidence. I do know what the asserted position of at least a couple of the European r= egulators is. Keith=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian > Sent: 29 July 2014 23:22 > To: Marc Linsner > Cc: ecrit_ietf.org > Subject: Re: [Ecrit] Discussion on=20 > draft-winterbottom-ecrit-priv-loc-04 >=20 > Let's also qualify that "In Europe" is this specific ETSI=20 > work. There is other work (EENA) that uses the IETF approach=20 > holistically. It may be that the ETSI work succeeds and is=20 > deployed in some countries for some time, but I would not=20 > recommend betting against the EENA approach long term. >=20 > Brian >=20 > On Jul 29, 2014, at 5:13 PM, Marc Linsner (mlinsner)=20 > wrote: >=20 > >=20 > >=20 > > -----Original Message----- > > From: James Winterbottom > > Date: Tuesday, July 29, 2014 at 4:58 PM > > To: "Rosen, Brian" > > Cc: Randall Gellens , "ecrit_ietf.org" > > > > Subject: Re: [Ecrit] Discussion on=20 > > draft-winterbottom-ecrit-priv-loc-04 > >=20 > >> Brian, > >>=20 > >> If this really is your sentiment then why are we having=20 > this debate? > >> By your own admission LbyR in LoST requires at least some rough=20 > >> location, this doesn=B9t meet the requirements we have outlined. > >> The routing returned in HELD will meet the requirements in Europe,=20 > >> can=B9t we just get on with producing a spec please? > >=20 > >=20 > > The problem is the requirements are for the most part fallacious. > >=20 > > When queried why the VSP can=B9t have LbyV if it=B9s covered by their=20 > > EULA, the answer is, in that case they can have LbyV. > >=20 > > -Marc- > >=20 > >=20 > >=20 > >>=20 > >> Cheers > >> James > >>=20 > >>=20 > >>>>=20 > >>>>=20 > >>>> Right, it's a query no matter which entity does it, or which=20 > >>>> protocol is used. > >>> Yeah. That=B9s why even though I have a preference for=20 > >>> LoST-does-LbyR, I am not really against HELD-returns-route. > >>>=20 > >>> Brian > >>>=20 > >>>=20 > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From nobody Thu Jul 31 05:45:42 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5701B278C for ; Thu, 31 Jul 2014 05:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgcndM40_owf for ; Thu, 31 Jul 2014 05:45:38 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4C31A0AB4 for ; Thu, 31 Jul 2014 05:45:36 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 31 Jul 2014 14:45:32 +0200 X-IronPort-AV: E=Sophos;i="5.01,772,1400018400"; d="scan'208,217";a="507375248" Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 31 Jul 2014 14:45:32 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 31 Jul 2014 14:45:32 +0200 From: To: , Date: Thu, 31 Jul 2014 14:45:31 +0200 Thread-Topic: draft-winterbottom-ecrit-priv-loc-04 Thread-Index: AQHPqmcDQBOWz8idXUOAditSmLV3Jpu6JWWw Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E2819CD43F@HE113667.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_058CE00BD4D6B94FAD033A2439EA1E4B01E2819CD43FHE113667eme_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/e9kY9TTKEpZ0FuGUMJGBYGcr79w Subject: Re: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 12:45:41 -0000 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01E2819CD43FHE113667eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I support #1 Best Regards Roland Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von Marc Linsner (mli= nsner) Gesendet: Montag, 28. Juli 2014 15:23 An: ecrit@ietf.org Betreff: [Ecrit] draft-winterbottom-ecrit-priv-loc-04 All, This draft was presented in a compressed time slot at the Toronto meeting l= ast week. James W. has indicated an urgency to move this work forward. Th= e chairs are asking everyone to review this from the perspective of adoptin= g this draft as a wg item. So, please review this from the overall archite= ctural value of providing emergency call routing within a HELD req/response= (protocol details and word smithing can be done after it becomes a wg item= ). Since James has indicated this work will be used by other SDOs, and coupled= with the stated urgency, the chairs request that you review the draft and = indicate to the list by COB Wednesday August 6, 2014 your opinion: 1. I believe this work should move forward in ECRIT 2. I'm agnostic to this work and don't care either way 3. I'm opposed to this architectural change to the ECRIT model and believ= e this work should not be adopted. A indication of #2 tells the chairs that you are aware of the work and trul= y don't have an opinion, it helps us in determining what percentage of the = wg participants have read the draft. Thanks, Marc & Roger --_000_058CE00BD4D6B94FAD033A2439EA1E4B01E2819CD43FHE113667eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

=

I support #1

=

 

Best Regards

 

Roland

 

<= div>

Von: Ecrit [mailto:ecrit-bounces@ietf.org] = Im Auftrag von Marc Linsner (mlinsner)
Gesendet: Montag, 2= 8. Juli 2014 15:23
An: ecrit@ietf.org
Betreff: [Ecrit] = draft-winterbottom-ecrit-priv-loc-04

 

All,

 <= /span>

This draft was presented in = a compressed time slot at the Toronto meeting last week.  James W. has= indicated an urgency to move this work forward.  The chairs are askin= g everyone to review this from the perspective of adopting this draft as a = wg item.  So, please review this from the overall architectural value = of providing emergency call routing within a HELD req/response (protocol de= tails and word smithing can be done after it becomes a wg item).=

 

Since James has indicated this work w= ill be used by other SDOs, and coupled with the stated urgency, the chairs = request that you review the draft and indicate to the list by COB Wednesday= August 6, 2014 your opinion:

  1. I believe this work should move f= orward in ECRIT
  2. = I’m agnostic to this work and don’t care either way<= /span>
  3. I’m opposed to this a= rchitectural change to the ECRIT model and believe this work should not be = adopted.

&= nbsp;

A indication of = #2 tells the chairs that you are aware of the work and truly don’t ha= ve an opinion, it helps us in determining what percentage of the wg partici= pants have read the draft.

 

= Thanks,

&nbs= p;

Marc & Roger

 

 

<= /div>
= --_000_058CE00BD4D6B94FAD033A2439EA1E4B01E2819CD43FHE113667eme_--