From hannes.tschofenig@gmx.net Wed Jul 3 09:39:21 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2103E21F994C for ; Wed, 3 Jul 2013 09:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFH4glkVbmqZ for ; Wed, 3 Jul 2013 09:39:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6F30521F9E15 for ; Wed, 3 Jul 2013 09:39:13 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MHdb8-1UvX5A32Cq-003Mnn for ; Wed, 03 Jul 2013 18:39:12 +0200 Received: (qmail invoked by alias); 03 Jul 2013 16:39:12 -0000 Received: from unknown (EHLO [10.255.132.88]) [194.251.119.201] by mail.gmx.net (mp027) with SMTP; 03 Jul 2013 18:39:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+IqH4wT5OITNqTdiJkCGm/j4i0upqRSqyLWA1RRL TeXHf9lJxITu8u Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Hannes Tschofenig In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012140A09D38@SISPE7MB1.commscope.com> Date: Wed, 3 Jul 2013 19:39:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9D1BA7B2-E3F7-432A-BCEA-0FACE9A6E8A4@gmx.net> References: <5A55A45AE77F5941B18E5457ECAC8188012140A09D38@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Additional Data -09 Data Provider Schema X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 16:39:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Thanks James for catching this bug. I have fixed it in version -10. Ciao Hannes On Jun 21, 2013, at 9:12 AM, Winterbottom, James wrote: > Hi Hannes, > =20 > Did you respond to this? > If you did I apologize as I don=E2=80=99t seem to have the response. > If not, could you confirm that these are a problem and are in the = pipeline to be fixed please? > =20 > Cheers > James > =20 > =20 > From: Winterbottom, James=20 > Sent: Monday, 3 June 2013 1:45 PM > To: ecrit@ietf.org > Subject: Additional Data -09 Data Provider Schema > =20 > Hi Hannes, > =20 > The Data Provider Information sections in the document are covered in = section 3.1. > Section 3.1.8 =E2=80=9CSubcontractor Principal=E2=80=9D and Section = 3.1.9 =E2=80=9CSubcontractor Priority=E2=80=9D seem to be missing from = the element sequence defined in the emergencyCall.ProviderInfo schema = defined in section 6.1. > =20 > Cheers > James > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR1FOuAAoJEGhJURNOOiAtdjwH/0NKRDLTAHlrD4fPi760sUXy ZAzadR7BGzmqD66zWFXoXET2ndTOSYKc5PrSVxkLS9RIgD0ksJZkOy2HRuIqaYTK XWpC9RJEnbKW+WTYDV/erJRbvCoewLzAOQF/TOTo+FSOGWqIv5T6ObTMARD4uNW1 aqmedDj44ms+9Xbnd9V0DKvCR3iyY6Z6RSAHfityXB8qNkUxr0Z/Yh9SNx74CUhh VgAssEVCfNP+Izjyr6t8ZBGn90F0aw84xiCmdIzYVkMF476CjwyFuCRiarDXu5GD KzxWkKNr0PSkmXbXUj/jWwhByVBHEHTwzvAI7gRZhiWAOsH8QwQdDKs0wL6zYL4=3D =3DJmVR -----END PGP SIGNATURE----- From shida@ntt-at.com Mon Jul 8 12:56:42 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B32621F9D9D for ; Mon, 8 Jul 2013 12:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.851 X-Spam-Level: X-Spam-Status: No, score=-99.851 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhTiz6XjSvQv for ; Mon, 8 Jul 2013 12:56:33 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id D150D21F9D8F for ; Mon, 8 Jul 2013 12:56:33 -0700 (PDT) Received: from [50.152.169.249] (port=55753 helo=[192.168.1.5]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1UwHXz-0006Bb-V1; Mon, 08 Jul 2013 14:56:32 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Mon, 8 Jul 2013 12:56:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <581E085DEB6A444093CDAEA4C4EE48181356EA58@xmb-rcd-x08.cisco.com> <51CAFAF7.3030705@alum.mit.edu> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.5]) [50.152.169.249]:55753 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 8 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 19:56:42 -0000 +1 On Jun 28, 2013, at 4:45 AM, DOLLY, MARTIN C wrote: > +1 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Paul Kyzivat > Sent: Wednesday, June 26, 2013 10:30 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 >=20 > I support this draft, as is. >=20 > Thanks, > Paul >=20 > On 6/26/13 8:43 AM, Marc Linsner (mlinsner) wrote: >> At the Orlando meeting there was consensus that this work move = forward >> along with some volunteers to tweak the text. Since we've seen no >> discussion or text being tweaked, we're wondering if such tweaking is >> still necessary? >>=20 >> If you needed the impetus, how about: >>=20 >> This is a notice that we are starting a WGLC on this draft. Please >> submit comments to this list by COB on Thursday, July 11, 2013. >>=20 >>=20 >> Thanks, >>=20 >> Marc & Roger >>=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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From atle.monrad@ericsson.com Mon Jul 8 22:39:17 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A4321F9DBC for ; Mon, 8 Jul 2013 22:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3852ET7LFOT for ; Mon, 8 Jul 2013 22:39:13 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9C34B21F9F42 for ; Mon, 8 Jul 2013 22:39:12 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-bf-51dba1fd6031 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 55.CA.19388.DF1ABD15; Tue, 9 Jul 2013 07:39:10 +0200 (CEST) Received: from ESESSMB203.ericsson.se ([169.254.3.224]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Tue, 9 Jul 2013 07:39:07 +0200 From: Atle Monrad To: Shida Schubert Thread-Topic: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 Thread-Index: AQHOfBVHGYvuuybYFUOSSr3DvMYzaZlb1ReI Date: Tue, 9 Jul 2013 05:39:07 +0000 Message-ID: <211sukonob2vtu020806s80d.1373348344885@email.android.com> References: <581E085DEB6A444093CDAEA4C4EE48181356EA58@xmb-rcd-x08.cisco.com> <51CAFAF7.3030705@alum.mit.edu> , In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: nb-NO X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvre6/hbcDDe4uYrNoXPSU1eLQg6fs Fr8PzWN1YPZ42T+H0WPJkp9MHj2XZjMGMEdx2aSk5mSWpRbp2yVwZXS1X2cqWMdXsXuPTgPj U+4uRk4OCQETiSurO9kgbDGJC/fWA9lcHEIChxklPpx4yAThLGaUODShlxGkik1AR+Lczzus ILaIgKrEghePmbsYOTiYBTwldr6xBgkLC9hLzJlxgAkkLCLgIPFnARNEtZHExsPzwDpZBFQk 1qz9yg5i8wq4Sew8cJYVYtUHRol9P7eDNXAK2EncOnqaFWQOo4CsxNwmXpAws4C4xIyjd1gg bhaQWLLnPDOELSrx8vE/VogaHYkFuz+xQdjaEssWvmaG2CUocXLmE5YJjKKzkIyahaRlFpKW WUhaFjCyrGJkz03MzEkvN9/ECIyNg1t+G+xg3HRf7BCjNAeLkjjvZr0zgUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoYt2/e7u/p27rvwcI93NP/rti8p/Pz9fvTq16ImktKKcyYPDX5ZNaJ iECe9/MtlQVzHG7EmWnWRDDtCg59OMmNe1Xi2Yshz2qFZG4vs2grkBZZY+9r8eZ+y59Fp6Uf HX/Jw7X6Fp+uu1jlNt2wypZt67JvPEnj9N5anL12Z3RdneKVvA7OpSemKLEUZyQaajEXFScC AG+Xgo1bAgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 05:39:17 -0000 Support the draft going forward as is \atle Sent from Moxier Mail (http://www.moxier.com) ----- Opprinnelig melding ----- Fra: Shida Schubert Til: "DOLLY, MARTIN C" Kopi: "ecrit@ietf.org" Sendt: 08.07.2013 9:56 PM Emne: Re: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 +1 On Jun 28, 2013, at 4:45 AM, DOLLY, MARTIN C wrote: > +1 > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: Wednesday, June 26, 2013 10:30 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] WGLC - draft-ietf-ecrit-country-emg-urn-00 > > I support this draft, as is. > > Thanks, > Paul > > On 6/26/13 8:43 AM, Marc Linsner (mlinsner) wrote: >> At the Orlando meeting there was consensus that this work move forward >> along with some volunteers to tweak the text. Since we've seen no >> discussion or text being tweaked, we're wondering if such tweaking is >> still necessary? >> >> If you needed the impetus, how about: >> >> This is a notice that we are starting a WGLC on this draft. Please >> submit comments to this list by COB on Thursday, July 11, 2013. >> >> >> 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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Jul 9 05:47:56 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE83621F9CB1 for ; Tue, 9 Jul 2013 05:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgNCRiZzSD3p for ; Tue, 9 Jul 2013 05:47:49 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C111E80E1 for ; Tue, 9 Jul 2013 05:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=Mime-Version:Message-Id:To:References:Date:Subject:Content-Type:From; bh=LRIeXH5ZJGPAHi3KzZrs9e+qaDufgS7Q1B80v7L5Lpc=; b=TyynwJuMfzU7szWrx1q693gkBHVRwez+KjzyjGY7qdDVhamAkQ1id4CY7ISSHUTVB3r+IirsfoAxmrP70wO6ZQjMTZpzJt3IioQLFvPyk2ddDt06joWEMjc9bZve8OzyyvQKkUrXNPOTXV/iKcQSlCQPMM4zkXxRThXhT+DwWf4=; Received: from neustargw.va.neustar.com ([209.173.53.233]:45856 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UwXKe-0005PH-Fk for ecrit@ietf.org; Tue, 09 Jul 2013 08:47:48 -0400 From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_D19248CD-9995-4A26-90AD-065587981275" Date: Tue, 9 Jul 2013 08:47:46 -0400 References: <20130708210423.14631.25965.idtracker@ietfa.amsl.com> To: "ecrit@ietf.org Org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Subject: [Ecrit] Fwd: I-D Action: draft-rosen-ecrit-addldata-subnot-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 12:47:57 -0000 --Apple-Mail=_D19248CD-9995-4A26-90AD-065587981275 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This document proposes a SIP Sub/Not event package to update the = Additional Call Data information. It's complimentary to = draft-ietf-ecrit-additional-data. It also has a new block that contains the URI to send the SUBSCRIBE to. Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-rosen-ecrit-addldata-subnot-00.txt > Date: July 8, 2013 5:04:23 PM EDT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Updating Additional Data related to an = Emergency Call using Subscribe/ Notify > Author(s) : Brian Rosen > Filename : draft-rosen-ecrit-addldata-subnot-00.txt > Pages : 7 > Date : 2013-07-08 >=20 > Abstract: > Additional Call Data is sent in a SIP Call-Info header or in a > provided-by element of a PIDF-LO. Sometimes, the information needs > to be updated while an emergency call is in progress. It is best = for > the Public Safety Answering Point (PSAP) to control the timing and > frequency of updates. This document describes a SIP = Subscribe/Notify > Package to supply updates of Additional Call Data. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-rosen-ecrit-addldata-subnot >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-rosen-ecrit-addldata-subnot-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_D19248CD-9995-4A26-90AD-065587981275 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = document proposes a SIP Sub/Not event package to update the Additional = Call Data information.  It's complimentary to = draft-ietf-ecrit-additional-data.
It also has a new block that = contains the URI to send the SUBSCRIBE = to.

Brian


Begin = forwarded message:

Subject: I-D Action: = draft-rosen-ecrit-addldata-subnot-00.txt
Date: July 8, 2013 = 5:04:23 PM EDT
Reply-To: = internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.


Title =           : Updating = Additional Data related to an Emergency Call using Subscribe/ = Notify
= Author(s)       : Brian = Rosen
= Filename        : = draft-rosen-ecrit-addldata-subnot-00.txt
Pages =           : 7
Date =            : = 2013-07-08

Abstract:
  Additional Call Data is sent = in a SIP Call-Info header or in a
  provided-by element of = a PIDF-LO.  Sometimes, the information needs
  to be = updated while an emergency call is in progress.  It is best for
=   the Public Safety Answering Point (PSAP) to control the = timing and
  frequency of updates.  This document = describes a SIP Subscribe/Notify
  Package to supply = updates of Additional Call Data.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-rosen-ecrit-addldata-subnot
There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-rosen-ecrit-addldata-subnot-00
=

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=
= --Apple-Mail=_D19248CD-9995-4A26-90AD-065587981275-- From ietf-secretariat-reply@ietf.org Wed Jul 10 15:12:01 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31E811E8137 for ; Wed, 10 Jul 2013 15:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7psxdaz+nAWd for ; Wed, 10 Jul 2013 15:12:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D9011E8135 for ; Wed, 10 Jul 2013 15:12:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710221200.7744.20611.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 15:12:00 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 11 Jul 2013 06:42:31 -0700 Subject: [Ecrit] Milestones changed for ecrit WG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:12:02 -0000 Changed milestone "Informational RFC containing terminology definitions and the requirements", set due date to July 2006 from July 2006. Changed milestone "An Informational document describing the threats and security considerations", set due date to July 2006 from July 2006. Changed milestone "A Standards Track RFC describing how to identify a session set-up request is to an emergency response center", set due date to July 2006 from July 2006. Changed milestone "Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC.", set due date to July 2009 from July 2009. Changed milestone "Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document", set due date to July 2009 from July 2009. Changed milestone "Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC", set due date to December 2009 from December 2009. Changed milestone "Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC", set due date to October 2010 from October 2010. Changed milestone "Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC", set due date to March 2011 from March 2011. Changed milestone "Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC", set due date to December 2011 from December 2011. Changed milestone "Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC", set due date to January 2012 from January 2012. Changed milestone "Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC", set due date to March 2012 from March 2012. Changed milestone "Submit a draft 'Policy for defining new service-identifying labels' to the IESG for consideration as BCP", set due date to December 2013 from April 2013. URL: http://datatracker.ietf.org/wg/ecrit/charter/ From ietf-secretariat-reply@ietf.org Wed Jul 10 15:21:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48BB21F9A83 for ; Wed, 10 Jul 2013 15:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqoNsfexbUCw for ; Wed, 10 Jul 2013 15:21:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C3321F9B5B for ; Wed, 10 Jul 2013 15:21:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710222137.5771.21420.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 15:21:37 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 11 Jul 2013 06:42:31 -0700 Subject: [Ecrit] Milestones changed for ecrit WG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 22:21:39 -0000 Changed milestone "Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC", resolved as "Done". Changed milestone "Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC", set due date to May 2013 from March 2012. Changed milestone "Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC", set due date to June 2013 from January 2012. Changed milestone "Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC", set due date to August 2013 from March 2011. Changed milestone "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", set due date to November 2013 from April 2011. Changed milestone "Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC", set due date to December 2013 from December 2011. Changed milestone "Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC", set due date to March 2014 from November 2010. Added milestone " Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC", due April 2014. URL: http://datatracker.ietf.org/wg/ecrit/charter/ From RMarshall@telecomsys.com Fri Jul 12 14:55:50 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C758721F9FE7 for ; Fri, 12 Jul 2013 14:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rg-loIOFEYD for ; Fri, 12 Jul 2013 14:55:46 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2B7621F9FED for ; Fri, 12 Jul 2013 14:55:44 -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.1/8.14.1) with ESMTP id r6CLtc5J015943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 12 Jul 2013 14:55:39 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.236]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Fri, 12 Jul 2013 14:55:38 -0700 From: Roger Marshall To: "'ecrit@ietf.org'" Thread-Topic: Draft ecrit agenda for the IETF87 Berlin meeting Thread-Index: Ac5/SJh4D99CLaVoQKyLFLivTxDIFQ== Date: Fri, 12 Jul 2013 21:55:37 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC36B29CSEAEXMB2telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] Draft ecrit agenda for the IETF87 Berlin meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 21:55:50 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC36B29CSEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See the ECRIT draft agenda below. We've got some additional time availabl= e. If there is some draft or topic you'd like to see included, let me know. Thanks. Roger & Marc. *** ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall) 20 min * Additional Data related to an Emergency Call (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss latest changes and if ready for WGLC 15 min. * Trustworthy Location Information (Bernard) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss impact of recent rewrite 15 min * Internet Protocol-based In-Vehicle Emergency Call (Hannes) http://tools.ietf.org/id/draft-rosen-ecrit-ecall-08.txt Intention: Discussion of draft & WG adoption question 15 min * eCall - background, current status, and requirements discussion li= nked to current ETSI work (Ban Al-Bakri) 15 min * Open Discussion 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_FBD5AAFFD0978846BF6D3FAB4C892ACC36B29CSEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See the ECRIT draft ag= enda below.   We’ve got some additional time available.

If there is some draft= or topic you’d like to see included, let me know.<= /p>

 

Thanks.

 

Roger & Marc.=

 

***<= /p>

 

ECRIT Agenda - 13:00-1= 5:00, Monday, July 29, 2013 Berlin

 

10 min * Agenda Bashin= g, Draft Status Update (Marc Linsner, Roger Marshall)

 

20 min * Additional Da= ta related to an Emergency Call (Brian)

http://datatracker.= ietf.org/doc/draft-ietf-ecrit-additional-data/

Intention: Discuss lat= est changes and if ready for WGLC

 

15 min. * Trustworthy = Location Information (Bernard)

http://datatra= cker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/

Intention: Discuss imp= act of recent rewrite

 

15 min * Intern= et Protocol-based In-Vehicle Emergency Call (Hannes)

http://tools.ietf.org/id/draf= t-rosen-ecrit-ecall-08.txt

Intention: Discussion = of draft & WG adoption question

 

15 min * eCall - backg= round, current status, and requirements discussion linked to current ETSI w= ork (Ban Al-Bakri)

 

15 min * Open Discussi= on

 

 

 

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_FBD5AAFFD0978846BF6D3FAB4C892ACC36B29CSEAEXMB2telecomsy_-- From internet-drafts@ietf.org Sat Jul 13 02:04:08 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7021F9F7A; Sat, 13 Jul 2013 02:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFJmc+8CpRUm; Sat, 13 Jul 2013 02:04:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8D811E819B; Sat, 13 Jul 2013 02:04:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130713090404.25150.79305.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 02:04:04 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-psap-callback-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 09:04:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callback Author(s) : Henning Schulzrinne Hannes Tschofenig Christer Holmberg Milan Patel Filename : draft-ietf-ecrit-psap-callback-10.txt Pages : 15 Date : 2013-07-13 Abstract: After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current situation of a wounded person. A call taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than- normal call treatment behavior would be desirable. A solution based on a new header field value, called "psap-callback", for the SIP Priority header field is specified to accomplish the PSAP callback marking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-psap-callback-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Sat Jul 13 02:16:31 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DFA21E8089 for ; Sat, 13 Jul 2013 02:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH3x7iNA08cW for ; Sat, 13 Jul 2013 02:16:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 779C721F9BA6 for ; Sat, 13 Jul 2013 02:16:23 -0700 (PDT) Received: from [172.16.254.104] ([80.92.118.93]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M8NBi-1UCGyC13ic-00vtKT; Sat, 13 Jul 2013 11:16:22 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jul 2013 11:16:20 +0200 Message-Id: <990C8CBC-D0C4-458E-AE26-DADD6EA9B8FE@gmx.net> To: "ecrit@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:9K25qfxaZxriMsMDpgubFjCk3xXc6QK/KpJfCJCc9cKl+jeoT6Q /q2+FeEQlY5VwZuKkDxxF/ATTmI7hjVhh/EYBa7j9THXcsOi2MCCNVG7kv6ztsqHz+t0ztn C76vnuk8BUHVlwSACHoNrqydc8u4tNrOw3kHQRC5oHecgk5c1IPGOu/sDVFKyaP9aTDS/RT ojhcd7bcHtUDk1YENPKPQ== Subject: [Ecrit] draft-ietf-ecrit-psap-callback-10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 09:16:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I just posted version -10 of the PSAP callback draft to fix nits = (particularly with unused references) found by Roger, the document = shepherd.=20 The tool also complained about the use of non-RFC2606-compliant FQDNs in = the example section. That's correct but I do not see another way to = illustrate the limitations with the mechanism described in PhoneBCP. = Hence, I suggest to the keep the FQDNs in the examples as they are but I = added a note at the beginning of the section.=20 Here is the updated document:=20 http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-10 Ciao Hannes =20 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR4RrlAAoJEGhJURNOOiAt+zMH/1XqGQKOu/fpXAP1uc4UAt3B jH5DGKkfZ1VNkF/PrN4nXZPVACGVwO0mYXt8uNZHavEZhvSwAS4c27ZgA0YSbbYZ QAHFMjoqMWJLtT5Xa6NpcXgFmpnV2uySshyiQhBoW5vFprXqaxNf6h9e+mAEUZ/V gjPDzo23smWO4LOhTH0AxGYmVBhnn9tyPcu479YIqsk1erNKrseTZh6vqs2Ua+4N zBEyS+w+hgyfmbcV5DAIAtmxT5/MzHwBlciDfgDXXNUK0T7EE/xxdUrDrlFeU1nC QMlkk3kqsCZjBjavq3rOyOYsSDazFd2xy275tDh1b/8Ic89FvlfmFySZYCuS4rk=3D =3DUVZ6 -----END PGP SIGNATURE----- From internet-drafts@ietf.org Sat Jul 13 06:49:24 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2652721F9E12; Sat, 13 Jul 2013 06:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkVT0oD6YHhV; Sat, 13 Jul 2013 06:49:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B099521F9E02; Sat, 13 Jul 2013 06:49:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130713134923.8982.32977.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 06:49:23 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-unauthenticated-access-07.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 13:49:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Extensions to the Emergency Services Architecture for de= aling with Unauthenticated and Unauthorized Devices Author(s) : Henning Schulzrinne Stephen McCann Gabor Bajko Hannes Tschofenig Dirk Kroeselberg Filename : draft-ietf-ecrit-unauthenticated-access-07.txt Pages : 19 Date : 2013-07-13 Abstract: The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-unauthenticated-access-= 07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Sat Jul 13 06:53:28 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1A121F9B58 for ; Sat, 13 Jul 2013 06:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfZCYCS+lnz3 for ; Sat, 13 Jul 2013 06:53:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 87C4021F977A for ; Sat, 13 Jul 2013 06:53:16 -0700 (PDT) Received: from [172.16.254.104] ([80.92.118.93]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M0yaB-1UAqFZ25Jn-00vBci; Sat, 13 Jul 2013 15:53:14 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jul 2013 15:53:12 +0200 Message-Id: To: "ecrit@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:MULEdnpwcsgboz0oKkDYjwVND0zqePdJxfNYfPQncPdukZuIWIb Mw7IcGUHv7EZhx/m2Cr8tggnUKnnpVBPBBsaNf9G8+TurRjSXvY7sPkA8y+tX+OSrLGGHfJ 2xXjDRm/17R+xbPsB10Tk5WPTuEi5CSrFeoMG6Wy1Ti86qld0cVxhHTCkSX3bHDcmi2pR88 ZEjY8PaPjIWk5Up/zmF0A== Subject: [Ecrit] draft-ietf-ecrit-unauthenticated-access-07.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 13:53:28 -0000 X-List-Received-Date: Sat, 13 Jul 2013 13:53:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all,=20 I have submitted an update of draft-ietf-ecrit-unauthenticated-access to = address comments from Roger, the document shepherd.=20 In particular I have updated and removed unused references. I have also = made some editorial changes.=20 Here is the updated version:=20 http://tools.ietf.org/html/draft-ietf-ecrit-unauthenticated-access-07 Ciao Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR4VvJAAoJEGhJURNOOiAtKb0H/04qzZuotCEA2E/cZNFe42P6 j6+b7M8j5Np7FAvJHdOOXzJrEq8vpLaR0VYJcP6vKHOk2OvRuPHQTHkSj+1MSsCq 0cbCitavRDwYDiw4PjkDvNZzEm1vpNgO0T7d/mUwODZD8ZfDPbMgq7RRzCeO7NG2 hbTIqK9yd2CbIG6gA9DpKcBtAyg2TcSRmat6Z3JBiDWNCfVperSxVCZxTY9gJnkM KGg3SRzV0n8hBgqNO7zVqvpGaEQ5GA3jrXr9qCvMh/ygzJNb3jFK3GPE5CTPTUp0 btqsHd3ECPayUNwa5Ly87Gz2EhLBxRuuAS0gybRnUnlUFTiMuVb88X8ZWt+/268=3D =3DvX9Y -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Sat Jul 13 07:16:39 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348C021F9D5C for ; Sat, 13 Jul 2013 07:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O0J+AarysQ4 for ; Sat, 13 Jul 2013 07:16:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3621F8AD5 for ; Sat, 13 Jul 2013 07:16:34 -0700 (PDT) Received: from [172.16.254.104] ([80.92.118.93]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M2Ldk-1U8NyX056y-00s30C; Sat, 13 Jul 2013 16:16:33 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jul 2013 16:16:32 +0200 Message-Id: To: "ecrit@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:4Q8vSWgB1usRDOnN0hAzyFtZxKYJHHrWeGXX6qdDpyoQ7CGwFKU pEttYjVLG8xdtyA+lD8GusjqzkeQwWZ7/qUHA9gZ1CBkqFWlk4dKltm2MxH+5iN7Af/ze67 gP0aBiRoxKknyD3vZVvU7ZZpnZWBg9/ogIF4mQ/KeR6CGtAhLGWaekHEZHsH6Nil31uzzjD DjNaj6crxBf9WBJ5LfpGA== Subject: [Ecrit] draft-rosen-ecrit-ecall-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 14:16:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all,=20 I have just submitted an update of the eCall document.=20 There have been a number of changes to the document, namely: * there is a much longer introduction that provides some information = about existing deployment models and how we envision the next generation = deployments to look like.=20 * added terminology * MIME registration for the VEDS data set (which was moved over from the = additional data draft) * registration of the 'VEDS' entry in the Emergency Call Additional = Data registry * updated appendix containing the mapping between the eCall = functionality and the IP-based emergency services signaling=20 The new version can be found here:=20 http://tools.ietf.org/html/draft-rosen-ecrit-ecall-09 Ciao Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR4WFAAAoJEGhJURNOOiAtQd4H/3dXFL0Q/BZELRWlFpgSKkRk 47uQgD3qZjcBLum7bX2mjNbUxGY52EdN9MZ5CvWloJEV2CXK2G9mYNM1M+VMnBH8 QCAslmIqVdELmETXa2fUZlL670PiEgEUuSPqgoUHcdk5Y8nfRH/mNRD/hqiMSCO3 oAyenSQZkL0fbTU9BR6Mtw436kJFvVLOVccSUNnyXiNma3OZAJvYZm0JnkOmp+yt bnM0i8ZLCOJuq1xNj5iEUkX/69xMPLDreAFEQRVxzK++Zrslg0ecAGQn4yg9bAyd 6APZI/nWH0xSChE/ppNtTttJL9oMtdC7UTaK71IXSO0Qj2TeDevz64JI0sj2eQI=3D =3DkS9Z -----END PGP SIGNATURE----- From randy@qti.qualcomm.com Sun Jul 14 01:56:29 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4663221F9B85 for ; Sun, 14 Jul 2013 01:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8vr3Si0T835 for ; Sun, 14 Jul 2013 01:56:25 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 40A7D21F8EB5 for ; Sun, 14 Jul 2013 01:56:25 -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=1373792185; x=1405328185; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=EqSsA6UtH9sgjGERKG8Z/r4S2WJEH0XGIB2/MaGfZD8=; b=mNbzLCYumK3wapkP3MqWGnjMh2wrhcA9AUjoevsEuX8U3XENDiTpwDNZ CkPMcfixCYyJQAFJzHRt6I1WrJTE0zX+ndbSI162m6vvBBD6PjKs7kbl6 LcKIOFS/49b+KUV2AP/e7vr6eU0tToDfnP0T/jWVJdGk2OjC65241SHIf 8=; X-IronPort-AV: E=Sophos;i="4.89,662,1367996400"; d="scan'208";a="47474775" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 14 Jul 2013 01:56:24 -0700 Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Jul 2013 01:56:24 -0700 Received: from [10.121.65.183] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 14 Jul 2013 01:56:22 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Sun, 14 Jul 2013 01:56:18 -0700 To: "ecrit@ietf.org WG" 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.48.1] Subject: [Ecrit] draft-rosen-ecrit-ecall-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 08:56:29 -0000 Hi all, A few more changes to the ecall document: - tweaked the deployment model figures - more clarifying text in Introduction on purpose of document, and ACN and eCall systems - made a few wording changes for clarity - added a box showing the ESInet to the illustrative figure - added ESInet to the acronyms - mentioned that in the absence of an ESInet the VoIP provider routes to the PSAP - added a VEDS object to the SIP INVITE example At 4:16 PM +0200 7/13/13, Hannes Tschofenig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi all, > > I have just submitted an update of the eCall document. > > There have been a number of changes to the document, namely: > * there is a much longer introduction that provides some > information about existing deployment models and how we envision > the next generation deployments to look like. > * added terminology > * MIME registration for the VEDS data set (which was moved over > from the additional data draft) > * registration of the 'VEDS' entry in the Emergency Call Additional > Data registry > * updated appendix containing the mapping between the eCall > functionality and the IP-based emergency services signaling > > The new version can be found here: > http://tools.ietf.org/html/draft-rosen-ecrit-ecall-09 > > Ciao > Hannes > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBCgAGBQJR4WFAAAoJEGhJURNOOiAtQd4H/3dXFL0Q/BZELRWlFpgSKkRk > 47uQgD3qZjcBLum7bX2mjNbUxGY52EdN9MZ5CvWloJEV2CXK2G9mYNM1M+VMnBH8 > QCAslmIqVdELmETXa2fUZlL670PiEgEUuSPqgoUHcdk5Y8nfRH/mNRD/hqiMSCO3 > oAyenSQZkL0fbTU9BR6Mtw436kJFvVLOVccSUNnyXiNma3OZAJvYZm0JnkOmp+yt > bnM0i8ZLCOJuq1xNj5iEUkX/69xMPLDreAFEQRVxzK++Zrslg0ecAGQn4yg9bAyd > 6APZI/nWH0xSChE/ppNtTttJL9oMtdC7UTaK71IXSO0Qj2TeDevz64JI0sj2eQI= > =kS9Z > -----END PGP SIGNATURE----- > _______________________________________________ > 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: --------------- Squad Helps Dog Bite Victim --Newspaper headline From trac+ecrit@trac.tools.ietf.org Sun Jul 14 22:10:28 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD59E21F9D38 for ; Sun, 14 Jul 2013 22:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLZDrZ-l0cvB for ; Sun, 14 Jul 2013 22:10:28 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2547F21F9C25 for ; Sun, 14 Jul 2013 22:10:27 -0700 (PDT) Received: from localhost ([127.0.0.1]:56942 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uyb3I-0003rq-Nx; Mon, 15 Jul 2013 07:10:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Mon, 15 Jul 2013 05:10:24 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/12#comment:2 Message-ID: <080.36d98b8af37d288359ab3a21a9878e14@trac.tools.ietf.org> References: <065.a74dbc7676ca3af6c9ab1365df20dd33@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <065.a74dbc7676ca3af6c9ab1365df20dd33@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130715051028.2547F21F9C25@ietfa.amsl.com> Resent-Date: Sun, 14 Jul 2013 22:10:27 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #12: Introduction X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 05:10:28 -0000 #12: Introduction Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Sun Jul 14 22:12:43 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4964321F9D66 for ; Sun, 14 Jul 2013 22:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2VVw5zyV51K for ; Sun, 14 Jul 2013 22:12:42 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 731FC21F8DE3 for ; Sun, 14 Jul 2013 22:12:39 -0700 (PDT) Received: from localhost ([127.0.0.1]:57104 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uyb5S-0001Vc-N2; Mon, 15 Jul 2013 07:12:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: drat-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Mon, 15 Jul 2013 05:12:38 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/13#comment:3 Message-ID: <080.ccf9838a6fd63a81fe74a7fe33d16639@trac.tools.ietf.org> References: <065.d65107e0f04ba3b145e66d2b8bae348c@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <065.d65107e0f04ba3b145e66d2b8bae348c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: drat-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #13: Location Trust Assessment X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 05:12:43 -0000 #13: Location Trust Assessment Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: drat-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Sun Jul 14 22:13:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8320B21F85B2 for ; Sun, 14 Jul 2013 22:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0ebbT7nHUq2 for ; Sun, 14 Jul 2013 22:13:26 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B6BB521F8DE3 for ; Sun, 14 Jul 2013 22:13:25 -0700 (PDT) Received: from localhost ([127.0.0.1]:57245 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uyb6B-0007Zx-2D; Mon, 15 Jul 2013 07:13:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Mon, 15 Jul 2013 05:13:23 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/14#comment:2 Message-ID: <080.f808f68a276af32c6ce720c6d09bb6de@trac.tools.ietf.org> References: <065.a9d5155d47366b7fa2e2b595220d3bd2@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <065.a9d5155d47366b7fa2e2b595220d3bd2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130715051325.B6BB521F8DE3@ietfa.amsl.com> Resent-Date: Sun, 14 Jul 2013 22:13:25 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #14: Security Considerations X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 05:13:26 -0000 #14: Security Considerations Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Mon Jul 15 01:15:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E13521F9ECE for ; Mon, 15 Jul 2013 01:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0sZcchY5Pdm for ; Mon, 15 Jul 2013 01:15:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8F86C21F9EC2 for ; Mon, 15 Jul 2013 01:15:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:49348 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uydvw-0007Cn-IC; Mon, 15 Jul 2013 10:15:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Mon, 15 Jul 2013 08:15:00 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/8#comment:3 Message-ID: <080.f196b89973a5ecfe4b94647ff5b0e029@trac.tools.ietf.org> References: <065.165eff18457d51bb8c98009f8bce2353@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <065.165eff18457d51bb8c98009f8bce2353@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130715081507.8F86C21F9EC2@ietfa.amsl.com> Resent-Date: Mon, 15 Jul 2013 01:15:07 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #8: Solutions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 08:15:38 -0000 #8: Solutions Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- Bernard_Aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 2.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From internet-drafts@ietf.org Mon Jul 15 01:30:12 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA17221F9E67; Mon, 15 Jul 2013 01:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZspd0rQlkza; Mon, 15 Jul 2013 01:30:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6842321F8C7C; Mon, 15 Jul 2013 01:27:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715082648.22850.13055.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 01:26:48 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-trustworthy-location-06.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 08:30:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Trustworthy Location Author(s) : Hannes Tschofenig Henning Schulzrinne Bernard Aboba Filename : draft-ietf-ecrit-trustworthy-location-06.txt Pages : 23 Date : 2013-07-15 Abstract: For some location-based applications, such as emergency calling or roadside assistance, the trustworthiness of location information is critically important. This document describes how to convey location in a manner that is inherently secure and reliable. 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-trustworthy-location-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ivo.sedlacek@ericsson.com Mon Jul 15 04:23:33 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C12E11E80E1 for ; Mon, 15 Jul 2013 04:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Avp-Ry+2i4jq for ; Mon, 15 Jul 2013 04:23:28 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 146DF21F8ECA for ; Mon, 15 Jul 2013 04:23:11 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-ed-51e3db9efea8 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 04.05.11907.E9BD3E15; Mon, 15 Jul 2013 13:23:11 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.30]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Mon, 15 Jul 2013 13:23:10 +0200 From: Ivo Sedlacek To: Ivo Sedlacek , "ecrit@ietf.org" Thread-Topic: Question to draft-ietf-ecrit-data-only-ea-05 Thread-Index: Ac5yNO0/BT+1Wf3oSGOSPbvRWIDIagPGKW0g Date: Mon, 15 Jul 2013 11:23:09 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvre78248DDXZ8ZLdoXPSU1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGe8aG9gLZslULFw1mbWB8bNYFyMnh4SAicTjngksELaYxIV7 69m6GLk4hASOMkq8n7UKylnMKLHz8A9WkCo2AT2JiVuOgNkiAoESL/9NA+sWFrCU+DCnjQUi biXxtmE1UxcjB5BtJLHuciRImEVAVWLLyYtMIDavgLfEwieH2EBsISB7650V7CA2p4CPxLZj 88HGMwrISlz908sIYjMLiEvcejKfCeJQAYkle84zQ9iiEi8f/2OFsBUlrk5fzgRRryfx7NQs FghbW2LZwtfMEHsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMHMWpxUm56UYGmxiBgX9w y2+LHYyX/9ocYpTmYFES592idyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+ON7YLHmtsc t3/26lV+sy7+dEScmvBPAS6Ox567BX/ytxsu2DuxqHf+oTl/E1g+Z5+ws7FnO6Kweekurl/1 /Oxb7RZ6Kd6/7/wmboPF1roEL14RQZHWr0cuf4hfefBeUOS7ZQ4n30Ruvmz2/OinaactXpvp BMyKKeDb3FU5L/+5otKBaUmOBkeVWIozEg21mIuKEwEYJ+3sSgIAAA== Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 11:23:33 -0000 Any comments to the issues below?=20 Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of I= vo Sedlacek Sent: 26. =E8ervna 2013 8:26 To: ecrit@ietf.org Subject: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 Hello, draft-ietf-ecrit-data-only-ea-05 states: =A0=A0 This document does not define a mechanism for updates to the data =A0=A0 contained in data-only emergency calls. Is there another I-D describing how to provide the updates of the data to t= he PSAP? I saw some post suggesting that a SUBSCRIBE/NOTIFY mechanism could= be used where the PSAP is subscriber and the UA is notifier, however I hav= e not found such draft. Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the subscriber = and the UA is the notifier, this would require reachability of UA for initi= al request for dialog (i.e. SUBSCRIBE). However, when the UA is not registe= red e.g. due to missing credentials, the UA is normally not reachable for S= IP requests other than those sent within the dialog of the emergency call. Issue 2: How to send the update of the data __triggered by the UA__? Do we = assume that if the PSAP subscription is not available, the PSAP prevents th= e UE from sending further information? =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If so, assuming PSAP is interested in any= information available, PSAP will need to subscribe in every single case of= MESSAGE with CAP where UA can potentially provide the update of the data. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If not, do we assume that the UE would se= nd updates of data triggered by UE using other mechanism (MESSAGE?) than up= dates of data requested by PSAP (NOTIFY)? Issue 3: In some architectures (like 3GPP), signalling path for inital requ= est for dialog from the PSAP to the UA is different than signalling path fo= r the emergency request from the UA to the PSAP. If the UA has subscription= from network in country X and roams in country Y, there is likelyhood that= information that request comes from the PSAP is lost due to missing trust = among PSAP (in country Y), transit networks (in country Y and X and possibl= y other transit countries), network of registrar and proxy of the UA (in co= untry X), transit networks (in country X and Y and possibly other transit c= ountries) and network of edge proxy serving the UA (in country Y) . If so, = the UA would then handle the inital request for dialog as coming from an at= tacker UE and possibly reject it. Is draft-ietf-ecrit-data-only-ea-05 supposed to be a base for future solut= ion where updates of the data to the PSAP are sent? I do not think it would= work due to issues above. If the UA ever wants to provide the updates of the data to the PSAP, either= triggred by the UA or requested by the PSAP, it would be better to establi= sh a dialog from beginning, e.g. send the initial data in INVITE and update= s (from UE) and requests for updates (from PSAP) in INFOs. Kind regards Ivo Sedlacek=20 Ericsson Mobile +420 608 234 709 ivo.sedlacek@ericsson.com www.ericsson.com=20 This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer ____________= ___________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Mon Jul 15 04:44:10 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57A921F9E0A for ; Mon, 15 Jul 2013 04:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPYs781+wrCo for ; Mon, 15 Jul 2013 04:44:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6062621F9DEE for ; Mon, 15 Jul 2013 04:44:06 -0700 (PDT) Received: from [172.16.254.104] ([80.92.118.93]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LrePN-1U1tio1kwn-013LZH; Mon, 15 Jul 2013 13:44:03 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-2 From: Hannes Tschofenig In-Reply-To: <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se> Date: Mon, 15 Jul 2013 13:44:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2AA25A28-2AC6-42FB-9115-CA319785A555@gmx.net> References: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se> To: Ivo Sedlacek X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:u/e/IQJ21Wd0uoxu5qF3N+T/tXtbwoQ8N6pVXeiB/nLBzBskXfy UD1cUCC0jaPIMDRHrfjPIn81jUWK21s3U3jgd/mihA3GH4YNHw6Z9Y4ZsbxQay0aK21NhrT OBFfVIdOlZWgZtMswbxy5yNHyzrjPAgy7060gsGsrQDSpSw2FFniej/8ZQqHFgsnTS9IJxt ZhBiZ32ba6OuMuyUXBKGQ== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 11:44:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Ivo,=20 sorry for the delay and for the quick response. A more detailed response = will follow tomorrow.=20 We have worked on a subscribe/notify document (that also works with this = document) in the past and the initial plan was to go through it in ATOCA = (because it was perceived to be the fastest route). Obviously that did = not turn out to be correct.=20 Maybe we should consider it in this working group.=20 Here is the document:=20 http://tools.ietf.org/html/draft-rosen-sipping-cap-04 We would be happy to get help (=3Dco-authorship) from you (or anymore = else) to progress the document.=20 Ciao Hannes On Jul 15, 2013, at 1:23 PM, Ivo Sedlacek wrote: > Any comments to the issues below?=20 >=20 > Kind regards >=20 > Ivo Sedlacek >=20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer=20 >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Ivo Sedlacek > Sent: 26. =E8ervna 2013 8:26 > To: ecrit@ietf.org > Subject: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 >=20 > Hello, >=20 > draft-ietf-ecrit-data-only-ea-05 states: >=20 >=20 > This document does not define a mechanism for updates to the data > contained in data-only emergency calls. >=20 >=20 > Is there another I-D describing how to provide the updates of the data = to the PSAP? I saw some post suggesting that a SUBSCRIBE/NOTIFY = mechanism could be used where the PSAP is subscriber and the UA is = notifier, however I have not found such draft. >=20 > Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the = subscriber and the UA is the notifier, this would require reachability = of UA for initial request for dialog (i.e. SUBSCRIBE). However, when the = UA is not registered e.g. due to missing credentials, the UA is normally = not reachable for SIP requests other than those sent within the dialog = of the emergency call. >=20 > Issue 2: How to send the update of the data __triggered by the UA__? = Do we assume that if the PSAP subscription is not available, the PSAP = prevents the UE from sending further information? > If so, assuming PSAP is interested in any information = available, PSAP will need to subscribe in every single case of MESSAGE = with CAP where UA can potentially provide the update of the data. > If not, do we assume that the UE would send updates of = data triggered by UE using other mechanism (MESSAGE?) than updates of = data requested by PSAP (NOTIFY)? >=20 > Issue 3: In some architectures (like 3GPP), signalling path for inital = request for dialog from the PSAP to the UA is different than signalling = path for the emergency request from the UA to the PSAP. If the UA has = subscription from network in country X and roams in country Y, there is = likelyhood that information that request comes from the PSAP is lost due = to missing trust among PSAP (in country Y), transit networks (in country = Y and X and possibly other transit countries), network of registrar and = proxy of the UA (in country X), transit networks (in country X and Y and = possibly other transit countries) and network of edge proxy serving the = UA (in country Y) . If so, the UA would then handle the inital request = for dialog as coming from an attacker UE and possibly reject it. >=20 > Is draft-ietf-ecrit-data-only-ea-05 supposed to be a base for future = solution where updates of the data to the PSAP are sent? I do not think = it would work due to issues above. >=20 > If the UA ever wants to provide the updates of the data to the PSAP, = either triggred by the UA or requested by the PSAP, it would be better = to establish a dialog from beginning, e.g. send the initial data in = INVITE and updates (from UE) and requests for updates (from PSAP) in = INFOs. >=20 > Kind regards >=20 > Ivo Sedlacek=20 >=20 > Ericsson > Mobile +420 608 234 709 > ivo.sedlacek@ericsson.com > www.ericsson.com=20 >=20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer = _______________________________________________ > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR4+CCAAoJEGhJURNOOiAt50IH/1r04pjqikpsvo+Mb7uExHWJ dM4zjOWZarOLyhglCcXddCi5EgaeIJ0myYhtc2qcJ9aCHqs7m5c5pfn0M9EZogUO PHd0uT4d4a5aXr0eBFhva6W4t4j/aLGHBiVrpakX3hIveVYBfKNnwC1yMxgO1BUs otCOmFjnEcykLe8ko6JRVRrHR7vEtYGltMR8IierpHap8C5zkXDB+NpdinCKNkeO wHJZ72HD2sQi9qHYCI/VvgyMxkrCg05BvspixEkA4cIUL5lqeR4VIgENngofJ76f Ub6mwtRgFNORRI3Tw2GJsM3RRg0zxrCh5Iv98DOmxsCeL6JdtSGYkLxm0Nj3qCU=3D =3DFcHc -----END PGP SIGNATURE----- From br@brianrosen.net Mon Jul 15 05:52:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C570E21E8064 for ; Mon, 15 Jul 2013 05:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.237 X-Spam-Level: X-Spam-Status: No, score=-100.237 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6LycL5eHKbb for ; Mon, 15 Jul 2013 05:52:20 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 19F7321F9E12 for ; Mon, 15 Jul 2013 05:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=gjLCMOxFLIwKTNA+guRQ60wNZlzVOZbSUd+BpeJVGCI=; b=A6BIXZw24GqrRsmpzQAHPz5+K/4MkOQK7ClAY3hFuSIjPxBEkl1AIu/dGWkkPJ446Gb31VC4AJ4P4zlzLuTv/rSFzKedw3vIUqACue6iVWPWHkDpSzEh3mFXGVZx4/qieSGP7DZlznoiYS2H+WH+Gu7EqZAMjk4Y+RSVfsPAW4U=; Received: from neustargw.va.neustar.com ([209.173.53.233]:44196 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UyiGH-0000XY-BU; Mon, 15 Jul 2013 08:52:17 -0400 Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se> Date: Mon, 15 Jul 2013 08:52:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4BD09290-F3F3-45CE-BF56-1896B76EE51D@brianrosen.net> References: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se> To: Ivo Sedlacek X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 12:52:26 -0000 See comments inline On Jul 15, 2013, at 7:23 AM, Ivo Sedlacek = wrote: > Any comments to the issues below?=20 >=20 > Kind regards >=20 > Ivo Sedlacek >=20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer=20 >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Ivo Sedlacek > Sent: 26. =E8ervna 2013 8:26 > To: ecrit@ietf.org > Subject: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 >=20 > Hello, >=20 > draft-ietf-ecrit-data-only-ea-05 states: >=20 >=20 > This document does not define a mechanism for updates to the data > contained in data-only emergency calls. >=20 >=20 > Is there another I-D describing how to provide the updates of the data = to the PSAP? I saw some post suggesting that a SUBSCRIBE/NOTIFY = mechanism could be used where the PSAP is subscriber and the UA is = notifier, however I have not found such draft. >=20 > Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the = subscriber and the UA is the notifier, this would require reachability = of UA for initial request for dialog (i.e. SUBSCRIBE). However, when the = UA is not registered e.g. due to missing credentials, the UA is normally = not reachable for SIP requests other than those sent within the dialog = of the emergency call. I think the combination of missing credentials, and data updates is so = unlikely that the problem of PSAP control of updates dwarfs it. I think that in many cases where the DEVICE as a opposed to a service = supplies updates, it will employ a server somewhere and publish its = updates to the server, which can allow PSAP subscriptions. That's = primarily because the device doesn't want or need much mechanism. I = probably should mention that idea in the draft. >=20 > Issue 2: How to send the update of the data __triggered by the UA__? = Do we assume that if the PSAP subscription is not available, the PSAP = prevents the UE from sending further information? > If so, assuming PSAP is interested in any information = available, PSAP will need to subscribe in every single case of MESSAGE = with CAP where UA can potentially provide the update of the data. > If not, do we assume that the UE would send updates of = data triggered by UE using other mechanism (MESSAGE?) than updates of = data requested by PSAP (NOTIFY)? The source is the server (unless a device uses another server, see = above). Updates will always be triggered by the source. The = destination (PSAP) can ask for filtering, but updates would not be sent = unless the source wanted to send one. The mechanism the draft I created included an explicit mechanism to tell = the PSAP that updates may be available. If the source won't update, = then it would not send the URI for subscriptions. The PSAP can then = decide if it wants to subscribe. It would have, at most, as many = subscriptions as it can handle calls (one per call taker). >=20 > Issue 3: In some architectures (like 3GPP), signalling path for inital = request for dialog from the PSAP to the UA is different than signalling = path for the emergency request from the UA to the PSAP. If the UA has = subscription from network in country X and roams in country Y, there is = likelyhood that information that request comes from the PSAP is lost due = to missing trust among PSAP (in country Y), transit networks (in country = Y and X and possibly other transit countries), network of registrar and = proxy of the UA (in country X), transit networks (in country X and Y and = possibly other transit countries) and network of edge proxy serving the = UA (in country Y) . If so, the UA would then handle the inital request = for dialog as coming from an attacker UE and possibly reject it. In such circumstances, you INCREASE the probability of success by = requesting the PSAP contact the device without any of the networks in = the path (possibly other than the home network). The request is coming to a URI that is contained in the outgoing = message, which is supposed to be protected the entire path with TLS (to = avoid observation). The attacker would have to be in the path of the = call to get the URI, unless it's guessable. This isn't very strong = security, but it's something. PSAPs have credentials, and the device or server can check them. >=20 > Is draft-ietf-ecrit-data-only-ea-05 supposed to be a base for future = solution where updates of the data to the PSAP are sent? I do not think = it would work due to issues above. >=20 > If the UA ever wants to provide the updates of the data to the PSAP, = either triggred by the UA or requested by the PSAP, it would be better = to establish a dialog from beginning, e.g. send the initial data in = INVITE and updates (from UE) and requests for updates (from PSAP) in = INFOs. I don't think it is acceptable to have the device in control of the rate = of updates, which is the entire reason I suggest using SUBSCRIBE. = Unless we recreate the entire filtering mechanism, I don't think in-band = updates work. Brian From br@brianrosen.net Mon Jul 15 05:55:06 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543F411E80FE for ; Mon, 15 Jul 2013 05:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.251 X-Spam-Level: X-Spam-Status: No, score=-100.251 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsavziZ-Pf0w for ; Mon, 15 Jul 2013 05:55:02 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0611011E80D3 for ; Mon, 15 Jul 2013 05:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=vlh2vxQacGsMVxzikOAoYWfoHkSiL5R0oTd9PPAA94I=; b=gItSReLm4bwsHDCFz2oJzWS4yQjUtyMFwuaFS2P9jZ4gkCG87pQ4IePEU0VOgTnK5Hf2bqNXm+w06hSCBXtQIS2CAefVQnW8PB688L73Gmh+u4p+GQBjqy1z5V1jPsUvkmb99x4LAruFfkrG0aju2mzgNK1DbIqye/bpyMwzSJw=; Received: from neustargw.va.neustar.com ([209.173.53.233]:50147 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UyiIp-00014H-Ur; Mon, 15 Jul 2013 08:54:56 -0400 Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <2AA25A28-2AC6-42FB-9115-CA319785A555@gmx.net> Date: Mon, 15 Jul 2013 08:54:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1EFA2F5D-26A6-415D-AB8F-6698B302601F@brianrosen.net> References: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se> <2AA25A28-2AC6-42FB-9115-CA319785A555@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 12:55:06 -0000 > http://tools.ietf.org/html/draft-rosen-ecrit-addldata-subnot-00 Simpler, more direct update (sends the blocks in the same way that the = original source did. Using CAP for updates isn't particularly helpful - none of the CAP = information is useful. All you want is the blocks that were in the = original INVITE/MESSAGE with updated content. Brian On Jul 15, 2013, at 7:44 AM, Hannes Tschofenig = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi Ivo,=20 >=20 > sorry for the delay and for the quick response. A more detailed = response will follow tomorrow.=20 >=20 > We have worked on a subscribe/notify document (that also works with = this document) in the past and the initial plan was to go through it in = ATOCA (because it was perceived to be the fastest route). Obviously = that did not turn out to be correct.=20 >=20 > Maybe we should consider it in this working group.=20 >=20 > Here is the document:=20 > http://tools.ietf.org/html/draft-rosen-sipping-cap-04 >=20 > We would be happy to get help (=3Dco-authorship) from you (or anymore = else) to progress the document.=20 >=20 > Ciao > Hannes >=20 > On Jul 15, 2013, at 1:23 PM, Ivo Sedlacek wrote: >=20 >> Any comments to the issues below?=20 >>=20 >> Kind regards >>=20 >> Ivo Sedlacek >>=20 >> This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer=20 >>=20 >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Ivo Sedlacek >> Sent: 26. =E8ervna 2013 8:26 >> To: ecrit@ietf.org >> Subject: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 >>=20 >> Hello, >>=20 >> draft-ietf-ecrit-data-only-ea-05 states: >>=20 >>=20 >> This document does not define a mechanism for updates to the data >> contained in data-only emergency calls. >>=20 >>=20 >> Is there another I-D describing how to provide the updates of the = data to the PSAP? I saw some post suggesting that a SUBSCRIBE/NOTIFY = mechanism could be used where the PSAP is subscriber and the UA is = notifier, however I have not found such draft. >>=20 >> Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the = subscriber and the UA is the notifier, this would require reachability = of UA for initial request for dialog (i.e. SUBSCRIBE). However, when the = UA is not registered e.g. due to missing credentials, the UA is normally = not reachable for SIP requests other than those sent within the dialog = of the emergency call. >>=20 >> Issue 2: How to send the update of the data __triggered by the UA__? = Do we assume that if the PSAP subscription is not available, the PSAP = prevents the UE from sending further information? >> If so, assuming PSAP is interested in any information = available, PSAP will need to subscribe in every single case of MESSAGE = with CAP where UA can potentially provide the update of the data. >> If not, do we assume that the UE would send updates of = data triggered by UE using other mechanism (MESSAGE?) than updates of = data requested by PSAP (NOTIFY)? >>=20 >> Issue 3: In some architectures (like 3GPP), signalling path for = inital request for dialog from the PSAP to the UA is different than = signalling path for the emergency request from the UA to the PSAP. If = the UA has subscription from network in country X and roams in country = Y, there is likelyhood that information that request comes from the PSAP = is lost due to missing trust among PSAP (in country Y), transit networks = (in country Y and X and possibly other transit countries), network of = registrar and proxy of the UA (in country X), transit networks (in = country X and Y and possibly other transit countries) and network of = edge proxy serving the UA (in country Y) . If so, the UA would then = handle the inital request for dialog as coming from an attacker UE and = possibly reject it. >>=20 >> Is draft-ietf-ecrit-data-only-ea-05 supposed to be a base for future = solution where updates of the data to the PSAP are sent? I do not think = it would work due to issues above. >>=20 >> If the UA ever wants to provide the updates of the data to the PSAP, = either triggred by the UA or requested by the PSAP, it would be better = to establish a dialog from beginning, e.g. send the initial data in = INVITE and updates (from UE) and requests for updates (from PSAP) in = INFOs. >>=20 >> Kind regards >>=20 >> Ivo Sedlacek=20 >>=20 >> Ericsson >> Mobile +420 608 234 709 >> ivo.sedlacek@ericsson.com >> www.ericsson.com=20 >>=20 >> This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer = _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBCgAGBQJR4+CCAAoJEGhJURNOOiAt50IH/1r04pjqikpsvo+Mb7uExHWJ > dM4zjOWZarOLyhglCcXddCi5EgaeIJ0myYhtc2qcJ9aCHqs7m5c5pfn0M9EZogUO > PHd0uT4d4a5aXr0eBFhva6W4t4j/aLGHBiVrpakX3hIveVYBfKNnwC1yMxgO1BUs > otCOmFjnEcykLe8ko6JRVRrHR7vEtYGltMR8IierpHap8C5zkXDB+NpdinCKNkeO > wHJZ72HD2sQi9qHYCI/VvgyMxkrCg05BvspixEkA4cIUL5lqeR4VIgENngofJ76f > Ub6mwtRgFNORRI3Tw2GJsM3RRg0zxrCh5Iv98DOmxsCeL6JdtSGYkLxm0Nj3qCU=3D > =3DFcHc > -----END PGP SIGNATURE----- > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Daniel.MONGRAIN@frequentis.com Mon Jul 15 06:40:44 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7321F11E8101 for ; Mon, 15 Jul 2013 06:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woDt3WF6BW+5 for ; Mon, 15 Jul 2013 06:40:35 -0700 (PDT) Received: from mail1.frequentis.com (mail1.frequentis.com [195.20.158.50]) by ietfa.amsl.com (Postfix) with ESMTP id 72F9E21F9DFB for ; Mon, 15 Jul 2013 06:40:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,668,1367964000"; d="scan'208,217";a="1208333" Received: from vie190nt.frequentis.frq ([172.16.1.190]) by mail1.frequentis.com with ESMTP; 15 Jul 2013 15:40:33 +0200 Received: from vie196nt.frequentis.frq ([172.16.1.196]) by vie190nt.frequentis.frq ([172.16.1.190]) with mapi id 14.02.0328.009; Mon, 15 Jul 2013 15:40:32 +0200 From: MONGRAIN Daniel To: Roger Marshall , "'ecrit@ietf.org'" Thread-Topic: Draft ecrit agenda for the IETF87 Berlin meeting Thread-Index: Ac5/SJh4D99CLaVoQKyLFLivTxDIFQCF400g Date: Mon, 15 Jul 2013 13:40:32 +0000 Message-ID: <7A5CECA875B00640B202F1DBA1815D230E7D1D89@vie196nt> References: In-Reply-To: Accept-Language: en-CA, en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.254.162] Content-Type: multipart/alternative; boundary="_000_7A5CECA875B00640B202F1DBA1815D230E7D1D89vie196nt_" MIME-Version: 1.0 Subject: Re: [Ecrit] Draft ecrit agenda for the IETF87 Berlin meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:40:44 -0000 --_000_7A5CECA875B00640B202F1DBA1815D230E7D1D89vie196nt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like 10 minutes to present the Service Coverage Scope draft and gau= ge the working group's interest on proceeding with it. As I cannot attend = the meeting, Brian Rosen has accepted to present on my behalf if allowed to= be on the agenda. Thanx, Dan ____________________________________________________ Dan Mongrain, eng. Senior Systems Engineer, Public Safety FREQUENTIS USA Inc. 9017 Red Branch Road, Suite 102 Columbia Maryland 21045 Phone +1-301-657-8001 Mobile +1-819-744-0491 Fax +1-301-657-8002 Web www.frequentis.com/usa E-Mail dan.mongrain@frequentis.com Incorporated in the State of Maryland EIN: 52-2178926 CAGE Code: 1XKR9 ____________________________________________________ Confidentiality Notice: This email message, including any attachments, is f= or the sole use of the intended recipient(s) and contains confidential and = privileged information. Any unauthorized review, use, disclosure or distrib= ution is prohibited. If you are not the intended recipient, please contact = the sender by reply email and destroy all copies of the original message an= d associated attachments. From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= oger Marshall Sent: July-12-13 5:56 PM To: 'ecrit@ietf.org' Subject: [Ecrit] Draft ecrit agenda for the IETF87 Berlin meeting See the ECRIT draft agenda below. We've got some additional time availabl= e. If there is some draft or topic you'd like to see included, let me know. Thanks. Roger & Marc. *** ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall) 20 min * Additional Data related to an Emergency Call (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss latest changes and if ready for WGLC 15 min. * Trustworthy Location Information (Bernard) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss impact of recent rewrite 15 min * Internet Protocol-based In-Vehicle Emergency Call (Hannes) http://tools.ietf.org/id/draft-rosen-ecrit-ecall-08.txt Intention: Discussion of draft & WG adoption question 15 min * eCall - background, current status, and requirements discussion li= nked to current ETSI work (Ban Al-Bakri) 15 min * Open Discussion 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_7A5CECA875B00640B202F1DBA1815D230E7D1D89vie196nt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like 10 minute= s to present the Service Coverage Scope draft and gauge the working group&#= 8217;s interest on proceeding with it.  As I cannot attend the meeting= , Brian Rosen has accepted to present on my behalf if allowed to be on the agenda.

 

Thanx,

Dan<= /p>

 

___________________________= _________________________
Dan Mongrain, eng.
Senior Systems Engineer, Public Safety<= /span>
FREQUENTIS USA Inc.

9017 Red Branch Road, Suite 102 Columbia Ma= ryland 21045
Phone   +1-301-657-8001<= br> Mobile   +1-819-744-0491
Fax      &nbs= p;+1-301-657-8002
Web      www.freque= ntis.com/usa
E-Mail    dan.mongrain@frequentis.com=

Incorporated in the State of Maryland

EIN: 52-2178926 CAGE Code: 1XKR9
____________________________________________________

Confidentiality Notice:<= /span> This email message, including any attac= hments, is for the sole use of the intended recipient(s) and contains confidential= and privileged information. Any unauthorized review, use, disclosure or di= stribution is prohibited. If you are not the intended recipient, please con= tact the sender by reply email and destroy all copies of the original message and associated attachments.<= span lang=3D"EN-US" style=3D"font-size:12.0pt;font-family:"Times New R= oman","serif";color:#1F497D">

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Roger Marshall
Sent: July-12-13 5:56 PM
To: 'ecrit@ietf.org'
Subject: [Ecrit] Draft ecrit agenda for the IETF87 Berlin meeting

 

See the= ECRIT draft agenda below.   We’ve got some additional time= available.

If ther= e is some draft or topic you’d like to see included, let me know.

&n= bsp;

Thanks.=

&n= bsp;

Roger &= amp; Marc.

&n= bsp;

***

&n= bsp;

ECRIT A= genda - 13:00-15:00, Monday, July 29, 2013 Berlin

&n= bsp;

10 min = * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall)

&n= bsp;

20 min = * Additional Data related to an Emergency Call (Brian)

http= ://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

Intenti= on: Discuss latest changes and if ready for WGLC

&n= bsp;

15 min.= * Trustworthy Location Information (Bernard)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/=

Intenti= on: Discuss impact of recent rewrite

&n= bsp;

15 min = * Internet Protocol-based In-Vehicle Emergency = Call (Hannes)

http://tools.i= etf.org/id/draft-rosen-ecrit-ecall-08.txt

Intenti= on: Discussion of draft & WG adoption question

&n= bsp;

15 min = * eCall - background, current status, and requirements discussion linked to= current ETSI work (Ban Al-Bakri)

&n= bsp;

15 min = * Open Discussion

&n= bsp;

 

 

CONFIDENTIALITY NOTICE: The information contain= ed in this message may be privileged and/or confidential. If you are not th= e intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, = distribution or copying of this communication or any attachment(s) is stric= tly prohibited. If you have received this message in error, please notify t= he sender immediately, and delete it and all attachments from your computer and network.

--_000_7A5CECA875B00640B202F1DBA1815D230E7D1D89vie196nt_-- From internet-drafts@ietf.org Mon Jul 15 10:34:17 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B326C21E8124; Mon, 15 Jul 2013 10:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zp3AvXvrKoHq; Mon, 15 Jul 2013 10:34:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C49521E80C0; Mon, 15 Jul 2013 10:34:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715173416.21707.86956.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 10:34:16 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:34:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens James Winterbottom Filename : draft-ietf-ecrit-additional-data-10.txt Pages : 84 Date : 2013-07-15 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call, the caller or the location which the PSAP may be able to use. This document describes data structures and a mechanism to convey such data to the PSAP. The mechanism uses a Uniform Resource Identifier (URI), which may point to either an external resource or an object in the body of the SIP message. The mechanism thus allows the data to be passed by reference (when the URI points to an external resource) or by value (when it points into the body of the message). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Mon Jul 15 10:44:01 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE3011E81C5 for ; Mon, 15 Jul 2013 10:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdFnV+B21o4u for ; Mon, 15 Jul 2013 10:43:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1721E8108 for ; Mon, 15 Jul 2013 10:43:55 -0700 (PDT) Received: from [172.16.254.104] ([80.92.118.93]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MZD0K-1UiMOJ3zMS-00L1k4; Mon, 15 Jul 2013 19:43:52 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jul 2013 19:43:50 +0200 Message-Id: <048408CB-5414-4548-8592-661CC4AD3DC8@gmx.net> To: "ecrit@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:Ac/61/jVK7s52CG8MgtcHRLZCPqDTusbPcmFjuKlLI2jt941R1+ +51GJVcMS1X5NMs2EL/oS462lQFCJs4Wayiyzj+WyowkXpLayVR3UG1hlXyx4EYDAzkbEkh gneC97Ug0ZcqkKIfFetINB6CSxuFFWoDfqeFCuAN9kkdmzOVvGlKS/wgmLqouIBhX3ZjTtP R03ISMdAQQL9uTcCUaOjg== Subject: [Ecrit] draft-ietf-ecrit-additional-data-10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:44:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all,=20 I have just uploaded a new version of the additional data draft.=20 The following changes have been made:=20 * Editorial changes throughout the document to improve readability=20 * James joined us as a co-author for his contributions to the document * Section about the Content-Disposition Parameter added (as discussed = on the list) * Updated examples=20 * Included an additional example illustrating the provided-by element * Fixed provided by schema. This caused changes to other schemas as = well * Re-wrote the privacy consideration section Here is the document:=20 http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-10 The diff can be found here:=20 http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-10 Ciao Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR5DTXAAoJEGhJURNOOiAtT9MH/jnxPS0xShhw/OoYJP3HbWn2 gZTpxcEgW/iaR8nqgH7nydruzihDZhWB+rhy744JzKQuQGMFY1tbqwoBtsjcN8eZ KihFwXxGYYYpLT3KOG0MNVim/kEFW+yURBAo2nhivF51t5rqJM76VRTUXjk94dgy dFysUhx041OT6NsGuxGIcsW5X1snFgHhvims+P7NJt93cqmaPOoYHYkparcJEsqw w4RcUUHWRGPUJ4e0wt45CdmYgz9CpR8wJcYHQbxhjB/K7ZlQXhJ1bNQ4njWep2F7 4omKn7osh8JqcxPYb21gAmdo0oLglrNwW++Z8g3DIhRXp6pH8NGDiiWt0XF2ri8=3D =3DTxce -----END PGP SIGNATURE----- From trac+ecrit@trac.tools.ietf.org Mon Jul 15 11:33:47 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541151F0D42 for ; Mon, 15 Jul 2013 11:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJNZjYuaAlUt for ; Mon, 15 Jul 2013 11:33:46 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AF8231F0D46 for ; Mon, 15 Jul 2013 11:33:31 -0700 (PDT) Received: from localhost ([127.0.0.1]:36740 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UynaQ-0007MP-5H; Mon, 15 Jul 2013 20:33:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Mon, 15 Jul 2013 18:33:26 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/15 Message-ID: <065.2ea1df71cf6659845d5501a8885c7938@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130715183332.AF8231F0D46@ietfa.amsl.com> Resent-Date: Mon, 15 Jul 2013 11:33:31 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #15: Definitions of Place Shifting, Time Shifting, Location Theft and Location swapping X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:33:47 -0000 #15: Definitions of Place Shifting, Time Shifting, Location Theft and Location swapping Currently there are no definitions of the terms "Place Shifting", "Time Shifting", "Location Theft" and "Location Swapping". The proposal is to add the following text to Section 1.1: The following additional terms apply to location spoofing: "Place Shifting" is where the attacker constructs a PIDF-LO for a location other than where they are currently located. In some cases, place shifting can be limited in range (e.g., within the coverage area of a particular cell tower). "Time Shifting" is where the attacker uses or re-uses location information that was valid in the past, but is no longer valid because the attacker has moved. "Location Theft" is where the attacker captures a Target's location information and presents it as their own. Location theft can occur on a one-off basis, or may be continuous (e.g., where the attacker has gained control over the victim's device). Location theft may also be combined with time shifting to present someone else's location information after the original Target has moved. Where the Target and attacker collude, the term "location swapping" is used. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Mon Jul 15 11:38:53 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF41311E8189 for ; Mon, 15 Jul 2013 11:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHUf4t5hKbgo for ; Mon, 15 Jul 2013 11:38:52 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 92D5521F86CC for ; Mon, 15 Jul 2013 11:38:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:37321 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Uynfd-0002WG-LC; Mon, 15 Jul 2013 20:38:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Mon, 15 Jul 2013 18:38:49 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/16 Message-ID: <065.a67b4f0b0474478ba0c3849e74c58167@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130715183852.92D5521F86CC@ietfa.amsl.com> Resent-Date: Mon, 15 Jul 2013 11:38:52 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #16: Re-organization of Section 3.1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:38:53 -0000 #16: Re-organization of Section 3.1 Material relating to location swapping is currently contained in various places in the document. The proposal is to consolidate this into Section 3.1, and also include more detail relating to how to address the location swapping threat via location signing. Proposal is to change the text of Section 3.1 to the following: 3.1. Signed Location by Value With location signing, a location server signs the location information before it is sent to the end host, (the entity subject to the location determination process). The signed location information is then verified by the location recipient and not by the target. A straw-man proposal for location signing is provided in "Digital Signature Methods for Location Dependability" [I-D.thomson-geopriv- location-dependability]. Figure 1 shows the communication model with the target requesting signed location in step (a), the location server returns it in step (b) and it is then conveyed to the location recipient in step (c) who verifies it. For SIP, the procedures described in "Location Conveyance for the Session Initiation Protocol" [RFC6442] are applicable for location conveyance. +-----------+ +-----------+ | | | Location | | LIS | | Recipient | | | | | +-+-------+-+ +----+------+ ^ | --^ | | -- Geopriv |Req. | -- Location |Signed |Signed -- Geopriv Configuration |Loc. |Loc. -- Using Protocol Protocol |(a) |(b) -- (e.g., SIP) | v -- (c) +-+-------+-+ -- | Target / | -- | End Host + | | +-----------+ Figure 1: Location Signing In order to limit replay attacks, [I.D.thomson-geopriv-location- dependability] proposes the addition of a "validity" element to the PIDF-LO, including a "from" sub-element containing the time that location information was validated by the signer, as well as an "until" sub-element containing the last time that the signature can be considered valid. One of the consequences of including an "until" element is that even a stationary target would need to periodically obtain a fresh PIDF- LO, or incur the additional delay of querying during an emergency call. Although privacy-preserving procedures may be disabled for emergency calls, by design, PIDF-LO objects limit the information available for real-time attribution. As noted in [RFC5985] Section 6.6: The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain identity are either omitted or contain unlinked pseudonyms [RFC3693]. A unique, unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence "entity" attribute of the PIDF document. Optional parameters such as the "contact" and "deviceID" elements [RFC4479] are not used. Also, the device referred to in the PIDF-LO may not necessarily be the same entity conveying the PIDF-LO to the PSAP. As noted in [RFC6442] Section 1: In no way does this document assume that the SIP user agent client that sends a request containing a location object is necessarily the Target. The location of a Target conveyed within SIP typically corresponds to that of a device controlled by the Target, for example, a mobile phone, but such devices can be separated from their owners, and moreover, in some cases, the user agent may not know its own location. Without the ability to tie the target identity to the identity asserted in the SIP message, it is possible for an attacker to cut and paste a PIDF-LO obtained by a different device or user into a SIP INVITE and send this to the PSAP. This cut and paste attack could succeed even when a PIDF-LO is signed, or [RFC4474] is implemented. To address location-swapping attacks, [I-D.thomson-geopriv-location- dependability] proposes addition of an "identity" element which could include a SIP URI (enabling comparison against the identity asserted in the SIP headers) or an X.509v3 certificate. If the target was authenticated by the LIS, an "authenticated" attribute is added. However, inclusion of an "identity" attribute could enable location tracking, so that a "hash" element is also proposed which could contain a hash of the content of the "identity" element instead. In practice, such a hash would not be much better for real-time validation than a pseudonym. Location signing is unlikely to deter attacks launched by bot-nets, since the work required to verify the location signature is considerable. However, while bot-nets are unlikely to be deterred by location signing, accurate location information would limit the subset of the bot-net that could be used for an attack, as only hosts within the PSAP serving area would be useful in placing emergency calls. Location signing is also difficult when the host obtains location via mechanisms such as GPS, unless trusted computing approaches, with tamper-proof GPS modules, can be applied. Otherwise, an end host can pretend to have a GPS device, and the recipient will need to rely on its ability to assess the level of trust that should be placed in the end host location claim. [NENA-i2] Section 3.7 includes operational recommendations relating to location signing: Location determination is out of scope for NENA, but we can offer guidance on what should be considered when designing mechanisms to report location: 1. The location object should be digitally signed. 2. The certificate for the signer (LIS operator) should be rooted in VESA. For this purpose, VPC and ERDB operators should issue certs to LIS operators. 3. The signature should include a timestamp. 4. Where possible, the Location Object should be refreshed periodically, with the signature (and thus the timestamp) being refreshed as a consequence. 5. Anti-spoofing mechanisms should be applied to the Location Reporting method. [Note: The term Valid Emergency Services Authority (VESA) refers to the root certificate authority.] As noted above, signing of location objects implies the development of a trust hierarchy that would enable a certificate chain provided by the LIS operator to be verified by the PSAP. Rooting the trust hierarchy in VESA can be accomplished either by having the VESA directly sign the LIS certificates, or by the creation of intermediate CAs certified by the VESA, which will then issue certificates to the LIS. In terms of the workload imposed on the VESA, the latter approach is highly preferable. However, this raises the question of who would operate the intermediate CAs and what the expectations would be. In particular, the question arises as to the requirements for LIS certificate issuance, and how they would compare to requirements for issuance of other certificates such as an SSL/TLS web certificate. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Mon Jul 15 11:42:50 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB72111E8179 for ; Mon, 15 Jul 2013 11:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwhca7kNQlIs for ; Mon, 15 Jul 2013 11:42:49 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7211B11E817C for ; Mon, 15 Jul 2013 11:42:49 -0700 (PDT) Received: from localhost ([127.0.0.1]:37576 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UynjN-0003Fr-76; Mon, 15 Jul 2013 20:42:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Mon, 15 Jul 2013 18:42:41 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/17 Message-ID: <065.3817af94c27189bfb7e27cf718565131@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130715184249.7211B11E817C@ietfa.amsl.com> Resent-Date: Mon, 15 Jul 2013 11:42:49 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #17: Rewrite of Section 4 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:42:50 -0000 #17: Rewrite of Section 4 As part of the reorganization of Section 3.1, some of the material from Section 4 has been moved there, so that Section 4 is now proposed to read as follows: 4. Location Trust Assessment The ability to assess the level of trustworthiness of conveyed location information is important, since this makes it possible to understand how much value should be placed on location information, as part of the decision making process. As an example, if automated location information is understood to be highly suspect, a call taker can put more effort into obtaining location information from the caller. Location trust assessment has value regardless of whether the location has been conveyed securely (via signed location, location- by-reference or proxy-added location) or not (via location-by-value without location signing), since secure conveyance does not provide assurance relating to the validity or provenance of location data. To prevent location-swapping attacks, the "entity" element of the PIDF-LO is of limited value if an unlinked pseudonym is provided in this field. However, if the LIS authenticates the target, then the linkage between the pseudonym and the target identity can be recovered post-mortem. As noted in [I.D.thomson-geopriv-location-dependability], if the location object was signed, the location recipient has additional information on which to base their trust assessment, such as the validity of the signature, the identity of the target, the identity of the LIS, whether the LIS authenticated the target, and the identifier included in the "entity" field. Caller accountability is also an important aspect of trust assessment. Can the individual purchasing the device or activating service be identified or did the call originate from a non-service initialized (NSI) device whose owner cannot be determined? Prior to the call, was the caller authenticated at the network or application layer? In the event of a prank call, can audit logs be made available to an investigator, or can information relating to the owner of an unlinked pseudonym be provided, enabling investigators to unravel the chain of events that lead to the attack? In practice, the ability to identify a caller may decrease the likelihood of caller misbehavior. For example, where emergency calls have been allowed from handsets lacking a SIM card, or where ownership of the SIM card cannot be determined, the frequency of nuisance calls has often been unacceptably high [TASMANIA][UK][SA]. In practice, the source of the location data is important for location trust assessment. For example, location provided by a Location Information Server (LIS) whose administrator has an established history of meeting emergency location accuracy requirements (e.g. Phase II) may be considered more reliable than location information provided by a third party Location Service Provider (LSP) that disclaims use of location information for emergency purposes. However, even where an LSP does not attempt to meet the accuracy requirements for emergency location, it still may be able to provide information useful in assessing about how reliable location information is likely to be. For example, was location determined based on the nearest cell tower or 802.11 Access Point (AP), or was a triangulation method used? If based on cell tower or AP location data, was the information obtained from an authoritative source (e.g. the tower or AP owner) and when was the last time that the location of the tower or access point was verified? For real-time validation, information in the signaling and media packets can be cross checked against location information. For example, it may be possible to determine the city, state, country or continent associated with the IP address included within SIP Via: or Contact: headers, or the media source address, and compare this against the location information reported by the caller or conveyed in the PIDF-LO. However, in some situations only entities close to the caller may be able to verify the correctness of location information. Real-time validation of the timestamp contained within PIDF-LO objects (reflecting the time at which the location was determined) is also challenging. To address time-shifting attacks, the "timestamp" element of the PIDF-LO, defined in [RFC3863], can be examined and compared against timestamps included within the enclosing SIP message, to determine whether the location data is sufficiently fresh. However, the timestamp only represents an assertion by the LIS, which may or may not be trustworthy. For example, the recipient of the signed PIDF-LO may not know whether the LIS supports time synchronization, or whether it is possible to reset the LIS clock manually without detection. Even if the timestamp was valid at the time location was determined, a time period may elapse between when the PIDF-LO was provided and when it is conveyed to the recipient. Periodically refreshing location information to renew the timestamp even though the location information itself is unchanged puts additional load on LISes. As a result, recipients need to validate the timestamp in order to determine whether it is credible. While this document focuses on the discussion of real-time determination of suspicious emergency calls, the use of audit logs may help in enforcing accountability among emergency callers. For example, in the event of a prank call, information relating to the owner of the unlinked pseudonym could be provided to investigators, enabling them to unravel the chain of events that lead to the attack. However, while auditability is an important deterrent, it is likely to be of most benefit in situations where attacks on the emergency services system are likely to be relatively infrequent, since the resources required to pursue an investigation are likely to be considerable. However, although real-time validation based on PIDF- LO elements is challenging, where LIS audit logs are available (such as where a law enforcement agency can present a subpoena), linking of a pseudonym to the device obtaining location can be accomplished in a post-mortem. Where attacks are frequent and continuous, automated mechanisms are required. For example, it might be valuable to develop mechanisms to exchange audit trails information in a standardized format between ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish potentially fraudulent emergency calls from real emergencies. While a CAPTCHA-style test may be applied to suspicious calls to lower the risk from bot-nets, this is quite controversial for emergency services, due to the risk of delaying or rejecting valid calls. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: ecrit From br@brianrosen.net Mon Jul 15 12:13:49 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E30121E8133 for ; Mon, 15 Jul 2013 12:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.264 X-Spam-Level: X-Spam-Status: No, score=-100.264 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISOhvbQZsIvR for ; Mon, 15 Jul 2013 12:13:45 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8A11E8177 for ; Mon, 15 Jul 2013 12:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=qfTWiab4kgO92CbBkSH5zzVkOmHsC0aKgmcE83wJJHc=; b=NHAxeDRO2dUCkdSSB2JLxVgWKPS6TjnK7FnRbTeq5dcGDsfqkGHRimiEczD45cGcmYTrwv1xk+UFHGLVAsFcUeZCBO9UXBx6QnGy91wRMIaFG5XiQ4JCZx38GPsa7NDQ+Oj0K2Y60CA2AT8/Lnm47+DLXhfnnjfwqESWWsQnsY4=; Received: from neustargw.va.neustar.com ([209.173.53.233]:50623 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UyoDQ-00085H-AH; Mon, 15 Jul 2013 15:13:44 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <048408CB-5414-4548-8592-661CC4AD3DC8@gmx.net> Date: Mon, 15 Jul 2013 15:13:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <98E5F4A5-9363-4878-A24A-AF3C9E55B3E1@brianrosen.net> References: <048408CB-5414-4548-8592-661CC4AD3DC8@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:13:49 -0000 Commenting on a draft of which I am an author :) The IANA considerations, in section 9.1.7. Additional Data Blocks = Registry says: This document creates a new sub-registry called 'Additional Data Blocks' in the purpose registry established by RFC 3261 [RFC3261]. Unfortunately, there is no "purpose" registry. There is only a list of = references in the Header parameters table that refer to RFCs that define = new purpose values. I think we should fix this and have "Additional Data" create the purpose = registry, adding one new value and the sub registry. Brian On Jul 15, 2013, at 1:43 PM, Hannes Tschofenig = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Hi all,=20 >=20 > I have just uploaded a new version of the additional data draft.=20 >=20 > The following changes have been made:=20 > * Editorial changes throughout the document to improve readability=20 > * James joined us as a co-author for his contributions to the = document > * Section about the Content-Disposition Parameter added (as discussed = on the list) > * Updated examples=20 > * Included an additional example illustrating the provided-by element > * Fixed provided by schema. This caused changes to other schemas as = well > * Re-wrote the privacy consideration section >=20 > Here is the document:=20 > http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-10 >=20 > The diff can be found here:=20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-10 >=20 > Ciao > Hannes >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org >=20 > iQEcBAEBCgAGBQJR5DTXAAoJEGhJURNOOiAtT9MH/jnxPS0xShhw/OoYJP3HbWn2 > gZTpxcEgW/iaR8nqgH7nydruzihDZhWB+rhy744JzKQuQGMFY1tbqwoBtsjcN8eZ > KihFwXxGYYYpLT3KOG0MNVim/kEFW+yURBAo2nhivF51t5rqJM76VRTUXjk94dgy > dFysUhx041OT6NsGuxGIcsW5X1snFgHhvims+P7NJt93cqmaPOoYHYkparcJEsqw > w4RcUUHWRGPUJ4e0wt45CdmYgz9CpR8wJcYHQbxhjB/K7ZlQXhJ1bNQ4njWep2F7 > 4omKn7osh8JqcxPYb21gAmdo0oLglrNwW++Z8g3DIhRXp6pH8NGDiiWt0XF2ri8=3D > =3DTxce > -----END PGP SIGNATURE----- > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From RMarshall@telecomsys.com Mon Jul 15 14:06:23 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BD521E818F for ; Mon, 15 Jul 2013 14:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Acu8Ne-2Yz1A for ; Mon, 15 Jul 2013 14:06:19 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAEFA21E8147 for ; Mon, 15 Jul 2013 14:06:18 -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.1/8.14.1) with ESMTP id r6FL5l85003050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 15 Jul 2013 14:05:48 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.236]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Mon, 15 Jul 2013 14:05:47 -0700 From: Roger Marshall To: "'ecrit@ietf.org'" Thread-Topic: WGLC announce - draft-ietf-ecrit-trustworthy-location Thread-Index: Ac6BncA6cDIDVrUhS66bzcCtDSgL4g== Date: Mon, 15 Jul 2013 21:05:47 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC36C822SEAEXMB2telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] WGLC announce - draft-ietf-ecrit-trustworthy-location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:06:23 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC36C822SEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This starts WGLC for draft-ietf-ecrit-trustworthy-location. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Please review the draft and provide comments to the list before our ECRIT m= eeting in Berlin, 2 weeks from today, July 29, 2013. 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_FBD5AAFFD0978846BF6D3FAB4C892ACC36C822SEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This starts WGLC fo= r draft-ietf-ecrit-trustworthy-location.

 

The draft can be fo= und at:

http://datatracker.ietf.org/doc/draft-ietf-ecrit-tru= stworthy-location/

 

Please review the d= raft and provide comments to the list before our ECRIT meeting in Berlin, 2= weeks from today, July 29, 2013.

&n= bsp;

Thanks,=

&n= bsp;

Marc &a= mp; 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_FBD5AAFFD0978846BF6D3FAB4C892ACC36C822SEAEXMB2telecomsy_-- From RMarshall@telecomsys.com Mon Jul 15 14:24:50 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7211E8237 for ; Mon, 15 Jul 2013 14:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1rAjVM0QT5i for ; Mon, 15 Jul 2013 14:24:46 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 31FA011E8210 for ; Mon, 15 Jul 2013 14:24:40 -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.1/8.14.1) with ESMTP id r6FLOKji013731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 15 Jul 2013 14:24:20 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.236]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Mon, 15 Jul 2013 14:24:20 -0700 From: Roger Marshall To: "'ecrit@ietf.org'" Thread-Topic: WGLC announce - draft-ietf-ecrit-country-emg-urn Thread-Index: Ac6BoZqpaQGpA7uKRFqiD1Jt22lQjw== Date: Mon, 15 Jul 2013 21:24:19 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC36CD93SEAEXMB2telecomsy_" MIME-Version: 1.0 Subject: Re: [Ecrit] WGLC announce - draft-ietf-ecrit-country-emg-urn X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:24:51 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC36CD93SEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This starts WGLC for draft-ietf-ecrit-country-emg-urn. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-ecrit-country-emg-urn/ Please review the draft and provide comments to the list before our ECRIT m= eeting in Berlin, 2 weeks from today, July 29, 2013. 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_FBD5AAFFD0978846BF6D3FAB4C892ACC36CD93SEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This starts WGLC fo= r draft-ietf-ecrit-country-emg-urn.

 

The draft can be fo= und at:

http://datatracker.ietf.org/doc/draft-ietf-ecrit-= country-emg-urn/

 

Please review the d= raft and provide comments to the list before our ECRIT meeting in Berlin, 2= weeks from today, July 29, 2013.

&n= bsp;

Thanks,=

&n= bsp;

Marc &a= mp; 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_FBD5AAFFD0978846BF6D3FAB4C892ACC36CD93SEAEXMB2telecomsy_-- From internet-drafts@ietf.org Mon Jul 15 15:03:18 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726EE21E8111; Mon, 15 Jul 2013 15:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSYwYItbUlno; Mon, 15 Jul 2013 15:03:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 987D621E80C8; Mon, 15 Jul 2013 15:03:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715220313.32107.6898.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 15:03:13 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-06.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:03:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Data-Only Emergency Calls Author(s) : Brian Rosen Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-data-only-ea-06.txt Pages : 21 Date : 2013-07-15 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-data-only-ea-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From keith.drage@alcatel-lucent.com Tue Jul 16 03:20:12 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8062711E829E for ; Tue, 16 Jul 2013 03:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KfVMQa+CkTu for ; Tue, 16 Jul 2013 03:20:06 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 80EAA11E829A for ; Tue, 16 Jul 2013 03:20:04 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6GAJ4Ld020658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jul 2013 05:19:17 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GAJ2Y8013619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 12:19:03 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 16 Jul 2013 12:19:02 +0200 From: "DRAGE, Keith (Keith)" To: Brian Rosen , Hannes Tschofenig Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-10 Thread-Index: AQHOgYLtX7bhhlSzlUWl/M+tAMRG9Jll+kiAgAEYEhA= Date: Tue, 16 Jul 2013 10:19:01 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B06A883@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <048408CB-5414-4548-8592-661CC4AD3DC8@gmx.net> <98E5F4A5-9363-4878-A24A-AF3C9E55B3E1@brianrosen.net> In-Reply-To: <98E5F4A5-9363-4878-A24A-AF3C9E55B3E1@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 10:20:12 -0000 The relevant document that defines the policy here is RFC 3968: Some SIP header field parameters only accept a set of predefined parameter values. For example, a parameter indicating the transport protocol in use may only accept the predefined tokens TCP, UDP, and SCTP as valid values. Registering all parameter values for all SIP header field parameters of this type would require a large number of subregistries. Instead, we have chosen to register parameter values by reference. That is, the entry in the parameter registry for a given header field parameter contains references to the RFCs defining new values of the parameter. References to RFCs defining parameter values appear in double brackets in the registry. So, the header field parameter registry contains a column that indicates whether or not each parameter only accepts a set of predefined values. Implementers of parameters with a "yes" in that column need to find all the valid parameter values in the RFCs provided as references. So given an explicit approved statement I think you should come up with bet= ter arguments for a separate registry, rather than "I think we should fix t= his". I'm not saying you may not be able to justify it, rather that if we f= ollow your policy without control we will be adding dozens of extra tables = to the registries, and noone will be able to find anything. Whatever the WG decides, you still need to amend the header field parameter= s table and this document currently does not fulfil that function. Additional comments I spotted while looking at this: I'd note that it is the=20 "purpose" header field parameter [of the Call Info header field] Rather than the 'purpose' parameter. And on 9.1.1: " As defined in [RFC5226], this registry operates under "Expert Review" rules." RFC 5226 does not define how this registry operates. What you want to say i= s that the expert review rules are defined in RFC 5226. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: 15 July 2013 20:14 > To: Hannes Tschofenig > Cc: ecrit@ietf.org WG > Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10 >=20 > Commenting on a draft of which I am an author :) >=20 > The IANA considerations, in section 9.1.7. Additional Data Blocks > Registry > says: >=20 > This document creates a new sub-registry called 'Additional Data > Blocks' in the purpose registry established by RFC 3261 [RFC3261]. >=20 > Unfortunately, there is no "purpose" registry. There is only a list of > references in the Header parameters table that refer to RFCs that define > new purpose values. > I think we should fix this and have "Additional Data" create the purpose > registry, adding one new value and the sub registry. >=20 > Brian >=20 > On Jul 15, 2013, at 1:43 PM, Hannes Tschofenig > wrote: >=20 > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Hi all, > > > > I have just uploaded a new version of the additional data draft. > > > > The following changes have been made: > > * Editorial changes throughout the document to improve readability > > * James joined us as a co-author for his contributions to the document > > * Section about the Content-Disposition Parameter added (as discussed > on the list) > > * Updated examples > > * Included an additional example illustrating the provided-by element > > * Fixed provided by schema. This caused changes to other schemas as > well > > * Re-wrote the privacy consideration section > > > > Here is the document: > > http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-10 > > > > The diff can be found here: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-10 > > > > Ciao > > Hannes > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > > Comment: GPGTools - http://gpgtools.org > > > > iQEcBAEBCgAGBQJR5DTXAAoJEGhJURNOOiAtT9MH/jnxPS0xShhw/OoYJP3HbWn2 > > gZTpxcEgW/iaR8nqgH7nydruzihDZhWB+rhy744JzKQuQGMFY1tbqwoBtsjcN8eZ > > KihFwXxGYYYpLT3KOG0MNVim/kEFW+yURBAo2nhivF51t5rqJM76VRTUXjk94dgy > > dFysUhx041OT6NsGuxGIcsW5X1snFgHhvims+P7NJt93cqmaPOoYHYkparcJEsqw > > w4RcUUHWRGPUJ4e0wt45CdmYgz9CpR8wJcYHQbxhjB/K7ZlQXhJ1bNQ4njWep2F7 > > 4omKn7osh8JqcxPYb21gAmdo0oLglrNwW++Z8g3DIhRXp6pH8NGDiiWt0XF2ri8=3D > > =3DTxce > > -----END PGP SIGNATURE----- > > _______________________________________________ > > 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 br@brianrosen.net Tue Jul 16 06:01:23 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51D421F9FDA for ; Tue, 16 Jul 2013 06:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.234 X-Spam-Level: X-Spam-Status: No, score=-100.234 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MSQXJnYgnZ5 for ; Tue, 16 Jul 2013 06:01:15 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id D81B221F9A1E for ; Tue, 16 Jul 2013 06:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=Mime-Version:Message-Id:To:References:Date:Subject:Content-Type:From; bh=KXhkyMBn+c6NKIzh0NiBsUeTT/jhN4+K6wtymwV29Fw=; b=YTTrcEh/kg16ZM7KBa0tYHXBco/GflgtM4+kHMW2qBeR3b4POzLdyAp9vwL3+60Yr10iq2SxvBgecy+ub+zK2XWUsWvMBkRf09/PslgBztOv6OyTTiJ+7GVn+QrA7aRHYiHB3OnM3CqxJ5HkTlDmcsjOOF/WjjZqbi15ZY7Bl44=; Received: from neustargw.va.neustar.com ([209.173.53.233]:56587 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uz4s6-0004rB-Gj for ecrit@ietf.org; Tue, 16 Jul 2013 09:00:50 -0400 From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_5368BC97-4C49-4B58-BE31-9B6F241AC2D6" Date: Tue, 16 Jul 2013 09:00:49 -0400 References: <20130715225016.14629.74436.idtracker@ietfa.amsl.com> To: "ecrit@ietf.org WG" Message-Id: <2165A8E8-9551-4FEB-ADD5-E37C4892EE35@brianrosen.net> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Subject: [Ecrit] Fwd: I-D Action: draft-marshall-ecrit-similar-location-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:01:24 -0000 --Apple-Mail=_5368BC97-4C49-4B58-BE31-9B6F241AC2D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We updated this draft. As a reminder, it allows location information to be returned in a = findservice response for two purposes: a) Return elements (CAtypes) not included in the request that are part = of the valid location b) Return alternative valid locations when the location in the request = is invalid. The changes involved improved XML in the examples, and an improved RELAX = NG schema, as well as some text improvements. None of the authors = really know how to create RELAX NG schemas, so the current work is = likely pretty bad. We'll recruit some help for that. We believe it is an important aid to getting good location for emergency = calls. It is intended to be used when provisioning a LIS, rather than = at emergency call time. We would appreciate review and comments on this doc. =20 Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-marshall-ecrit-similar-location-02.txt > Date: July 15, 2013 6:50:16 PM EDT > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : A LoST extension to support return of complete = and similar location info > Author(s) : Roger Marshall > Jeff Martin > Brian Rosen > Filename : draft-marshall-ecrit-similar-location-02.txt > Pages : 13 > Date : 2013-07-15 >=20 > Abstract: > This document introduces a new way to provide returned location > information in LoST responses that is either of a completed or > similar form to the original input civic location, based on whether = a > valid or invalid location is returned within the findServiceResponse > message. This document defines a new extension to the > findServiceResponse message within the LoST protocol [RFC5222] that > enables the LoST protocol to return a completed civic location > element set for a valid response, and one or more suggested sets of > civic location information for invalid LoST responses. These two > types of civic addresses are referred to as either "complete" or > "similar" locations, and are included as compilation of ca type xml > elements within the existing response message structure. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-marshall-ecrit-similar-location >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-marshall-ecrit-similar-location-02 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-marshall-ecrit-similar-location-0= 2 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_5368BC97-4C49-4B58-BE31-9B6F241AC2D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We = updated this draft.

As a reminder, it allows location = information to be returned in a findservice response for two = purposes:
a) Return elements (CAtypes) not included in the = request that are part of the valid location
b) Return = alternative valid locations when the location in the request is = invalid.

The changes involved improved XML in = the examples, and an improved RELAX NG schema, as well as some text = improvements.  None of the authors really know how to create RELAX = NG schemas, so the current work is likely pretty bad.  We'll = recruit some help for that.

We believe it is an = important aid to getting good location for emergency calls.  It is = intended to be used when provisioning a LIS, rather than at emergency = call time.

We would appreciate review and = comments on this doc. =   

Brian

Begin = forwarded message:

Subject: I-D Action: = draft-marshall-ecrit-similar-location-02.txt
Date: July 15, 2013 = 6:50:16 PM EDT
Reply-To: = internet-drafts@ietf.org
<= /span>


A New Internet-Draft is available from the = on-line Internet-Drafts directories.


Title =           : A LoST = extension to support return of complete and similar location = info
= Author(s)       : Roger = Marshall
=             &n= bsp;           &nbs= p;Jeff Martin
=             &n= bsp;           &nbs= p;Brian Rosen
= Filename        : = draft-marshall-ecrit-similar-location-02.txt
Pages =           : = 13
= Date =            : = 2013-07-15

Abstract:
  This document introduces a = new way to provide returned location
  information in LoST = responses that is either of a completed or
  similar form = to the original input civic location, based on whether a
=   valid or invalid location is returned within the = findServiceResponse
  message.  This document defines = a new extension to the
  findServiceResponse message = within the LoST protocol [RFC5222] that
  enables the LoST = protocol to return a completed civic location
  element = set for a valid response, and one or more suggested sets of
=   civic location information for invalid LoST responses. =  These two
  types of civic addresses are referred to = as either "complete" or
  "similar" locations, and are = included as compilation of ca type xml
  elements within = the existing response message structure.


The IETF datatracker = status page for this draft is:
https://datatracker.ietf.org/doc/draft-marshall-ecrit-similar-locati= on

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-marshall-ecrit-similar-location-02=

A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-marshall-ecrit-similar-loc= ation-02


Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=
= --Apple-Mail=_5368BC97-4C49-4B58-BE31-9B6F241AC2D6-- From br@brianrosen.net Tue Jul 16 09:15:44 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4240421E8085 for ; Tue, 16 Jul 2013 09:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.277 X-Spam-Level: X-Spam-Status: No, score=-100.277 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puvmSiuuFcP1 for ; Tue, 16 Jul 2013 09:15:39 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 936EA21E8063 for ; Tue, 16 Jul 2013 09:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=Mime-Version:Message-Id:To:References:Date:Subject:Content-Type:From; bh=dR/DNySsdtLfs3sNZ3ZPScqzySSCu6GdgU5WC6/MuHU=; b=c2dDYZ57uxFehuxZl2Jc7KB2XkDUAVHz1KbnjjPbkJLQTm7uIYhw4+uH9nmX1is1ZSEgqejIV58/hwF6A7P2XEDfpx3/QyhrBTalCj4AFtwHrU2QjPtAwdfBlNX7tXSeYbk8Wq+oab3/Ze0Z7qkWw1Iilczcys1hvKJR2K2I9Nw=; Received: from neustargw.va.neustar.com ([209.173.53.233]:51441 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Uz7uT-0005Wb-6D for ecrit@ietf.org; Tue, 16 Jul 2013 12:15:29 -0400 From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_C788A6B6-797A-4C83-B705-F9D7B06024C2" Date: Tue, 16 Jul 2013 12:15:27 -0400 References: <20130715220313.32107.6898.idtracker@ietfa.amsl.com> To: "ecrit@ietf.org WG" Message-Id: <6B921656-F31C-4592-9A94-34646E0B6836@brianrosen.net> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Subject: [Ecrit] Fwd: I-D Action: draft-ietf-ecrit-data-only-ea-06.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:15:44 -0000 --Apple-Mail=_C788A6B6-797A-4C83-B705-F9D7B06024C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We revved this doc following the discussion from the last meeting. We made the CAP message a block of additional-data. This provides both = by-reference and by-value passing of the CAP message. It also lets us = use my proposed Event package to do updates of the CAP message. I think this is ready to go. Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-06.txt > Date: July 15, 2013 6:03:13 PM EDT > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org >=20 >=20 > 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. >=20 > Title : Data-Only Emergency Calls > Author(s) : Brian Rosen > Henning Schulzrinne > Hannes Tschofenig > Filename : draft-ietf-ecrit-data-only-ea-06.txt > Pages : 21 > Date : 2013-07-15 >=20 > 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. >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-data-only-ea-06 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_C788A6B6-797A-4C83-B705-F9D7B06024C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We = revved this doc following the discussion from the last = meeting.

We made the CAP message a block of = additional-data.  This provides both by-reference and by-value = passing of the CAP message.  It also lets us use my proposed Event = package to do updates of the CAP message.

I = think this is ready to = go.

Brian

Begin forwarded = message:

Subject: [Ecrit] I-D Action: = draft-ietf-ecrit-data-only-ea-06.txt
Date: July 15, 2013 = 6:03:13 PM EDT


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
Author(s) =       : Brian Rosen
=             &n= bsp;           &nbs= p;Henning Schulzrinne
=             &n= bsp;           &nbs= p;Hannes Tschofenig
Filename =        : = draft-ietf-ecrit-data-only-ea-06.txt
Pages =           : = 21
= Date =            : = 2013-07-15

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:
ht= tps://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea

Th= ere's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-06

= A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-data-only-ea-06=


Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
Ecrit mailing = list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
<= /div>

= --Apple-Mail=_C788A6B6-797A-4C83-B705-F9D7B06024C2-- From ivo.sedlacek@ericsson.com Wed Jul 17 02:51:28 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0DC21F9970 for ; Wed, 17 Jul 2013 02:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-nfW6Gu3rCl for ; Wed, 17 Jul 2013 02:51:23 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3B82121F9703 for ; Wed, 17 Jul 2013 02:51:22 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-6d-51e6691811c3 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id ED.A3.19388.81966E15; Wed, 17 Jul 2013 11:51:20 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.30]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Wed, 17 Jul 2013 11:51:20 +0200 From: Ivo Sedlacek To: Brian Rosen Thread-Topic: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 Thread-Index: AQHOgVokZOlzZkUeiUS40a3EuQRgYJlomolw Date: Wed, 17 Jul 2013 09:51:19 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010F7801@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se> <4BD09290-F3F3-45CE-BF56-1896B76EE51D@brianrosen.net> In-Reply-To: <4BD09290-F3F3-45CE-BF56-1896B76EE51D@brianrosen.net> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061010F7801ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvra5E5rNAg0XNRhZP709js2hc9JTV gcnj/re/7B5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4d3U+Y8HmWYwVl+e9Z29gbG5g7GLk5JAQ MJFY8uYLG4QtJnHh3nogm4tDSOAwo8TTvf+ZIJzFjBLHp1xkB6liE9CTmLjlCCuILSKgLLHz VidYnFlAVeJc42MWEFtYwFHi+enDbBA1ThLzrl1hgbCNJDbsvwC2mQWoftuKE2A2r4C3RMv/ VSwQy44ySpw785IJJMEJ1Pxm43ewZkYBWYmrf3oZIZaJS9x6Mp8J4mwBiSV7zjND2KISLx// Y4WwFSV2nm1nhqjPl3i+qZUNYpmgxMmZT1gmMIrOQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18 zQxjnznwmAlZfAEj+ypG9tzEzJz0cvNNjMDYOrjlt8EOxk33xQ4xSnOwKInzbtY7EygkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBcVlwnNIRyT8/J19VVLin8fTA9hVxFh8/Vm+JEvp2vPP8 lUl7OK8pZUvVe90XKTq6T+jjNPYCPR7faq1sN58Axe+MqfNFD9eGaQbZcEoIG33adn3+GTt7 I/+9fKH8yjvT563akZT2tPqknwAT+/PJp/6HHNOSYLlx4Mf+nX3vWuNP967c2xW8RYmlOCPR UIu5qDgRAJ/lx5d7AgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 09:51:28 -0000 --_000_39B5E4D390E9BD4890E2B310790061010F7801ESESSMB301ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See comments inline. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer > > draft-ietf-ecrit-data-only-ea-05 states: > > > > > > This document does not define a mechanism for updates to the data > > contained in data-only emergency calls. > > > > > > Is there another I-D describing how to provide the updates of the data = to the PSAP? I saw some post suggesting that a SUBSCRIBE/NOTIFY mechanism c= ould be used where the PSAP is subscriber and the UA is notifier, however I= have not found such draft. > > > > Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the subscri= ber and the UA is the notifier, this would require reachability of UA for i= nitial request for dialog (i.e. SUBSCRIBE). However, when the UA is not reg= istered e.g. due to missing credentials, the UA is normally not reachable f= or SIP requests other than those sent within the dialog of the emergency ca= ll. > > I think the combination of missing credentials, and data updates is so un= likely that the problem of PSAP control of updates dwarfs it. Why do you believe it is unlikely? If PSAP accepts unauthenticated one short emergency requests, the PSAP will= likely be interested in any data updates which the UA is able to provide. = E.g. fire detection sensor could provide updates of the temperature in the = building. > I think that in many cases where the DEVICE as a opposed to a service su= pplies updates, it will employ a server somewhere and publish its updates t= o the server, which can allow PSAP subscriptions. That's primarily because= the device doesn't want or need much mechanism. I probably should mention= that idea in the draft. Lost on what this means. I thought we are discussing UA providing data only= emergency request to PSAP. > > Issue 2: How to send the update of the data __triggered by the UA__? Do= we assume that if the PSAP subscription is not available, the PSAP prevent= s the UE from sending further information? > > If so, assuming PSAP is interested in any information avail= able, PSAP will need to subscribe in every single case of MESSAGE with CAP = where UA can potentially provide the update of the data. > > If not, do we assume that the UE would send updates of data= triggered by UE using other mechanism (MESSAGE?) than updates of data requ= ested by PSAP (NOTIFY)? > The source is the server (unless a device uses another server, see above)= . Updates will always be triggered by the source. The destination (PSAP) = can ask for filtering, but updates would not be sent unless the source want= ed to send one. > The mechanism the draft I created included an explicit mechanism to tell = the PSAP that updates may be available. If the source won't update, then i= t would not send the URI for subscriptions. The PSAP can then decide if it= wants to subscribe. It would have, at most, as many subscriptions as it c= an handle calls (one per call taker). So, if updates are possible, PSAP would be required to subscribe whenever U= A is able to provide the updates (even if the UA will not provide any updat= es at the end). Right? UA ----> MESSAGE ---> PSAP UA <---- 2xx for MESSAGE <--- PSAP if PSAP is interested in updates (very likely): UA <---- SUBSCRIBE <--- PSAP UA ----> 2xx for SUBSCRIBE ---> PSAP UA ----> NOTIFY (initial) ---> PSAP UA <---- 2xx for NOTIFY <--- PSAP if update is to be sent: UA ----> NOTIFY (with update) ---> PSAP UA <---- 2xx for NOTIFY <--- PSAP when subscription expires: UA ----> NOTIFY (final) ---> PSAP UA <---- 2xx for NOTIFY <--- PSAP IMO, this is suboptimal. For single shot, the MESSAGE based mechanism is OK. Whenever updates are possible, MESSAGE together with SUBSCRIBE/NOTIFY from = PSAP to UA is rather bad as it requires additional messages to set up subsc= ription which may not be used at the end for any update. So, it boils down to - do we expect the UAs will be able to provide updates= often or rarely? > > Issue 3: In some architectures (like 3GPP), signalling path for inital = request for dialog from the PSAP to the UA is different than signalling pat= h for the emergency request from the UA to the PSAP. If the UA has subscrip= tion from network in country X and roams in country Y, there is likelyhood = that information that request comes from the PSAP is lost due to missing tr= ust among PSAP (in country Y), transit networks (in country Y and X and pos= sibly other transit countries), network of registrar and proxy of the UA (i= n country X), transit networks (in country X and Y and possibly other trans= it countries) and network of edge proxy serving the UA (in country Y) . If = so, the UA would then handle the inital request for dialog as coming from a= n attacker UE and possibly reject it. > In such circumstances, you INCREASE the probability of success by request= ing the PSAP contact the device without any of the networks in the path (po= ssibly other than the home network). > > The request is coming to a URI that is contained in the outgoing message,= which is supposed to be protected the entire path with TLS (to avoid obser= vation). The attacker would have to be in the path of the call to get the = URI, unless it's guessable. This isn't very strong security, but it's some= thing. > > PSAPs have credentials, and the device or server can check them. The issue was about trust between countries and MESSAGE going via a lot mor= e networks and more countries than pure dialog of the emergency call. Thus the risk of missing trust between the networks is high - e.g. when UA = with US subscription is an african country, sends emergency request to afri= can PSAP, will the US home network of the UA trust the african network clai= ming that SUBSCRIBE comes from PSAP? > > Is draft-ietf-ecrit-data-only-ea-05 supposed to be a base for future s= olution where updates of the data to the PSAP are sent? I do not think it w= ould work due to issues above. > > > > If the UA ever wants to provide the updates of the data to the PSAP, ei= ther triggred by the UA or requested by the PSAP, it would be better to est= ablish a dialog from beginning, e.g. send the initial data in INVITE and up= dates (from UE) and requests for updates (from PSAP) in INFOs. > I don't think it is acceptable to have the device in control of the rate = of updates, which is the entire reason I suggest using SUBSCRIBE. Unless w= e recreate the entire filtering mechanism, I don't think in-band updates wo= rk. The rate of the updates could be controlled by the INFO package parameters = or by the information exchanged by the INFOs. --_000_39B5E4D390E9BD4890E2B310790061010F7801ESESSMB301ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See comments inline. Kind regards Ivo Sedlacek

 

This Communication is Confidential. We only send = and receive email on the basis of the terms set out at www.ericsson.com/ema= il_disclaimer

 

> > draft-ietf-ecrit-data-only-ea-05 states= :

> >

> >

> >    This document does no= t define a mechanism for updates to the data

> >    contained in data-onl= y emergency calls.

> >

> >

> > Is there another I-D describing how to = provide the updates of the data to the PSAP? I saw some post suggesting tha= t a SUBSCRIBE/NOTIFY mechanism could be used where the PSAP is subscriber a= nd the UA is notifier, however I have not found such draft.

> >

> > Issue 1: If SUBSCRIBE/NOTIFY mechanism = is used, the PSAP is the subscriber and the UA is the notifier, this would = require reachability of UA for initial request for dialog (i.e. SUBSCRIBE).= However, when the UA is not registered e.g. due to missing credentials, the UA is normally not reachable for SIP = requests other than those sent within the dialog of the emergency call.

> 

> I think the combination of missing credentia= ls, and data updates is so unlikely that the problem of PSAP control of upd= ates dwarfs it.

 

Why do you believe it is unlikely?

 

If PSAP accepts unauthenticated one short emergen= cy requests, the PSAP will likely be interested in any data updates which t= he UA is able to provide. E.g. fire detection sensor could provide updates = of the temperature in the building.

 

> I think that in many cases where the DEVICE = as a opposed to a  service supplies updates, it will employ a server s= omewhere and publish its updates to the server, which can allow PSAP subscr= iptions.  That's primarily because the device doesn't want or need much mechanism.  I probably should mention that = idea in the draft.

 

Lost on what this means. I thought we are discuss= ing UA providing data only emergency request to PSAP.

 

> > Issue 2: How to send the update of the = data __triggered by the UA__? Do we assume that if the PSAP subscription is= not available, the PSAP prevents the UE from sending further information?<= o:p>

> >      &nbs= p;      If so, assuming PSAP is interested in any = information available, PSAP will need to subscribe in every single case of = MESSAGE with CAP where UA can potentially provide the update of the data.

> >      &nbs= p;      If not, do we assume that the UE would sen= d updates of data triggered by UE using other mechanism (MESSAGE?) than upd= ates of data requested by PSAP (NOTIFY)?

> The source is the server (unless a device us= es another server, see above).  Updates will always be triggered by th= e source.  The destination (PSAP) can ask for filtering, but updates w= ould not be sent unless the source wanted to send one.

> The mechanism the draft I created included a= n explicit mechanism to tell the PSAP that updates may be available.  = If the source won't update, then it would not send the URI for subscription= s.  The PSAP can then decide if it wants to subscribe.  It would have, at most, as many subscriptions as it can h= andle calls (one per call taker).

 

So, if updates are possible, PSAP would be requir= ed to subscribe whenever UA is able to provide the updates (even if the UA = will not provide any updates at the end). Right?

 

UA ----> MESSAGE ---> PSAP

UA <---- 2xx for MESSAGE <--- PSAP

 

if PSAP is interested in updates (very likely):

UA <---- SUBSCRIBE <--- PSAP

UA ----> 2xx for SUBSCRIBE ---> PSAP

UA ----> NOTIFY (initial) ---> PSAP

UA <---- 2xx for NOTIFY <--- PSAP

 

if update is to be sent:

UA ----> NOTIFY (with update) ---> PSAP

UA <---- 2xx for NOTIFY <--- PSAP

 

when subscription expires:

UA ----> NOTIFY (final) ---> PSAP

UA <---- 2xx for NOTIFY <--- PSAP

 

IMO, this is suboptimal.

 

For single shot, the MESSAGE based mechanism is O= K.

Whenever updates are possible, MESSAGE together w= ith SUBSCRIBE/NOTIFY from PSAP to UA is rather bad as it requires additiona= l messages to set up subscription which may not be used at the end for any = update.

 

So, it boils down to - do we expect the UAs will = be able to provide updates often or rarely?

 

 

> > Issue 3: In some architectures (like 3G= PP), signalling path for inital request for dialog from the PSAP to the UA = is different than signalling path for the emergency request from the UA to = the PSAP. If the UA has subscription from network in country X and roams in country Y, there is likelyhood that info= rmation that request comes from the PSAP is lost due to missing trust among= PSAP (in country Y), transit networks (in country Y and X and possibly oth= er transit countries), network of registrar and proxy of the UA (in country X), transit networks (in country= X and Y and possibly other transit countries) and network of edge proxy se= rving the UA (in country Y) . If so, the UA would then handle the inital re= quest for dialog as coming from an attacker UE and possibly reject it.

> In such circumstances, you INCREASE the prob= ability of success by requesting the PSAP contact the device without any of= the networks in the path (possibly other than the home network).

>

> The request is coming to a URI that is conta= ined in the outgoing message, which is supposed to be protected the entire = path with TLS (to avoid observation).  The attacker would have to be i= n the path of the call to get the URI, unless it's guessable.  This isn't very strong security, but it's something.=

>

> PSAPs have credentials, and the device or se= rver can check them.

 

The issue was about trust between countries and M= ESSAGE going via a lot more networks and more countries than pure dialog of= the emergency call.

Thus the risk of missing trust between the networ= ks is high - e.g. when UA with US subscription is an african country, sends= emergency request to african PSAP, will the US home network of the UA trus= t the african network claiming that SUBSCRIBE comes from PSAP?

 

> > Is draft-ietf-ecrit-data-only-ea-05 sup= posed to be a  base for future solution where updates of the data to t= he PSAP are sent? I do not think it would work due to issues above.

> >

> > If the UA ever wants to provide the upd= ates of the data to the PSAP, either triggred by the UA or requested by the= PSAP, it would be better to establish a dialog from beginning, e.g. send t= he initial data in INVITE and updates (from UE) and requests for updates (from PSAP) in INFOs.

> I don't think it is acceptable to have the d= evice in control of the rate of updates, which is the entire reason I sugge= st using SUBSCRIBE.  Unless we recreate the entire filtering mechanism= , I don't think in-band updates work.

 

The rate of the updates could be controlled by th= e INFO package parameters or by the information exchanged by the INFOs.

--_000_39B5E4D390E9BD4890E2B310790061010F7801ESESSMB301ericsso_-- From br@brianrosen.net Wed Jul 17 06:36:09 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0975111E80ED for ; Wed, 17 Jul 2013 06:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.297 X-Spam-Level: X-Spam-Status: No, score=-100.297 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZcWGdgYpj1L for ; Wed, 17 Jul 2013 06:36:04 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 04B1321F9F13 for ; Wed, 17 Jul 2013 06:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=BxrbrezJckCZybVCiksobpnoJTIpnhXO8dlTYDXGSw0=; b=XWA76z4LJ4jAKRQVDLXUdhV1TrW7cJPyxDEsX35Z8etJBRjqQVmyUCpemLlNDkqSV9tPU7XliujLKWPX61UyhY7TBhYOTlOTb4J2rrV5hPy6TXsj3hqq/bVdy5kHX2rQUpS4cZBFNgqzEj40sGKcW2KC+cwbawJnUSxvViiAGFA=; Received: from neustargw.va.neustar.com ([209.173.53.233]:59156 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzRte-0007e1-SZ; Wed, 17 Jul 2013 09:35:59 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_1D9FAE1D-94CF-4E92-B7C5-8D67C5B89ED8" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <39B5E4D390E9BD4890E2B310790061010F7801@ESESSMB301.ericsson.se> Date: Wed, 17 Jul 2013 09:35:56 -0400 Message-Id: <33E90524-25FA-48E0-B639-5B21862D21D6@brianrosen.net> References: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se> <4BD09290-F3F3-45CE-BF56-1896B76EE51D@brianrosen.net> <39B5E4D390E9BD4890E2B310790061010F7801@ESESSMB301.ericsson.se> To: Ivo Sedlacek X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 13:36:09 -0000 --Apple-Mail=_1D9FAE1D-94CF-4E92-B7C5-8D67C5B89ED8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Responses inline On Jul 17, 2013, at 5:51 AM, Ivo Sedlacek = wrote: > See comments inline. Kind regards Ivo Sedlacek > =20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out atwww.ericsson.com/email_disclaimer > =20 > > > draft-ietf-ecrit-data-only-ea-05 states: > > > > > > > > > This document does not define a mechanism for updates to the = data > > > contained in data-only emergency calls. > > > > > > > > > Is there another I-D describing how to provide the updates of the = data to the PSAP? I saw some post suggesting that a SUBSCRIBE/NOTIFY = mechanism could be used where the PSAP is subscriber and the UA is = notifier, however I have not found such draft. > > > > > > Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the = subscriber and the UA is the notifier, this would require reachability = of UA for initial request for dialog (i.e. SUBSCRIBE). However, when the = UA is not registered e.g. due to missing credentials, the UA is normally = not reachable for SIP requests other than those sent within the dialog = of the emergency call. > >=20 > > I think the combination of missing credentials, and data updates is = so unlikely that the problem of PSAP control of updates dwarfs it. > =20 > Why do you believe it is unlikely? Because PSAPs will have credentials, and most sensor based devices where = it's the device making the call don't update fast enough to be = interesting. I also think in most cases, devices will publish to a = server, and the server will send the alert. > =20 > If PSAP accepts unauthenticated one short emergency requests, the PSAP = will likely be interested in any data updates which the UA is able to = provide. E.g. fire detection sensor could provide updates of the = temperature in the building. Poor example. The way we intend to determine temperatures in a building = is the "additional location data" mechanism, which would probably (no = details have been worked out yet) have a portal access to the building = control system. The usual case where it is a device that has updates is that it uses the = credentials of the PSAP to allow subscription. Since the URL is = something it supplies, it can include a token, good for a small window = around the MESSAGE it sends. =20 > =20 > > I think that in many cases where the DEVICE as a opposed to a = service supplies updates, it will employ a server somewhere and publish = its updates to the server, which can allow PSAP subscriptions. That's = primarily because the device doesn't want or need much mechanism. I = probably should mention that idea in the draft. > =20 > Lost on what this means. I thought we are discussing UA providing data = only emergency request to PSAP. Nearly every device I know about that would do this has some associated = service. The device itself doesn't do all the work, there is a service = involved. Maintaining=20 state, verifying credentials, etc requires work. Usually, the device = offloads this to a service. So the device publishes it's sensor data to = the service and the service provides the emergency message and updates. We want to ALLOW direct from the device messages, and we have a way to = do that. A way the PSAP controls, which I think is important. > =20 > > > Issue 2: How to send the update of the data __triggered by the = UA__? Do we assume that if the PSAP subscription is not available, the = PSAP prevents the UE from sending further information? > > > If so, assuming PSAP is interested in any information = available, PSAP will need to subscribe in every single case of MESSAGE = with CAP where UA can potentially provide the update of the data. > > > If not, do we assume that the UE would send updates of = data triggered by UE using other mechanism (MESSAGE?) than updates of = data requested by PSAP (NOTIFY)? > > The source is the server (unless a device uses another server, see = above). Updates will always be triggered by the source. The = destination (PSAP) can ask for filtering, but updates would not be sent = unless the source wanted to send one. > > The mechanism the draft I created included an explicit mechanism to = tell the PSAP that updates may be available. If the source won't = update, then it would not send the URI for subscriptions. The PSAP can = then decide if it wants to subscribe. It would have, at most, as many = subscriptions as it can handle calls (one per call taker). > =20 > So, if updates are possible, PSAP would be required to subscribe = whenever UA is able to provide the updates (even if the UA will not = provide any updates at the end). Right? If the UA doesn't intend to provide updates, it doesn't offer a = SUBSCRIBE URI. If one is offered, and the PSAP wants updates, it will = subscribe. > =20 > UA ----> MESSAGE ---> PSAP > UA <---- 2xx for MESSAGE <--- PSAP > =20 > if PSAP is interested in updates (very likely): > UA <---- SUBSCRIBE <--- PSAP > UA ----> 2xx for SUBSCRIBE ---> PSAP > UA ----> NOTIFY (initial) ---> PSAP > UA <---- 2xx for NOTIFY <--- PSAP > =20 > if update is to be sent: > UA ----> NOTIFY (with update) ---> PSAP > UA <---- 2xx for NOTIFY <--- PSAP > =20 > when subscription expires: > UA ----> NOTIFY (final) ---> PSAP > UA <---- 2xx for NOTIFY <--- PSAP > =20 > IMO, this is suboptimal. > =20 > For single shot, the MESSAGE based mechanism is OK. > Whenever updates are possible, MESSAGE together with SUBSCRIBE/NOTIFY = from PSAP to UA is rather bad as it requires additional messages to set = up subscription which may not be used at the end for any update. > =20 > So, it boils down to - do we expect the UAs will be able to provide = updates often or rarely? You seem to think there is a substantially simpler way. There isn't. For one thing devices that do this tend to move. MESSAGE does not = create a session. Sending updates requires a session where the routing = wouldn't change within the session. You can't send individual MESSAGE = transactions, because each one may route differently. That means we = would need for the initial alert to be in an INVITE, create a session = with no media, then send INFOs. Not a whole lot different. > =20 > =20 > > > Issue 3: In some architectures (like 3GPP), signalling path for = inital request for dialog from the PSAP to the UA is different than = signalling path for the emergency request from the UA to the PSAP. If = the UA has subscription from network in country X and roams in country = Y, there is likelyhood that information that request comes from the PSAP = is lost due to missing trust among PSAP (in country Y), transit networks = (in country Y and X and possibly other transit countries), network of = registrar and proxy of the UA (in country X), transit networks (in = country X and Y and possibly other transit countries) and network of = edge proxy serving the UA (in country Y) . If so, the UA would then = handle the inital request for dialog as coming from an attacker UE and = possibly reject it. > > In such circumstances, you INCREASE the probability of success by = requesting the PSAP contact the device without any of the networks in = the path (possibly other than the home network). > > > > The request is coming to a URI that is contained in the outgoing = message, which is supposed to be protected the entire path with TLS (to = avoid observation). The attacker would have to be in the path of the = call to get the URI, unless it's guessable. This isn't very strong = security, but it's something. > > > > PSAPs have credentials, and the device or server can check them. > =20 > The issue was about trust between countries and MESSAGE going via a = lot more networks and more countries than pure dialog of the emergency = call. > Thus the risk of missing trust between the networks is high - e.g. = when UA with US subscription is an african country, sends emergency = request to african PSAP, will the US home network of the UA trust the = african network claiming that SUBSCRIBE comes from PSAP? No network is involved. The question you are asking is will a US device = visiting Africa trust an African PSAP. When the MESSAGE is sent the URI = for the subscribe is that of the device, not the home or visited network = of the device. > =20 > > > Is draft-ietf-ecrit-data-only-ea-05 supposed to be a base for = future solution where updates of the data to the PSAP are sent? I do not = think it would work due to issues above. > > > > > > If the UA ever wants to provide the updates of the data to the = PSAP, either triggred by the UA or requested by the PSAP, it would be = better to establish a dialog from beginning, e.g. send the initial data = in INVITE and updates (from UE) and requests for updates (from PSAP) in = INFOs. > > I don't think it is acceptable to have the device in control of the = rate of updates, which is the entire reason I suggest using SUBSCRIBE. = Unless we recreate the entire filtering mechanism, I don't think in-band = updates work. > =20 > The rate of the updates could be controlled by the INFO package = parameters or by the information exchanged by the INFOs. So you propose to recreate RFC6446 and 6447 in an INFO package? --Apple-Mail=_1D9FAE1D-94CF-4E92-B7C5-8D67C5B89ED8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Responses = inline
On Jul 17, 2013, at 5:51 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com>= ; wrote:

See comments inline. Kind regards Ivo = Sedlacek
This Communication = is Confidential. We only send and receive email on the basis of the = terms set out at 
Because = PSAPs will have credentials, and most sensor based devices where it's = the device making the call don't update fast enough to be interesting. =  I also think in most cases, devices will publish to a server, and = the server will send the alert.


If PSAP accepts = unauthenticated one short emergency requests, the PSAP will likely be = interested in any data updates which the UA is able to provide. E.g. = fire detection sensor could provide updates of the temperature in the = building.
Poor example.  The way we = intend to determine temperatures in a building is the "additional = location data" mechanism, which would probably (no details have been = worked out yet) have a portal access to the building control = system.

The usual case where it is a device = that has updates is that it uses the credentials of the PSAP to allow = subscription.  Since the URL is something it supplies, it can = include a token, good for a small window around the MESSAGE it sends. =  
 
> I think that in many cases where the DEVICE = as a opposed to a  service supplies updates, it will employ a = server somewhere and publish its updates to the server, which can allow = PSAP subscriptions.  That's primarily because the device doesn't = want or need much mechanism.  I probably should mention that idea = in the draft.
Lost on what this = means. I thought we are discussing UA providing data only emergency = request to PSAP.
Nearly every device I = know about that would do this has some associated service.  The = device itself doesn't do all the work, there is a service involved. =  Maintaining 
state, verifying credentials, etc = requires work.  Usually, the device offloads this to a service. =  So the device publishes it's sensor data to the service and the = service provides the emergency message and = updates.

We want to ALLOW direct from the = device messages, and we have a way to do that.  A way the PSAP = controls, which I think is important.

> > Issue 2: = How to send the update of the data __triggered by the UA__? Do we assume = that if the PSAP subscription is not available, the PSAP prevents the UE = from sending further information?
> = >           &nbs= p; If not, do we assume that the UE would send updates of data triggered = by UE using other mechanism (MESSAGE?) than updates of data requested by = PSAP (NOTIFY)?
> The source is = the server (unless a device uses another server, see above).  = Updates will always be triggered by the source.  The destination = (PSAP) can ask for filtering, but updates would not be sent unless the = source wanted to send one.
> The = mechanism the draft I created included an explicit mechanism to tell the = PSAP that updates may be available.  If the source won't update, = then it would not send the URI for subscriptions.  The PSAP can = then decide if it wants to subscribe.  It would have, at most, as = many subscriptions as it can handle calls (one per call = taker).
So, if updates are = possible, PSAP would be required to subscribe whenever UA is able to = provide the updates (even if the UA will not provide any updates at the = end). Right?
If the UA doesn't intend to = provide updates, it doesn't offer a SUBSCRIBE URI.  If one is = offered, and the PSAP wants updates, it will = subscribe.

UA ----> MESSAGE = ---> PSAP
UA <---- 2xx for = MESSAGE <--- PSAP
if PSAP is = interested in updates (very likely):
UA ----> NOTIFY (initial) ---> = PSAP
UA <---- 2xx for NOTIFY = <--- PSAP
if update is to be = sent:
UA ----> NOTIFY (with = update) ---> PSAP
UA = <---- 2xx for NOTIFY <--- PSAP
when subscription = expires:
UA ----> NOTIFY = (final) ---> PSAP
UA = <---- 2xx for NOTIFY <--- PSAP
IMO, this is = suboptimal.
For single shot, = the MESSAGE based mechanism is OK.
So, it boils down = to - do we expect the UAs will be able to provide updates often or = rarely?
You seem to think there is a = substantially simpler way.  There = isn't.

For one thing devices that do this tend = to move.  MESSAGE does not create a session.  Sending updates = requires a session where the routing wouldn't change within the session. =  You can't send individual MESSAGE transactions, because each one = may route differently.  That means we would need for the initial = alert to be in an INVITE, create a session with no media, then send = INFOs.  Not a whole lot different.
> > Issue 3: = In some architectures (like 3GPP), signalling path for inital request = for dialog from the PSAP to the UA is different than signalling path for = the emergency request from the UA to the PSAP. If the UA has = subscription from network in country X and roams in country Y, there is = likelyhood that information that request comes from the PSAP is lost due = to missing trust among PSAP (in country Y), transit networks (in country = Y and X and possibly other transit countries), network of registrar and = proxy of the UA (in country X), transit networks (in country X and Y and = possibly other transit countries) and network of edge proxy serving the = UA (in country Y) . If so, the UA would then handle the inital request = for dialog as coming from an attacker UE and possibly reject = it.
> In such circumstances, = you INCREASE the probability of success by requesting the PSAP contact = the device without any of the networks in the path (possibly other than = the home network).
> The request is = coming to a URI that is contained in the outgoing message, which is = supposed to be protected the entire path with TLS (to avoid = observation).  The attacker would have to be in the path of the = call to get the URI, unless it's guessable.  This isn't very strong = security, but it's something.
> PSAPs have = credentials, and the device or server can check = them.
 
The issue was about trust between countries and = MESSAGE going via a lot more networks and more countries than pure = dialog of the emergency call.
Thus = the risk of missing trust between the networks is high - e.g. when UA = with US subscription is an african country, sends emergency request to = african PSAP, will the US home network of the UA trust the african = network claiming that SUBSCRIBE comes from = PSAP?
No network is involved.  The = question you are asking is will a US device visiting Africa trust an = African PSAP.  When the MESSAGE is sent the URI for the subscribe = is that of the device, not the home or visited network of the = device.

> > Is = draft-ietf-ecrit-data-only-ea-05 supposed to be a  base for future = solution where updates of the data to the PSAP are sent? I do not think = it would work due to issues above.
> > If the UA = ever wants to provide the updates of the data to the PSAP, either = triggred by the UA or requested by the PSAP, it would be better to = establish a dialog from beginning, e.g. send the initial data in INVITE = and updates (from UE) and requests for updates (from PSAP) in = INFOs.
> I don't think = it is acceptable to have the device in control of the rate of updates, = which is the entire reason I suggest using SUBSCRIBE.  Unless we = recreate the entire filtering mechanism, I don't think in-band updates = work.
 
The rate of the updates could be controlled by = the INFO package parameters or by the information exchanged by the = INFOs.
So you propose to = recreate RFC6446 and 6447 in an INFO = package?


= --Apple-Mail=_1D9FAE1D-94CF-4E92-B7C5-8D67C5B89ED8-- From br@brianrosen.net Wed Jul 17 06:52:11 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ED721F9FE4 for ; Wed, 17 Jul 2013 06:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.302 X-Spam-Level: X-Spam-Status: No, score=-100.302 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNPJLcmHlECE for ; Wed, 17 Jul 2013 06:52:07 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id E923B21F9F85 for ; Wed, 17 Jul 2013 06:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=uTXyDjoRjHaWx32lwqPZLtRN3c5lwYw/bx1R3bgogAQ=; b=gDPwqZVzuzZp7VH6OCpVHGhhc3WaOeilzckKxYoGLW2vgH7BccxukJyx9lw1v/GmLkQuEl6HtK4zVeuFxcgeUwsq3Q6iUUw1bpUpSNpdk6tOwvwzRT/eLXOSLMXjCcFx/QI4qZWTDLF1DvXV4LjgDuU2l0tyRywfBpZwdVFDvls=; Received: from neustargw.va.neustar.com ([209.173.53.233]:45585 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzS9F-0002u9-0l; Wed, 17 Jul 2013 09:52:05 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B06A883@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Wed, 17 Jul 2013 09:52:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0B990A8B-48DA-41B4-987C-E11537DD168F@brianrosen.net> References: <048408CB-5414-4548-8592-661CC4AD3DC8@gmx.net> <98E5F4A5-9363-4878-A24A-AF3C9E55B3E1@brianrosen.net> <949EF20990823C4C85C18D59AA11AD8B06A883@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 13:52:12 -0000 Looking at the registry, there are only two parameters that have more = than 3 values, purpose and "handling" parameter of Content-Disposition. = When we're finished, we're going to have six in purpose, and NENA wants = to register two more. I think that justifies a separate sub registry, I = don't think it would affect other parameters, and I think this parameter = ought to have a more lax registration mechanism than IETF consensus. I'll fix the other things you noted. Brian On Jul 16, 2013, at 6:19 AM, "DRAGE, Keith (Keith)" = wrote: > The relevant document that defines the policy here is RFC 3968: >=20 > Some SIP header field parameters only accept a set of predefined > parameter values. For example, a parameter indicating the transport > protocol in use may only accept the predefined tokens TCP, UDP, and > SCTP as valid values. Registering all parameter values for all SIP > header field parameters of this type would require a large number of > subregistries. Instead, we have chosen to register parameter values > by reference. That is, the entry in the parameter registry for a > given header field parameter contains references to the RFCs = defining > new values of the parameter. References to RFCs defining parameter > values appear in double brackets in the registry. >=20 > So, the header field parameter registry contains a column that > indicates whether or not each parameter only accepts a set of > predefined values. Implementers of parameters with a "yes" in that > column need to find all the valid parameter values in the RFCs > provided as references. >=20 > So given an explicit approved statement I think you should come up = with better arguments for a separate registry, rather than "I think we = should fix this". I'm not saying you may not be able to justify it, = rather that if we follow your policy without control we will be adding = dozens of extra tables to the registries, and noone will be able to find = anything. >=20 > Whatever the WG decides, you still need to amend the header field = parameters table and this document currently does not fulfil that = function. >=20 > Additional comments I spotted while looking at this: >=20 > I'd note that it is the=20 >=20 > "purpose" header field parameter [of the Call Info header field] >=20 > Rather than the >=20 > 'purpose' parameter. >=20 > And on 9.1.1: >=20 > " As defined in [RFC5226], this registry operates > under "Expert Review" rules." >=20 > RFC 5226 does not define how this registry operates. What you want to = say is that the expert review rules are defined in RFC 5226. >=20 >=20 >=20 > Keith >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of >> Brian Rosen >> Sent: 15 July 2013 20:14 >> To: Hannes Tschofenig >> Cc: ecrit@ietf.org WG >> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10 >>=20 >> Commenting on a draft of which I am an author :) >>=20 >> The IANA considerations, in section 9.1.7. Additional Data Blocks >> Registry >> says: >>=20 >> This document creates a new sub-registry called 'Additional Data >> Blocks' in the purpose registry established by RFC 3261 [RFC3261]. >>=20 >> Unfortunately, there is no "purpose" registry. There is only a list = of >> references in the Header parameters table that refer to RFCs that = define >> new purpose values. >> I think we should fix this and have "Additional Data" create the = purpose >> registry, adding one new value and the sub registry. >>=20 >> Brian >>=20 >> On Jul 15, 2013, at 1:43 PM, Hannes Tschofenig = >> wrote: >>=20 >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>>=20 >>> Hi all, >>>=20 >>> I have just uploaded a new version of the additional data draft. >>>=20 >>> The following changes have been made: >>> * Editorial changes throughout the document to improve readability >>> * James joined us as a co-author for his contributions to the = document >>> * Section about the Content-Disposition Parameter added (as = discussed >> on the list) >>> * Updated examples >>> * Included an additional example illustrating the provided-by = element >>> * Fixed provided by schema. This caused changes to other schemas as >> well >>> * Re-wrote the privacy consideration section >>>=20 >>> Here is the document: >>> http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-10 >>>=20 >>> The diff can be found here: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-10= >>>=20 >>> Ciao >>> Hannes >>>=20 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >>> Comment: GPGTools - http://gpgtools.org >>>=20 >>> iQEcBAEBCgAGBQJR5DTXAAoJEGhJURNOOiAtT9MH/jnxPS0xShhw/OoYJP3HbWn2 >>> gZTpxcEgW/iaR8nqgH7nydruzihDZhWB+rhy744JzKQuQGMFY1tbqwoBtsjcN8eZ >>> KihFwXxGYYYpLT3KOG0MNVim/kEFW+yURBAo2nhivF51t5rqJM76VRTUXjk94dgy >>> dFysUhx041OT6NsGuxGIcsW5X1snFgHhvims+P7NJt93cqmaPOoYHYkparcJEsqw >>> w4RcUUHWRGPUJ4e0wt45CdmYgz9CpR8wJcYHQbxhjB/K7ZlQXhJ1bNQ4njWep2F7 >>> 4omKn7osh8JqcxPYb21gAmdo0oLglrNwW++Z8g3DIhRXp6pH8NGDiiWt0XF2ri8=3D >>> =3DTxce >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> 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 ivo.sedlacek@ericsson.com Wed Jul 17 08:14:05 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503CC11E80E6 for ; Wed, 17 Jul 2013 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oERDnyEHnLX8 for ; Wed, 17 Jul 2013 08:13:59 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 539D711E80D3 for ; Wed, 17 Jul 2013 08:13:59 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-d0-51e6b4b667d5 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 59.24.11907.6B4B6E15; Wed, 17 Jul 2013 17:13:58 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.30]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Wed, 17 Jul 2013 17:13:57 +0200 From: Ivo Sedlacek To: Brian Rosen Thread-Topic: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 Thread-Index: AQHOgvKVoY2w/1c/UkKTlMBs+yWgpJlo5GVw Date: Wed, 17 Jul 2013 15:13:57 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010F7A2B@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se> <4BD09290-F3F3-45CE-BF56-1896B76EE51D@brianrosen.net> <39B5E4D390E9BD4890E2B310790061010F7801@ESESSMB301.ericsson.se> <33E90524-25FA-48E0-B639-5B21862D21D6@brianrosen.net> In-Reply-To: <33E90524-25FA-48E0-B639-5B21862D21D6@brianrosen.net> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM+Jvre62Lc8CDebdFbR4en8am0Xjoqes Dkwe97/9ZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG1L0nWAr+GlasWjCTpYHxv3oXIyeHhICJ xMHbm1ggbDGJC/fWs3UxcnEICRxllNg+5x8zhLOYUeL9z3mMIFVsAnoSE7ccYQWxRQSUJXbe 6mQHsZkFVCXONT4GmyQs4Cjx/PRhNogaJ4l5164AxTmAbCOJuw+rQMIsQOVftjWDlfMKeEvM aGxhgdi1n0miYeoVJpAEJ1Dv9Cf3wPYyCshKXP3TywixS1zi1pP5TBBXC0gs2XOeGcIWlXj5 +B8rhK0osfNsOzNEvZ7EjalT2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywkLQsY WVYxchSnFiflphsZbGIExsnBLb8tdjBe/mtziFGag0VJnHeL3plAIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYzTvfy0Li8z9RF+MMtjl/5Kac0dpU+Mby5OutEyiXFmY0j3xkXP1xRkLw2L +fTn4XXh66d+GK29GJa/8U7h95VWE6Z9qHodkLLzo43/ndzp/zOmGeo+WjUj50R4O5uZ9KlV C2f+Fw1k/WanvivjKnM4wwKTMj931aSyf6Iqt49rG0+LYWz1qXVXYinOSDTUYi4qTgQAcYkR BWECAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:14:05 -0000 please see below. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 =A0 > > > > Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the sub= scriber and the UA is the notifier, this would require reachability of UA f= or initial request for dialog (i.e. SUBSCRIBE). However, when the UA is not= registered e.g. due to missing credentials, the UA is normally not reachab= le for SIP requests other than those sent within the dialog of the emergenc= y call. > > >=A0 > > > I think the combination of missing credentials, and data updates is s= o unlikely that the problem of PSAP control of updates dwarfs it. The issue above was related to UA not being reachable for incoming requests= due to __UA__ not having its credentials.=20 Networks (like 3GPP IMS) enable UA without valid credentials to only send e= mergency requests and requests sent within dialogs created by emergency req= uest.=20 To receive requests sent outside of dialog created by emergency requests, t= he UA needs to be registered. To be registered, the UA needs to have valid credentials. Note that some countries require UAs to be able to make voice emergency cal= l even if the UA does not valid credentials.=20 Why should that be not be required as well for data only emergency requests= ? > Because PSAPs will have credentials, and most sensor based devices where = it's the device making the call don't update fast enough to be interesting.= =A0I also think in most cases, devices will publish to a server, and the s= erver will send the alert. The above describes some particular architecture where SIP and non SIP sig= nalling is mixed, or perhaps server acts as SIP B2BUA, not sure. Which enti= ty is the SIP UA - the "server" or the "device" or both? Why would the UA not be able to provide updates fast enough? Even if the UA= s are not able to do it today, why shouldn't they be able to do it in futur= e? =A0 > > If PSAP accepts unauthenticated one short emergency requests, the PSAP = will likely be interested in any data updates which the UA is able to provi= de. E.g. fire detection sensor could provide updates of the temperature in = the building. > Poor example. =A0The way we intend to determine temperatures in a buildin= g is the "additional location data" mechanism, which would probably (no det= ails have been worked out yet) have a portal access to the building control= system. Abstract of draft-ietf-ecrit-data-only-ea-06 states:=20 Examples of such environments include a __temperature sensors issuing alerts__, or vehicles sending crash data. Is the Abstract is wrong? > The usual case where it is a device that has updates is that it uses the = credentials of the PSAP to allow subscription. =A0Since the URL is somethin= g it supplies, it can include a token, good for a small window around the M= ESSAGE it sends. =A0 The UA normally do not know the identity of the PSAP and cannot authenticat= e PSAP. This was discussed quite a lot in draft-ietf-ecrit-psap-callback. T= he result is that just indication is provided and UA needs to rely on netwo= rk to assert it.=20 > We want to ALLOW direct from the device messages, and we have a way to d= o that. =A0A way the PSAP controls, which I think is important. I understand the PSAP control is wished. This could be provided in INFO pac= kage mechanism as well. =A0 > If the UA doesn't intend to provide updates, it doesn't offer a SUBSCRIBE= URI. =A0If one is offered, and the PSAP wants updates, it will subscribe. The point is that UA may be able and may want to allow PSAP to request the = updates in every single request.=20 Similarly, PSAP may want to decide that it wants the updates for every sing= le request.=20 If this is the most common case, the MESSAGE + SUBSCRIBE/NOTIFY is suboptim= al. =A0 > For one thing devices that do this tend to move. =A0MESSAGE does not crea= te a session. =A0Sending updates requires a session where the routing would= n't change within the session. =A0You can't send individual MESSAGE transac= tions, because each one may route differently. =A0That means we would need = for the initial alert to be in an INVITE, create a session with no media, t= hen send INFOs. =A0Not a whole lot different. Updates sent using subscription will require dialog as well so there is rea= lly no difference related to UE movement. IMO, the solution using INVITE (containing the 1st shot) followed by INFOs = would be simpler and (in comparision to MESSAGE+SUBSCRIBE/NOTIFY solution): 1) would enable updates sent by UA without credentials 2) would not need to rely on trust between networks to preserve information= that SUBSCRIBE is sent by PSAP. =A0 =A0 > > Thus the risk of missing trust between the networks is high - e.g. when= UA with US subscription is an african country, sends emergency request to = african PSAP, will the US home network of the UA trust the african network = claiming that SUBSCRIBE comes from PSAP? > No network is involved. =A0The question you are asking is will a US devic= e visiting Africa trust an African PSAP. =A0When the MESSAGE is sent the UR= I for the subscribe is that of the device, not the home or visited network = of the device. 1) In normal SIP environment (like 3GPP IMS), PSAP will need to involve som= e network to reach UA. If UA includes IP address and port in the URI includ= ed in the MESSAGE, and PSAP sends SUBSCRIBE directly to that IP address and= port, the SUBSCRIBE will likely be blocked by a firewall/SBC. 2) US device trusts that the emergency message/call is delivered to african= PSAP since the UA set the Request-URI to the emergency URN. But when SUBSC= RIBE is received, how does the UA know that that SUBSCRIBE was really sent = by PSAP and not by malicious UE? Normally, the UA trusts its home network t= o assert this, and its home network trusts the transit networks, and the tr= ansit networks checks that message comes from PSAP. So, there is chain of t= rust which is however difficult to achive if several countries are involved= . =A0 > So you propose to recreate RFC6446 and 6447 in an INFO package? Not sure if all of that is needed, but possibly.=20 From pkyzivat@alum.mit.edu Wed Jul 17 09:57:41 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C232021F99C0 for ; Wed, 17 Jul 2013 09:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.228 X-Spam-Level: X-Spam-Status: No, score=-0.228 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d17pSK5UAaWi for ; Wed, 17 Jul 2013 09:57:37 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 1A33221F8206 for ; Wed, 17 Jul 2013 09:57:34 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta08.westchester.pa.mail.comcast.net with comcast id 1Nmp1m0021ap0As58UxaLt; Wed, 17 Jul 2013 16:57:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id 1Uxa1m00K3ZTu2S3iUxa6Z; Wed, 17 Jul 2013 16:57:34 +0000 Message-ID: <51E6CCFD.1020707@alum.mit.edu> Date: Wed, 17 Jul 2013 12:57:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ecrit@ietf.org References: <048408CB-5414-4548-8592-661CC4AD3DC8@gmx.net> <98E5F4A5-9363-4878-A24A-AF3C9E55B3E1@brianrosen.net> <949EF20990823C4C85C18D59AA11AD8B06A883@FR712WXCHMBA11.zeu.alcatel-lucent.com> <0B990A8B-48DA-41B4-987C-E11537DD168F@brianrosen.net> In-Reply-To: <0B990A8B-48DA-41B4-987C-E11537DD168F@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1374080254; bh=QtC8EXxKYx1x71y5XkbXvWlyGJgefiG7OE7ctX5p4y0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ftyuheymf2vOVGs+zJOxQeoe6zGBmLMmBmdgKuu3F5i/XeZWXr8OYKKsA7ailBdKk bhMBo0jBvq7hFf5gD76zd8lQG/0dPq2HCtlScN6TT0wHWRuWqWFD2HAIMbb/NQOo/Y DW1hWCDkzyH2EjvtYMcPRxMpBY5EqN7WuEJQNtUA7jmV9TDkz13ZMZ7NADYRCL3IB9 io9UDiBTwGvHock1KGrUcbYEbpMyNebWW4yaLTu8xunDaKrMu6YW8dYustXQ/qw+Xq Ww7RIVJICZPxEavH4eRplSfzjY53ByE1A+EjBzqd5LFKFWRemKXnV709jZ7Sv9uT4M Yc2q9Fovw2Zxw== Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:57:41 -0000 Clearly this is a sipcore issue. I have to think more about it before I take a position. Thanks, Paul On 7/17/13 9:52 AM, Brian Rosen wrote: > Looking at the registry, there are only two parameters that have more than 3 values, purpose and "handling" parameter of Content-Disposition. When we're finished, we're going to have six in purpose, and NENA wants to register two more. I think that justifies a separate sub registry, I don't think it would affect other parameters, and I think this parameter ought to have a more lax registration mechanism than IETF consensus. > > I'll fix the other things you noted. > > Brian > > On Jul 16, 2013, at 6:19 AM, "DRAGE, Keith (Keith)" wrote: > >> The relevant document that defines the policy here is RFC 3968: >> >> Some SIP header field parameters only accept a set of predefined >> parameter values. For example, a parameter indicating the transport >> protocol in use may only accept the predefined tokens TCP, UDP, and >> SCTP as valid values. Registering all parameter values for all SIP >> header field parameters of this type would require a large number of >> subregistries. Instead, we have chosen to register parameter values >> by reference. That is, the entry in the parameter registry for a >> given header field parameter contains references to the RFCs defining >> new values of the parameter. References to RFCs defining parameter >> values appear in double brackets in the registry. >> >> So, the header field parameter registry contains a column that >> indicates whether or not each parameter only accepts a set of >> predefined values. Implementers of parameters with a "yes" in that >> column need to find all the valid parameter values in the RFCs >> provided as references. >> >> So given an explicit approved statement I think you should come up with better arguments for a separate registry, rather than "I think we should fix this". I'm not saying you may not be able to justify it, rather that if we follow your policy without control we will be adding dozens of extra tables to the registries, and noone will be able to find anything. >> >> Whatever the WG decides, you still need to amend the header field parameters table and this document currently does not fulfil that function. >> >> Additional comments I spotted while looking at this: >> >> I'd note that it is the >> >> "purpose" header field parameter [of the Call Info header field] >> >> Rather than the >> >> 'purpose' parameter. >> >> And on 9.1.1: >> >> " As defined in [RFC5226], this registry operates >> under "Expert Review" rules." >> >> RFC 5226 does not define how this registry operates. What you want to say is that the expert review rules are defined in RFC 5226. >> >> >> >> Keith >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>> Brian Rosen >>> Sent: 15 July 2013 20:14 >>> To: Hannes Tschofenig >>> Cc: ecrit@ietf.org WG >>> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10 >>> >>> Commenting on a draft of which I am an author :) >>> >>> The IANA considerations, in section 9.1.7. Additional Data Blocks >>> Registry >>> says: >>> >>> This document creates a new sub-registry called 'Additional Data >>> Blocks' in the purpose registry established by RFC 3261 [RFC3261]. >>> >>> Unfortunately, there is no "purpose" registry. There is only a list of >>> references in the Header parameters table that refer to RFCs that define >>> new purpose values. >>> I think we should fix this and have "Additional Data" create the purpose >>> registry, adding one new value and the sub registry. >>> >>> Brian >>> >>> On Jul 15, 2013, at 1:43 PM, Hannes Tschofenig >>> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA512 >>>> >>>> Hi all, >>>> >>>> I have just uploaded a new version of the additional data draft. >>>> >>>> The following changes have been made: >>>> * Editorial changes throughout the document to improve readability >>>> * James joined us as a co-author for his contributions to the document >>>> * Section about the Content-Disposition Parameter added (as discussed >>> on the list) >>>> * Updated examples >>>> * Included an additional example illustrating the provided-by element >>>> * Fixed provided by schema. This caused changes to other schemas as >>> well >>>> * Re-wrote the privacy consideration section >>>> >>>> Here is the document: >>>> http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-10 >>>> >>>> The diff can be found here: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-10 >>>> >>>> Ciao >>>> Hannes >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >>>> Comment: GPGTools - http://gpgtools.org >>>> >>>> iQEcBAEBCgAGBQJR5DTXAAoJEGhJURNOOiAtT9MH/jnxPS0xShhw/OoYJP3HbWn2 >>>> gZTpxcEgW/iaR8nqgH7nydruzihDZhWB+rhy744JzKQuQGMFY1tbqwoBtsjcN8eZ >>>> KihFwXxGYYYpLT3KOG0MNVim/kEFW+yURBAo2nhivF51t5rqJM76VRTUXjk94dgy >>>> dFysUhx041OT6NsGuxGIcsW5X1snFgHhvims+P7NJt93cqmaPOoYHYkparcJEsqw >>>> w4RcUUHWRGPUJ4e0wt45CdmYgz9CpR8wJcYHQbxhjB/K7ZlQXhJ1bNQ4njWep2F7 >>>> 4omKn7osh8JqcxPYb21gAmdo0oLglrNwW++Z8g3DIhRXp6pH8NGDiiWt0XF2ri8= >>>> =Txce >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Wed Jul 17 11:21:00 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF7421F9EEC for ; Wed, 17 Jul 2013 11:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.313 X-Spam-Level: X-Spam-Status: No, score=-100.313 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2UFBT4LTggD for ; Wed, 17 Jul 2013 11:20:56 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id D8BFB21F9D9A for ; Wed, 17 Jul 2013 11:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=JOx1R5ozpxah34h0sLyJD+STTJTc2wqhPmqIcR2cU7I=; b=bStc9f/PaQQCL8gV+EUtGKImeVGkdZuHQLSvc14JXLZjmNeEslgu8bfdwD8MxIhzqONVsNrLpsVBn3/5khVyKQArIo16Uc6zF9t3lhGqKmg8XaxWl3JYBvLcvXADzvjZ4K0DwksphNZRrSjk6kmLB1z45TtKY8OzCwV+vSjqJeE=; Received: from neustargw.va.neustar.com ([209.173.53.233]:46981 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UzWLJ-0005y4-Uy; Wed, 17 Jul 2013 14:20:50 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <39B5E4D390E9BD4890E2B310790061010F7A2B@ESESSMB301.ericsson.se> Date: Wed, 17 Jul 2013 14:20:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6B23A1AC-E25C-4DA8-B83F-D3512BF0DAAC@brianrosen.net> References: <39B5E4D390E9BD4890E2B310790061010EF4FC@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061010F63EB@ESESSMB301.ericsson.se> <4BD09290-F3F3-45CE-BF56-1896B76EE51D@brianrosen.net> <39B5E4D390E9BD4890E2B310790061010F7801@ESESSMB301.ericsson.se> <33E90524-25FA-48E0-B639-5B21862D21D6@brianrosen.net> <39B5E4D390E9BD4890E2B310790061010F7A2B@ESESSMB301.ericsson.se> To: Ivo Sedlacek X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:21:00 -0000 Hi Ivo See inline. On Jul 17, 2013, at 11:13 AM, Ivo Sedlacek = wrote: > please see below. Kind regards Ivo Sedlacek >=20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer=20 > =20 >>>>> Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the = subscriber and the UA is the notifier, this would require reachability = of UA for initial request for dialog (i.e. SUBSCRIBE). However, when the = UA is not registered e.g. due to missing credentials, the UA is normally = not reachable for SIP requests other than those sent within the dialog = of the emergency call. >>>> =20 >>>> I think the combination of missing credentials, and data updates is = so unlikely that the problem of PSAP control of updates dwarfs it. >=20 > The issue above was related to UA not being reachable for incoming = requests due to __UA__ not having its credentials.=20 >=20 > Networks (like 3GPP IMS) enable UA without valid credentials to only = send emergency requests and requests sent within dialogs created by = emergency request.=20 > To receive requests sent outside of dialog created by emergency = requests, the UA needs to be registered. > To be registered, the UA needs to have valid credentials. I misunderstood >=20 > Note that some countries require UAs to be able to make voice = emergency call even if the UA does not valid credentials.=20 Yeah, but none of them require devices to be able to send data updates = if they are not registered. >=20 > Why should that be not be required as well for data only emergency = requests? Personal opinion - because it's a DDoS attack opening towards a PSAP. I = would prohibit it. All the PSAPs I am in discussion with are afraid of = such problems. As an example, in the U.S., in most cases, alarm = systems are not permitted to connect directly to a PSAP - they must = connect through a "Central Alarm Monitoring" service. We hope to change = that, but only if we can guarantee that the PSAP is protected, and they = believe they are protected. >=20 >> Because PSAPs will have credentials, and most sensor based devices = where it's the device making the call don't update fast enough to be = interesting. I also think in most cases, devices will publish to a = server, and the server will send the alert. >=20 > The above describes some particular architecture where SIP and non SIP = signalling is mixed, or perhaps server acts as SIP B2BUA, not sure. = Which entity is the SIP UA - the "server" or the "device" or both? The above assumes the device is registered to a service that aids it. = Most devices that have this kind of capability do that, but not all. If there is a service, the service has a server, the UA publishes = updates to the server, the PSAP subscribes to the server. If there is no service, the device UA is the server, and the PSAP = subscribes to it. >=20 > Why would the UA not be able to provide updates fast enough? Even if = the UAs are not able to do it today, why shouldn't they be able to do it = in future? Not a matter of able to, it's just that the data on such devices doesn't = change enough over the course of a call to be interesting. Once a car = crashes, it has crash data, but it doesn't change. If a fire starts, = the fire could go out on it's own, but usually the fire brigade goes out = anyway - updates aren't interesting. Same with burglar alarms. It's only a device like a heart monitor that would have updates that = would be interesting, but in my experience, such devices have services = that interpret the raw data from the sensor into more useful data for = responders. > =20 >>> If PSAP accepts unauthenticated one short emergency requests, the = PSAP will likely be interested in any data updates which the UA is able = to provide. E.g. fire detection sensor could provide updates of the = temperature in the building. >> Poor example. The way we intend to determine temperatures in a = building is the "additional location data" mechanism, which would = probably (no details have been worked out yet) have a portal access to = the building control system. >=20 > Abstract of draft-ietf-ecrit-data-only-ea-06 states:=20 >=20 > Examples of such environments include a > __temperature sensors issuing alerts__, or vehicles sending crash = data. I can change the example. Issuing the alert is one thing, monitoring = the HVAC system is another. >=20 > Is the Abstract is wrong? It's just that a typical building has a wide variety of sensors and = actuators that are of interest to a responder. A good example is the = state of the water system or the air handing equipment, the elevators = and the door sensors. None of those are the ones that trigger the = alert. We're thinking about a portal to the building monitoring system = that let's a responder connect to the portal and get all the data, and = maybe even control aspects of it, if building management lets them. You also typically have more than one call about an incident, and you = need the same data whether you got a data-only alert or a telephone = call. >=20 >> The usual case where it is a device that has updates is that it uses = the credentials of the PSAP to allow subscription. Since the URL is = something it supplies, it can include a token, good for a small window = around the MESSAGE it sends. =20 >=20 > The UA normally do not know the identity of the PSAP and cannot = authenticate PSAP. This was discussed quite a lot in = draft-ietf-ecrit-psap-callback. The result is that just indication is = provided and UA needs to rely on network to assert it.=20 >=20 >> We want to ALLOW direct from the device messages, and we have a way = to do that. A way the PSAP controls, which I think is important. >=20 > I understand the PSAP control is wished. This could be provided in = INFO package mechanism as well. > =20 >> If the UA doesn't intend to provide updates, it doesn't offer a = SUBSCRIBE URI. If one is offered, and the PSAP wants updates, it will = subscribe. >=20 > The point is that UA may be able and may want to allow PSAP to request = the updates in every single request.=20 > Similarly, PSAP may want to decide that it wants the updates for every = single request.=20 > If this is the most common case, the MESSAGE + SUBSCRIBE/NOTIFY is = suboptimal. First of all, I think this is an uncommon case. The common cases I know = about have a service and it's not the device that the emergency = authorities connect to. Second of all, the MESSAGE goes to the PSAP, which usually only cares = about dispatching a responder. It is the responder who cares about the = data after that. Updates nearly always are of interest to responders = and not PSAPs. By sending a URI, we allow the responder to subscribe, = not just the PSAP. If we create a session, it's with the PSAP, not the = responder. We would have to transfer the session to the responder. > =20 >> For one thing devices that do this tend to move. MESSAGE does not = create a session. Sending updates requires a session where the routing = wouldn't change within the session. You can't send individual MESSAGE = transactions, because each one may route differently. That means we = would need for the initial alert to be in an INVITE, create a session = with no media, then send INFOs. Not a whole lot different. >=20 > Updates sent using subscription will require dialog as well so there = is really no difference related to UE movement. Agree, no difference. But we have a mechanism much better suited to = asynchronous notification in SUB/NOT vs INVITE/INFO. >=20 > IMO, the solution using INVITE (containing the 1st shot) followed by = INFOs would be simpler and (in comparision to MESSAGE+SUBSCRIBE/NOTIFY = solution): > 1) would enable updates sent by UA without credentials > 2) would not need to rely on trust between networks to preserve = information that SUBSCRIBE is sent by PSAP. As above, I don't think allowing devices without credentials to send = alerts is a good idea at all. I would prohibit it. What I'm proposing doesn't require trust between networks, it requires = trust between the device that sent the alert and the PSAP or responders = that get it. MITM is an issue if the signaling is observable however. > =20 > =20 >>> Thus the risk of missing trust between the networks is high - e.g. = when UA with US subscription is an african country, sends emergency = request to african PSAP, will the US home network of the UA trust the = african network claiming that SUBSCRIBE comes from PSAP? >> No network is involved. The question you are asking is will a US = device visiting Africa trust an African PSAP. When the MESSAGE is sent = the URI for the subscribe is that of the device, not the home or visited = network of the device. >=20 > 1) In normal SIP environment (like 3GPP IMS), PSAP will need to = involve some network to reach UA. If UA includes IP address and port in = the URI included in the MESSAGE, and PSAP sends SUBSCRIBE directly to = that IP address and port, the SUBSCRIBE will likely be blocked by a = firewall/SBC. And will INFO pass through IMS networks? Or will it be blocked by those = SBCs? >=20 > 2) US device trusts that the emergency message/call is delivered to = african PSAP since the UA set the Request-URI to the emergency URN. But = when SUBSCRIBE is received, how does the UA know that that SUBSCRIBE was = really sent by PSAP and not by malicious UE? Normally, the UA trusts its = home network to assert this, and its home network trusts the transit = networks, and the transit networks checks that message comes from PSAP. = So, there is chain of trust which is however difficult to achive if = several countries are involved. SUBSCRIBE is like any other SIP transaction. If you want to send them = all the way through the same path, you can. I think that is more = fragile, but you can do it. The PSAP sends the SUBSCRIBE to the visited = network that sent it the alert, which sends it to any transit networks = enroute to the home network that originated the alert. > =20 >> So you propose to recreate RFC6446 and 6447 in an INFO package? >=20 > Not sure if all of that is needed, but possibly.=20 It would be necessary I think. From brian.rosen@neustar.biz Wed Jul 17 12:10:37 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBF821F9B0D for ; Wed, 17 Jul 2013 12:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.62 X-Spam-Level: X-Spam-Status: No, score=-5.62 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTkxL44uCrdJ for ; Wed, 17 Jul 2013 12:10:33 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1332321F9A1C for ; Wed, 17 Jul 2013 12:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374088197; x=1689441797; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=sx8RMasenXqzT9jSplPCV0jzHyTYiSYXegA1AeKoAiI=; b=fFRkHAxCeWwxpGpzvQHsthpjmu/l8YR1uAw87W17ZWyRKZd3aSQHZqnaM9bbLV i1o1E1a12qZNYXiy9oQoLN3g== Received: from ([10.31.58.69]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22504319; Wed, 17 Jul 2013 15:09:55 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 17 Jul 2013 15:10:22 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org WG" Thread-Topic: LoST recursion and Forest Guides Thread-Index: AQHOgyFJU8ETq0n8JkKNvkzlp5DbOw== Date: Wed, 17 Jul 2013 19:10:22 +0000 Message-ID: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: hfj82O91GsprGfJprkpi3g== Content-Type: multipart/alternative; boundary="_000_280B2BB7471B4539A26974FEAB469C95neustarbiz_" MIME-Version: 1.0 Subject: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:10:37 -0000 --_000_280B2BB7471B4539A26974FEAB469C95neustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An issue arose in a NENA discussion that calls into question the RFC5222, S= ection 8.3.3 text that reads: Regardless of the attribute, a server MAY always answer a query by providing a LoST application unique string (see Section 4), i.e., indirection; however, it MUST NOT recurse if the attribute is "false". Imagine that an area has a local LoST server that answers local requests, a= nd that server is aware of a regional or state/provincial server, which in = turn is aware of a national forest guide. Suppose a request to a local server has a location which is out of state/pr= ovince. If the 'recursive' attribute is missing or set false, the local LoST server= would return the URI of the regional or state server. The regional or sta= te server would return the URI of the national forest guide. This means that the national forest guide must be prepared to answer querie= s from any device at any time. In particular, it has to be sized for the w= orst case scenario where a very large number of devices make requests of it= , and it cannot refuse a request from any source (as a practical matter). = This makes it a very attractive DDoS target. In fact, I would argue that a= great number of implementations will simply start all queries at the top o= f the tree in all cases, since the forest guide URI will become well known = quickly. This is very undesirable in my opinion. Instead, we should allow the local= and/or state/regional LoST servers to query the Forest Guide and return th= e response. This would allow the Forest Guide to restrict who is able to q= uery it, possibly to only those entities that provide it coverage regions, = or some similar smaller set of queriers. What prevents us from doing that is the requirement that the server MUST NO= T recurse if the attribute is missing or set false. I would actually like to go farther. I'd prefer that the state and possibl= y the regional LoST servers be able to restrict who can query them, for the= same reasons. I would like all queries to start at the local server, and allow that serve= r to recurse, if it prefers to, regardless of the attribute. Brian --_000_280B2BB7471B4539A26974FEAB469C95neustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <13637420430EBB409E36CD113FFD10BD@neustar.biz> Content-Transfer-Encoding: quoted-printable An issue arose in a NENA discussion that calls into question the RFC5222, S= ection 8.3.3 text that reads:
Imagine that an area has a local LoST server that answers local reques= ts, and that server is aware of a regional or state/provincial server, whic= h in turn is aware of a national forest guide.

Suppose a request to a local server has a location which is out of sta= te/province.

If the 'recursive' attribute is missing or set false, the local LoST s= erver would return the URI of the regional or state server.  The regio= nal or state server would return the URI of the national forest guide.

This means that the national forest guide must be prepared to answer q= ueries from any device at any time.  In particular, it has to be sized= for the worst case scenario where a very large number of devices make requ= ests of it, and it cannot refuse a request from any source (as a practical matter).  This makes it a very attrac= tive DDoS target.  In fact, I would argue that a great number of imple= mentations will simply start all queries at the top of the tree in all case= s, since the forest guide URI will become well known quickly.

This is very undesirable in my opinion.  Instead, we should allow= the local and/or state/regional LoST servers to query the Forest Guide and= return the response.  This would allow the Forest Guide to restrict w= ho is able to query it, possibly to only those entities that provide it coverage regions, or some similar smaller set of = queriers.

What prevents us from doing that is the requirement that the server MU= ST NOT recurse if the attribute is missing or set false.

I would actually like to go farther.  I'd prefer that the state a= nd possibly the regional LoST servers be able to restrict who can query the= m, for the same reasons.

I would like all queries to start at the local server, and allow that = server to recurse, if it prefers to, regardless of the attribute.

Brian

--_000_280B2BB7471B4539A26974FEAB469C95neustarbiz_-- From RMarshall@telecomsys.com Wed Jul 17 15:06:56 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E2221F9EEB for ; Wed, 17 Jul 2013 15:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhN30vqX7ip2 for ; Wed, 17 Jul 2013 15:06:51 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id C198421F9E6E for ; Wed, 17 Jul 2013 15:06:51 -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.1/8.14.1) with ESMTP id r6HM6fDb031682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 17 Jul 2013 15:06:42 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.236]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Wed, 17 Jul 2013 15:06:41 -0700 From: Roger Marshall To: "'ecrit@ietf.org'" Thread-Topic: Ecrit agenda for the IETF87 Berlin meeting Thread-Index: Ac6DOO5Y+7xiwVMrQ8Gbk0eJR33ThA== Date: Wed, 17 Jul 2013 22:06:41 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC36FA5BSEAEXMB2telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] Ecrit agenda for the IETF87 Berlin meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:06:56 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC36FA5BSEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See the agenda below, which is also posted in the Meeting Materials Manager, http://www.ietf.org/proceedings/87/agenda/agenda-87-ecrit ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall) 20 min * Additional Data related to an Emergency Call (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss latest changes and if ready for WGLC 15 min. * Trustworthy Location Information (Bernard) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss impact of recent rewrite 10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts us= ing the Session Initiation Protocol (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Intention: Discuss recent updates to draft 15 min * Internet Protocol-based In-Vehicle Emergency Call (Hannes) http://tools.ietf.org/id/draft-rosen-ecrit-ecall/ Intention: Discussion of draft & WG adoption question 10 min * A LoST extension to support return of complete and similar locatio= n info (Brian) http://tools.ietf.org/id/draft-marshall-ecrit-similar-location Intention: Discussion of changes to draft 15 min * eCall - background, current status, and requirements discussion li= nked to current ETSI work (Ban Al-Bakri) 10 min * Service Coverage Scope for Service URN (Brian) http://tools.ietf.org/id/draft-mongrain-ecrit-service-coverage-scope-urn/ Intention: Discuss new draft 10 min * Uniform Resource Name (URN) extension for automatic and manual Eme= rgency Services (Roland) draft-jesske-ecrit-ecall-urn-extension-01 Intention: Discussion of changes to draft 5 min * Open Discussion 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_FBD5AAFFD0978846BF6D3FAB4C892ACC36FA5BSEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See the agenda below, = which is also posted in the Meeting Materials Manager,

http://www.ietf.org/pr= oceedings/87/agenda/agenda-87-ecrit

 

 

ECRIT Agenda - 13:00-15:00, Monday, July 2= 9, 2013 Berlin

 

10 min * Agenda Bashing, Draft Status Upda= te (Marc Linsner, Roger Marshall)

 

20 min * Additional Data related to an Eme= rgency Call (Brian)

http://datatracker.ietf.org/doc/draft-ietf= -ecrit-additional-data/

Intention: Discuss latest changes and if r= eady for WGLC

 

15 min. * Trustworthy Location Information= (Bernard)

http://datatracker.ietf.org/doc/draft-ietf= -ecrit-trustworthy-location/

Intention: Discuss impact of recent rewrit= e

 

10 min * Common Alerting Protocol (CAP) ba= sed Data-Only Emergency Alerts using the Session Initiation Protocol (Brian= )

http://datatracker.ietf.org/doc/draft-ietf= -ecrit-data-only-ea/

Intention: Discuss recent updates to draft=

 

15 min * Internet Protocol-based In-Vehicl= e Emergency Call (Hannes)

http://tools.ietf.org/id/draft-rosen-ecrit= -ecall/

Intention: Discussion of draft & WG ad= option question

 

10 min * A LoST extension to support retur= n of complete and similar location info (Brian)

http://tools.ietf.org/id/draft-marshall-ec= rit-similar-location

Intention: Discussion of changes to draft<= o:p>

 

15 min * eCall - background, current statu= s, and requirements discussion linked to current ETSI work (Ban Al-Bakri)

 

10 min * Service Coverage Scope for Servic= e URN (Brian)

http://tools.ietf.org/id/draft-mongrain-ec= rit-service-coverage-scope-urn/

Intention: Discuss new draft

 

10 min * Uniform Resource Name (URN) exten= sion for automatic and manual Emergency Services (Roland)=

draft-jesske-ecrit-ecall-urn-extension-01<= o:p>

Intention: Discussion of changes to draft<= o:p>

 

5 min * Open Discussion<= /p>

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_FBD5AAFFD0978846BF6D3FAB4C892ACC36FA5BSEAEXMB2telecomsy_-- From ivo.sedlacek@ericsson.com Thu Jul 18 00:13:05 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B303321F997B for ; Thu, 18 Jul 2013 00:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=1.217, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw0QbXmCt+5s for ; Thu, 18 Jul 2013 00:13:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2550421F880F for ; Thu, 18 Jul 2013 00:12:58 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-cd-51e79579345b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D0.CB.06741.97597E15; Thu, 18 Jul 2013 09:12:57 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.30]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Thu, 18 Jul 2013 09:12:56 +0200 From: Ivo Sedlacek To: Brian Rosen Thread-Topic: issues in draft-ietf-ecrit-data-only-ea-06 and draft-rosen-ecrit-addldata-subnot-00 (was RE: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05) Thread-Index: Ac6DfkycsJgsyaSMSrqhCmHs/DkA7A== Date: Thu, 18 Jul 2013 07:12:56 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010F7E49@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvrW7l1OeBBhdXaFg8vT+NzaJx0VNW ByaP+9/+snssWfKTKYApissmJTUnsyy1SN8ugSvjwiO/gmd5Fe1HZrA3MG6I6GLk5JAQMJH4 8/4KG4QtJnHh3nowW0jgMKPEjtm6XYxcQPZiRok7r7eygCTYBPQkJm45wgpiiwgoS+y81ckO YjMLqEqca3zMAtIgLDCfUeL65pnsII6IwBJGic9tb5khOvQkDvYtAOtmAero2NLPCGLzCnhL HP7xC2wSo4CsxNU/vYwQU8Ulbj2ZzwRxnoDEkj3nmSFsUYmXj/+xQtiKEjvPtjND1OtJPDs1 iwXC1pZYtvA1M8R8QYmTM5+wTGAUmYVk7CwkLbOQtMxC0rKAkWUVI3tuYmZOernhJkZg0B/c 8lt3B+OpcyKHGKU5WJTEeTfpnQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwDg1veGtUMsZ w6mZXtrsr+//2B5bFidQZt2yLbnRzKOZb9uT4N8WG+JqbVz6fwTEdV+4GPld99c235m3FeNN l4psOaNRIuow98DHYt4aQaFT17X9mBZdP5wvctLh8dp91T4xe7j2TajKnXRIYqlRj9GGFNv2 mF/lLvfbp8n037jEdemJl++7i0osxRmJhlrMRcWJAD/BifpIAgAA Cc: "ecrit@ietf.org" Subject: [Ecrit] issues in draft-ietf-ecrit-data-only-ea-06 and draft-rosen-ecrit-addldata-subnot-00 (was RE: Question to draft-ietf-ecrit-data-only-ea-05) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 07:13:05 -0000 Hello Brian, my conclusions of the discussion: ISSUE 1: -------------------------- if the UA and the PSAP wish to provide updates, the solution in the drafts = requires UA to provide a URI which PSAP uses to send out-of-dialog SUBSCRI= BE request to the UA. This URI needs to be a globally routable URI.=20 Since UAs are normally behind SBG/firewall and do not have globally routabl= e URI, this requires UA to be registered to get a globally routable URI.=20 If the UA does not have valid credentials, the registration will fail. In contrast, INFO based solution would not suffer from this problem as ever= ything is sent within dialog of emergency call. --------------------------=09 PROPOSAL 1: -------------------------- Record in the drafts that if the UA and the PSAP wish to provide updates, w= hen the UA does not have a globally routable URI (e.g. due to not having va= lid credentials which would enable registration providing GRUU to the UA), = then solution in the drafts does not work. -------------------------- ISSUE 2: -------------------------- The drafts do not solve how the UA is able to detect whether the subscriber= is an authorized entity or man-in-the-middle intercepting the MESSAGE or t= he previous SUBSCRIBE. Roaming UAs (e.g. in cars) are not aware of identiti= es of PSAPs or responders in visited country. In contrast, INFO based solution would not suffer from this problem as ever= ything is sent within dialog of emergency call. --------------------------=09 PROPOSAL 2: -------------------------- Record this security issue in the drafts. -------------------------- On: > What I'm proposing doesn't require trust between networks, it requires tr= ust between the device that sent the alert and the PSAP or responders that = get it.=20 The UA, particularly UA roaming to a different country (common for UAs in c= ars), does not know the PSAP or responder identity. > And will INFO pass through IMS networks? Or will it be blocked by those S= BCs? INFO is an in-dialog request. Moreover, it would be sent within an emergenc= y call. It would be passed. > SUBSCRIBE is like any other SIP transaction. If you want to send them al= l the way through the same path, you can. =20 > I think that is more fragile, but you can do it. =20 > The PSAP sends the SUBSCRIBE to the visited network that sent it the aler= t, which sends it to any transit networks enroute to the home network that = originated the alert. The visited network does not provide globally routable URI to the UA. It is= the registrar in the home network which provides GRUU during registration. So, the SUBSCRIBE from PSAP will traverse: PSAP (African country) - network= serving PSAP (African country) - transit network (any country) - home oper= ator (US) - visited network (African country) - UA.=20 In comparison, emergency requests sent by UA or exchanged in the emergency = dialogs initiated by UA will traverse: UA - visited network (African countr= y) - PSAP (African country) In the latter case, it is much easier to ensure trust for the "this-is-sent= -by-PSAP" information or resource priority as one regulatory body governs t= he whole signalling path.=20 Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 17. =E8ervence 2013 20:21 To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 Hi Ivo See inline. On Jul 17, 2013, at 11:13 AM, Ivo Sedlacek wrot= e: > please see below. Kind regards Ivo Sedlacek >=20 > This Communication is Confidential. We only send and receive email on the= basis of the terms set out at www.ericsson.com/email_disclaimer=20 > =20 >>>>> Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the subsc= riber and the UA is the notifier, this would require reachability of UA for= initial request for dialog (i.e. SUBSCRIBE). However, when the UA is not r= egistered e.g. due to missing credentials, the UA is normally not reachable= for SIP requests other than those sent within the dialog of the emergency = call. >>>> =20 >>>> I think the combination of missing credentials, and data updates is so= unlikely that the problem of PSAP control of updates dwarfs it. >=20 > The issue above was related to UA not being reachable for incoming reques= ts due to __UA__ not having its credentials.=20 >=20 > Networks (like 3GPP IMS) enable UA without valid credentials to only send= emergency requests and requests sent within dialogs created by emergency r= equest.=20 > To receive requests sent outside of dialog created by emergency requests,= the UA needs to be registered. > To be registered, the UA needs to have valid credentials. I misunderstood >=20 > Note that some countries require UAs to be able to make voice emergency c= all even if the UA does not valid credentials.=20 Yeah, but none of them require devices to be able to send data updates if t= hey are not registered. >=20 > Why should that be not be required as well for data only emergency reques= ts? Personal opinion - because it's a DDoS attack opening towards a PSAP. I wo= uld prohibit it. All the PSAPs I am in discussion with are afraid of such = problems. As an example, in the U.S., in most cases, alarm systems are n= ot permitted to connect directly to a PSAP - they must connect through a "C= entral Alarm Monitoring" service. We hope to change that, but only if we c= an guarantee that the PSAP is protected, and they believe they are protecte= d. >=20 >> Because PSAPs will have credentials, and most sensor based devices where= it's the device making the call don't update fast enough to be interesting= . I also think in most cases, devices will publish to a server, and the se= rver will send the alert. >=20 > The above describes some particular architecture where SIP and non SIP si= gnalling is mixed, or perhaps server acts as SIP B2BUA, not sure. Which ent= ity is the SIP UA - the "server" or the "device" or both? The above assumes the device is registered to a service that aids it. Most= devices that have this kind of capability do that, but not all. If there is a service, the service has a server, the UA publishes updates t= o the server, the PSAP subscribes to the server. If there is no service, the device UA is the server, and the PSAP subscribe= s to it. >=20 > Why would the UA not be able to provide updates fast enough? Even if the = UAs are not able to do it today, why shouldn't they be able to do it in fut= ure? Not a matter of able to, it's just that the data on such devices doesn't ch= ange enough over the course of a call to be interesting. Once a car crashe= s, it has crash data, but it doesn't change. If a fire starts, the fire co= uld go out on it's own, but usually the fire brigade goes out anyway - upda= tes aren't interesting. Same with burglar alarms. It's only a device like a heart monitor that would have updates that would = be interesting, but in my experience, such devices have services that inter= pret the raw data from the sensor into more useful data for responders. > =20 >>> If PSAP accepts unauthenticated one short emergency requests, the PSAP = will likely be interested in any data updates which the UA is able to provi= de. E.g. fire detection sensor could provide updates of the temperature in = the building. >> Poor example. The way we intend to determine temperatures in a building= is the "additional location data" mechanism, which would probably (no deta= ils have been worked out yet) have a portal access to the building control = system. >=20 > Abstract of draft-ietf-ecrit-data-only-ea-06 states:=20 >=20 > Examples of such environments include a > __temperature sensors issuing alerts__, or vehicles sending crash data. I can change the example. Issuing the alert is one thing, monitoring the H= VAC system is another. >=20 > Is the Abstract is wrong? It's just that a typical building has a wide variety of sensors and actuato= rs that are of interest to a responder. A good example is the state of the= water system or the air handing equipment, the elevators and the door sens= ors. None of those are the ones that trigger the alert. We're thinking ab= out a portal to the building monitoring system that let's a responder conne= ct to the portal and get all the data, and maybe even control aspects of it= , if building management lets them. You also typically have more than one call about an incident, and you need = the same data whether you got a data-only alert or a telephone call. >=20 >> The usual case where it is a device that has updates is that it uses the= credentials of the PSAP to allow subscription. Since the URL is something= it supplies, it can include a token, good for a small window around the ME= SSAGE it sends. =20 >=20 > The UA normally do not know the identity of the PSAP and cannot authentic= ate PSAP. This was discussed quite a lot in draft-ietf-ecrit-psap-callback.= The result is that just indication is provided and UA needs to rely on net= work to assert it.=20 >=20 >> We want to ALLOW direct from the device messages, and we have a way to d= o that. A way the PSAP controls, which I think is important. >=20 > I understand the PSAP control is wished. This could be provided in INFO p= ackage mechanism as well. > =20 >> If the UA doesn't intend to provide updates, it doesn't offer a SUBSCRIB= E URI. If one is offered, and the PSAP wants updates, it will subscribe. >=20 > The point is that UA may be able and may want to allow PSAP to request th= e updates in every single request.=20 > Similarly, PSAP may want to decide that it wants the updates for every si= ngle request.=20 > If this is the most common case, the MESSAGE + SUBSCRIBE/NOTIFY is subopt= imal. First of all, I think this is an uncommon case. The common cases I know ab= out have a service and it's not the device that the emergency authorities c= onnect to. Second of all, the MESSAGE goes to the PSAP, which usually only cares about= dispatching a responder. It is the responder who cares about the data aft= er that. Updates nearly always are of interest to responders and not PSAPs= . By sending a URI, we allow the responder to subscribe, not just the PSAP= . If we create a session, it's with the PSAP, not the responder. We would= have to transfer the session to the responder. > =20 >> For one thing devices that do this tend to move. MESSAGE does not creat= e a session. Sending updates requires a session where the routing wouldn't= change within the session. You can't send individual MESSAGE transactions= , because each one may route differently. That means we would need for the= initial alert to be in an INVITE, create a session with no media, then sen= d INFOs. Not a whole lot different. >=20 > Updates sent using subscription will require dialog as well so there is r= eally no difference related to UE movement. Agree, no difference. But we have a mechanism much better suited to asynch= ronous notification in SUB/NOT vs INVITE/INFO. >=20 > IMO, the solution using INVITE (containing the 1st shot) followed by INFO= s would be simpler and (in comparision to MESSAGE+SUBSCRIBE/NOTIFY solution= ): > 1) would enable updates sent by UA without credentials > 2) would not need to rely on trust between networks to preserve informati= on that SUBSCRIBE is sent by PSAP. As above, I don't think allowing devices without credentials to send alerts= is a good idea at all. I would prohibit it. What I'm proposing doesn't require trust between networks, it requires trus= t between the device that sent the alert and the PSAP or responders that ge= t it. MITM is an issue if the signaling is observable however. > =20 > =20 >>> Thus the risk of missing trust between the networks is high - e.g. when= UA with US subscription is an african country, sends emergency request to = african PSAP, will the US home network of the UA trust the african network = claiming that SUBSCRIBE comes from PSAP? >> No network is involved. The question you are asking is will a US device= visiting Africa trust an African PSAP. When the MESSAGE is sent the URI f= or the subscribe is that of the device, not the home or visited network of = the device. >=20 > 1) In normal SIP environment (like 3GPP IMS), PSAP will need to involve s= ome network to reach UA. If UA includes IP address and port in the URI incl= uded in the MESSAGE, and PSAP sends SUBSCRIBE directly to that IP address a= nd port, the SUBSCRIBE will likely be blocked by a firewall/SBC. And will INFO pass through IMS networks? Or will it be blocked by those SBC= s? >=20 > 2) US device trusts that the emergency message/call is delivered to afric= an PSAP since the UA set the Request-URI to the emergency URN. But when SUB= SCRIBE is received, how does the UA know that that SUBSCRIBE was really sen= t by PSAP and not by malicious UE? Normally, the UA trusts its home network= to assert this, and its home network trusts the transit networks, and the = transit networks checks that message comes from PSAP. So, there is chain of= trust which is however difficult to achive if several countries are involv= ed. SUBSCRIBE is like any other SIP transaction. If you want to send them all = the way through the same path, you can. I think that is more fragile, but = you can do it. The PSAP sends the SUBSCRIBE to the visited network that se= nt it the alert, which sends it to any transit networks enroute to the home= network that originated the alert. > =20 >> So you propose to recreate RFC6446 and 6447 in an INFO package? >=20 > Not sure if all of that is needed, but possibly.=20 It would be necessary I think. From br@brianrosen.net Thu Jul 18 05:51:13 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CD321E80F8 for ; Thu, 18 Jul 2013 05:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.302 X-Spam-Level: X-Spam-Status: No, score=-100.302 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bc8WQ+S3Y-d for ; Thu, 18 Jul 2013 05:51:08 -0700 (PDT) Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id B2F0321E80EA for ; Thu, 18 Jul 2013 05:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=01DmfW4jR0jSUtfiWgtOqgdTh+saKp7+u6/hCLeEyT0=; b=PnqsichWW/8OEF0tuVZbDleaELqAc7ktFmUuRW9Cur1VAEqKEIGOXDnNcocA7L7TspOiuDJZax2YvrWwmRIKMEIUDu8Yn5z52VLt/1gG40EBZ1p2ZVCeNHRe75m1q5SZGYBtQhaa61qHnqGUL2fedq11qA7P/G0Hi8V4HOexOVM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:57494 helo=[10.33.192.17]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UznfF-0005yt-On; Thu, 18 Jul 2013 08:50:33 -0400 Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Rosen In-Reply-To: <39B5E4D390E9BD4890E2B310790061010F7E49@ESESSMB301.ericsson.se> Date: Thu, 18 Jul 2013 08:50:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <670140B0-DC31-4922-82EF-45CAF73772F8@brianrosen.net> References: <39B5E4D390E9BD4890E2B310790061010F7E49@ESESSMB301.ericsson.se> To: Ivo Sedlacek X-Mailer: Apple Mail (2.1508) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] issues in draft-ietf-ecrit-data-only-ea-06 and draft-rosen-ecrit-addldata-subnot-00 (was RE: Question to draft-ietf-ecrit-data-only-ea-05) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 12:51:13 -0000 Hi Ivo I will note this limitations in the next edition of the draft. The working group can decide if they think they are more important than = I think they are. I will raise the issue when I discuss the draft in = Berlin. Brian On Jul 18, 2013, at 3:12 AM, Ivo Sedlacek = wrote: > Hello Brian, >=20 > my conclusions of the discussion: >=20 > ISSUE 1: > -------------------------- > if the UA and the PSAP wish to provide updates, the solution in the = drafts requires UA to provide a URI which PSAP uses to send = out-of-dialog SUBSCRIBE request to the UA. This URI needs to be a = globally routable URI.=20 > Since UAs are normally behind SBG/firewall and do not have globally = routable URI, this requires UA to be registered to get a globally = routable URI.=20 > If the UA does not have valid credentials, the registration will fail. >=20 > In contrast, INFO based solution would not suffer from this problem as = everything is sent within dialog of emergency call. > --------------------------=09 >=20 > PROPOSAL 1: > -------------------------- > Record in the drafts that if the UA and the PSAP wish to provide = updates, when the UA does not have a globally routable URI (e.g. due to = not having valid credentials which would enable registration providing = GRUU to the UA), then solution in the drafts does not work. > -------------------------- >=20 >=20 > ISSUE 2: > -------------------------- > The drafts do not solve how the UA is able to detect whether the = subscriber is an authorized entity or man-in-the-middle intercepting the = MESSAGE or the previous SUBSCRIBE. Roaming UAs (e.g. in cars) are not = aware of identities of PSAPs or responders in visited country. >=20 > In contrast, INFO based solution would not suffer from this problem as = everything is sent within dialog of emergency call. > --------------------------=09 >=20 > PROPOSAL 2: > -------------------------- > Record this security issue in the drafts. > -------------------------- >=20 >=20 > On: >=20 >> What I'm proposing doesn't require trust between networks, it = requires trust between the device that sent the alert and the PSAP or = responders that get it.=20 >=20 > The UA, particularly UA roaming to a different country (common for UAs = in cars), does not know the PSAP or responder identity. >=20 >> And will INFO pass through IMS networks? Or will it be blocked by = those SBCs? >=20 > INFO is an in-dialog request. Moreover, it would be sent within an = emergency call. It would be passed. >=20 >> SUBSCRIBE is like any other SIP transaction. If you want to send = them all the way through the same path, you can. =20 >> I think that is more fragile, but you can do it. =20 >> The PSAP sends the SUBSCRIBE to the visited network that sent it the = alert, which sends it to any transit networks enroute to the home = network that originated the alert. >=20 > The visited network does not provide globally routable URI to the UA. = It is the registrar in the home network which provides GRUU during = registration. >=20 > So, the SUBSCRIBE from PSAP will traverse: PSAP (African country) - = network serving PSAP (African country) - transit network (any country) - = home operator (US) - visited network (African country) - UA.=20 >=20 > In comparison, emergency requests sent by UA or exchanged in the = emergency dialogs initiated by UA will traverse: UA - visited network = (African country) - PSAP (African country) >=20 > In the latter case, it is much easier to ensure trust for the = "this-is-sent-by-PSAP" information or resource priority as one = regulatory body governs the whole signalling path.=20 >=20 > Kind regards >=20 > Ivo Sedlacek >=20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 17. =E8ervence 2013 20:21 > To: Ivo Sedlacek > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Question to draft-ietf-ecrit-data-only-ea-05 >=20 > Hi Ivo >=20 > See inline. >=20 > On Jul 17, 2013, at 11:13 AM, Ivo Sedlacek = wrote: >=20 >> please see below. Kind regards Ivo Sedlacek >>=20 >> This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer=20 >>=20 >>>>>> Issue 1: If SUBSCRIBE/NOTIFY mechanism is used, the PSAP is the = subscriber and the UA is the notifier, this would require reachability = of UA for initial request for dialog (i.e. SUBSCRIBE). However, when the = UA is not registered e.g. due to missing credentials, the UA is normally = not reachable for SIP requests other than those sent within the dialog = of the emergency call. >>>>>=20 >>>>> I think the combination of missing credentials, and data updates = is so unlikely that the problem of PSAP control of updates dwarfs it. >>=20 >> The issue above was related to UA not being reachable for incoming = requests due to __UA__ not having its credentials.=20 >>=20 >> Networks (like 3GPP IMS) enable UA without valid credentials to only = send emergency requests and requests sent within dialogs created by = emergency request.=20 >> To receive requests sent outside of dialog created by emergency = requests, the UA needs to be registered. >> To be registered, the UA needs to have valid credentials. > I misunderstood >>=20 >> Note that some countries require UAs to be able to make voice = emergency call even if the UA does not valid credentials.=20 > Yeah, but none of them require devices to be able to send data updates = if they are not registered. >=20 >>=20 >> Why should that be not be required as well for data only emergency = requests? > Personal opinion - because it's a DDoS attack opening towards a PSAP. = I would prohibit it. All the PSAPs I am in discussion with are afraid = of such problems. As an example, in the U.S., in most cases, alarm = systems are not permitted to connect directly to a PSAP - they must = connect through a "Central Alarm Monitoring" service. We hope to change = that, but only if we can guarantee that the PSAP is protected, and they = believe they are protected. >=20 >>=20 >>> Because PSAPs will have credentials, and most sensor based devices = where it's the device making the call don't update fast enough to be = interesting. I also think in most cases, devices will publish to a = server, and the server will send the alert. >>=20 >> The above describes some particular architecture where SIP and non = SIP signalling is mixed, or perhaps server acts as SIP B2BUA, not sure. = Which entity is the SIP UA - the "server" or the "device" or both? > The above assumes the device is registered to a service that aids it. = Most devices that have this kind of capability do that, but not all. > If there is a service, the service has a server, the UA publishes = updates to the server, the PSAP subscribes to the server. >=20 > If there is no service, the device UA is the server, and the PSAP = subscribes to it. >=20 >>=20 >> Why would the UA not be able to provide updates fast enough? Even if = the UAs are not able to do it today, why shouldn't they be able to do it = in future? > Not a matter of able to, it's just that the data on such devices = doesn't change enough over the course of a call to be interesting. Once = a car crashes, it has crash data, but it doesn't change. If a fire = starts, the fire could go out on it's own, but usually the fire brigade = goes out anyway - updates aren't interesting. >=20 > Same with burglar alarms. >=20 > It's only a device like a heart monitor that would have updates that = would be interesting, but in my experience, such devices have services = that interpret the raw data from the sensor into more useful data for = responders. >=20 >=20 >>=20 >>>> If PSAP accepts unauthenticated one short emergency requests, the = PSAP will likely be interested in any data updates which the UA is able = to provide. E.g. fire detection sensor could provide updates of the = temperature in the building. >>> Poor example. The way we intend to determine temperatures in a = building is the "additional location data" mechanism, which would = probably (no details have been worked out yet) have a portal access to = the building control system. >>=20 >> Abstract of draft-ietf-ecrit-data-only-ea-06 states:=20 >>=20 >> Examples of such environments include a >> __temperature sensors issuing alerts__, or vehicles sending crash = data. > I can change the example. Issuing the alert is one thing, monitoring = the HVAC system is another. >=20 >>=20 >> Is the Abstract is wrong? > It's just that a typical building has a wide variety of sensors and = actuators that are of interest to a responder. A good example is the = state of the water system or the air handing equipment, the elevators = and the door sensors. None of those are the ones that trigger the = alert. We're thinking about a portal to the building monitoring system = that let's a responder connect to the portal and get all the data, and = maybe even control aspects of it, if building management lets them. >=20 > You also typically have more than one call about an incident, and you = need the same data whether you got a data-only alert or a telephone = call. >=20 >>=20 >>> The usual case where it is a device that has updates is that it uses = the credentials of the PSAP to allow subscription. Since the URL is = something it supplies, it can include a token, good for a small window = around the MESSAGE it sends. =20 >>=20 >> The UA normally do not know the identity of the PSAP and cannot = authenticate PSAP. This was discussed quite a lot in = draft-ietf-ecrit-psap-callback. The result is that just indication is = provided and UA needs to rely on network to assert it.=20 >>=20 >>> We want to ALLOW direct from the device messages, and we have a way = to do that. A way the PSAP controls, which I think is important. >>=20 >> I understand the PSAP control is wished. This could be provided in = INFO package mechanism as well. >>=20 >>> If the UA doesn't intend to provide updates, it doesn't offer a = SUBSCRIBE URI. If one is offered, and the PSAP wants updates, it will = subscribe. >>=20 >> The point is that UA may be able and may want to allow PSAP to = request the updates in every single request.=20 >> Similarly, PSAP may want to decide that it wants the updates for = every single request.=20 >> If this is the most common case, the MESSAGE + SUBSCRIBE/NOTIFY is = suboptimal. > First of all, I think this is an uncommon case. The common cases I = know about have a service and it's not the device that the emergency = authorities connect to. >=20 > Second of all, the MESSAGE goes to the PSAP, which usually only cares = about dispatching a responder. It is the responder who cares about the = data after that. Updates nearly always are of interest to responders = and not PSAPs. By sending a URI, we allow the responder to subscribe, = not just the PSAP. If we create a session, it's with the PSAP, not the = responder. We would have to transfer the session to the responder. >=20 >>=20 >>> For one thing devices that do this tend to move. MESSAGE does not = create a session. Sending updates requires a session where the routing = wouldn't change within the session. You can't send individual MESSAGE = transactions, because each one may route differently. That means we = would need for the initial alert to be in an INVITE, create a session = with no media, then send INFOs. Not a whole lot different. >>=20 >> Updates sent using subscription will require dialog as well so there = is really no difference related to UE movement. > Agree, no difference. But we have a mechanism much better suited to = asynchronous notification in SUB/NOT vs INVITE/INFO. >=20 >>=20 >> IMO, the solution using INVITE (containing the 1st shot) followed by = INFOs would be simpler and (in comparision to MESSAGE+SUBSCRIBE/NOTIFY = solution): >> 1) would enable updates sent by UA without credentials >> 2) would not need to rely on trust between networks to preserve = information that SUBSCRIBE is sent by PSAP. > As above, I don't think allowing devices without credentials to send = alerts is a good idea at all. I would prohibit it. > What I'm proposing doesn't require trust between networks, it requires = trust between the device that sent the alert and the PSAP or responders = that get it. MITM is an issue if the signaling is observable however. >=20 >>=20 >>=20 >>>> Thus the risk of missing trust between the networks is high - e.g. = when UA with US subscription is an african country, sends emergency = request to african PSAP, will the US home network of the UA trust the = african network claiming that SUBSCRIBE comes from PSAP? >>> No network is involved. The question you are asking is will a US = device visiting Africa trust an African PSAP. When the MESSAGE is sent = the URI for the subscribe is that of the device, not the home or visited = network of the device. >>=20 >> 1) In normal SIP environment (like 3GPP IMS), PSAP will need to = involve some network to reach UA. If UA includes IP address and port in = the URI included in the MESSAGE, and PSAP sends SUBSCRIBE directly to = that IP address and port, the SUBSCRIBE will likely be blocked by a = firewall/SBC. > And will INFO pass through IMS networks? Or will it be blocked by = those SBCs? >=20 >>=20 >> 2) US device trusts that the emergency message/call is delivered to = african PSAP since the UA set the Request-URI to the emergency URN. But = when SUBSCRIBE is received, how does the UA know that that SUBSCRIBE was = really sent by PSAP and not by malicious UE? Normally, the UA trusts its = home network to assert this, and its home network trusts the transit = networks, and the transit networks checks that message comes from PSAP. = So, there is chain of trust which is however difficult to achive if = several countries are involved. > SUBSCRIBE is like any other SIP transaction. If you want to send them = all the way through the same path, you can. I think that is more = fragile, but you can do it. The PSAP sends the SUBSCRIBE to the visited = network that sent it the alert, which sends it to any transit networks = enroute to the home network that originated the alert. >=20 >>=20 >>> So you propose to recreate RFC6446 and 6447 in an INFO package? >>=20 >> Not sure if all of that is needed, but possibly.=20 > It would be necessary I think. >=20 >=20 From martin.thomson@gmail.com Thu Jul 18 10:28:43 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5AE21F8C4C for ; Thu, 18 Jul 2013 10:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pp20yp7LNBjn for ; Thu, 18 Jul 2013 10:28:33 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5B12B11E81B1 for ; Thu, 18 Jul 2013 10:27:51 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w57so3207030wes.15 for ; Thu, 18 Jul 2013 10:27:50 -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=eEb/TErapRtWPtYrAcHLBbuwPhmpZ6PR9MRDjdDIZUk=; b=m5A027k1p9X2Vc4AkSfZyAjwT49wLMFL+0k1cWPc524bfzLw5WHGwctFEIoYCFD9My nsQ66K4DkbqM1BeKq08XiqI1VFk8czExlGR0f2FGS7fWPeZrzh7n5IdQ9yLZR6fBrES/ luIe3pdtpVGf+Xxg8OSRjDLvgajnTeBt0iqRHoLvsSA90dhdOeoMaSFiu47AcH55kmWA jthd8RdeLfjrAKJS5iHC5DcQaqt4DEZQ8sso0GUB0VLXhh/3jqpB/RvGUAmHJ51M8jzD eXUDL9L4ug/mWoqSwB3R2ott2tSTGJTN9hbbqo3/TRwJq4OS0hmeuQHOhldlFOkmZsL6 awaw== MIME-Version: 1.0 X-Received: by 10.194.110.6 with SMTP id hw6mr9518809wjb.3.1374168470415; Thu, 18 Jul 2013 10:27:50 -0700 (PDT) Received: by 10.194.60.46 with HTTP; Thu, 18 Jul 2013 10:27:50 -0700 (PDT) In-Reply-To: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> References: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> Date: Thu, 18 Jul 2013 10:27:50 -0700 Message-ID: From: Martin Thomson To: "Rosen, Brian" Content-Type: text/plain; charset=UTF-8 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:28:43 -0000 On 17 July 2013 12:10, Rosen, Brian wrote: > I would like all queries to start at the local server, and allow that server > to recurse, if it prefers to, regardless of the attribute. Isn't it always possible for a server to decide to recurse, regardless of what the client and some moldy RFC says? Maybe you can write an update to said moldy RFC and we can all rubber-stamp it. What you describe is a reasonable operational practice. At one point, we talked about cases where the higher level LoST servers wouldn't even be accessible from the public Internet, always requiring intermediated access from known "proxy" servers. From khwolf1@gmail.com Mon Jul 22 02:08:28 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA8421E80B5 for ; Mon, 22 Jul 2013 02:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKd2XL52pNfm for ; Mon, 22 Jul 2013 02:08:16 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id AC73E21F8411 for ; Mon, 22 Jul 2013 01:56:03 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf10so253295vcb.12 for ; Mon, 22 Jul 2013 01:55:27 -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=e8qkXBBJ4kh6mXoKka7ejeYDg9F60xIB/vzkpb62bw8=; b=1EcRybpGynGzG/B+lIgyETZzsVhA2gTocV4kXoxrGB8iMBJOB5VOsWaUfGPiw68qDc 4NwgUZaVqgUwMQslwZVM1yCIr7c6E0jmB9GqT9Eem0FcCKGIDPokbMgFrpOrTgM4V9/2 yHA0Ei6Fb50lzFyMypDFj4NNgQDDN9xOANiLLqAUNAOlR7xTGl9WXC+YQYp39dekjX7U weEm1XXX7xUeDDL3awzNYo9fezmHqFwEo/25PyDAUKM55Pe0nAg8n0cVTsM9t7cuvZ/X 4MrADi/Pf9OfOCpecm/yjDTT0tvI4Icwlzan0IZo0UCqiWlwI8PtCn/RPsW45bdLofGU xQGg== MIME-Version: 1.0 X-Received: by 10.52.92.240 with SMTP id cp16mr7398572vdb.80.1374483326859; Mon, 22 Jul 2013 01:55:26 -0700 (PDT) Received: by 10.220.173.5 with HTTP; Mon, 22 Jul 2013 01:55:26 -0700 (PDT) In-Reply-To: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> References: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> Date: Mon, 22 Jul 2013 10:55:26 +0200 Message-ID: From: Karl Heinz Wolf To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=20cf307f39c072b3d104e215d602 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 09:08:28 -0000 --20cf307f39c072b3d104e215d602 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian wrot= e: > > This means that the national forest guide must be prepared to answer > queries from any device at any time. In particular, it has to be sized f= or > the worst case scenario where a very large number of devices make request= s > of it, and it cannot refuse a request from any source (as a practical > matter). This makes it a very attractive DDoS target. In fact, I would > argue that a great number of implementations will simply start all querie= s > at the top of the tree in all cases, since the forest guide URI will beco= me > well known quickly. > Brian, I got a bit confused here and I probably missed the discussion on the issue. However, the mapping architecture in RFC 5582 describes that a seeker queries a resolver, the resolver consults a forest guide and then goes to the root of the appropriate tree. So I don=92t see how the RFC5582 architecture should work without the forest guide URI to be known by resolvers. Moreover, since the forest guide points to the root of the tree, the query has to start at the root. Or are you talking about some private LoST deployments inside the NENA network where some other mechanisms and architectures apply? Best, Karl --20cf307f39c072b3d104e215d602 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:

This means that the national forest guide must be prepared to answer q= ueries from any device at any time. =A0In particular, it has to be sized fo= r the worst case scenario where a very large number of devices make request= s of it, and it cannot refuse a request from any source (as a practical matter). =A0This makes it a very attractiv= e DDoS target. =A0In fact, I would argue that a great number of implementat= ions will simply start all queries at the top of the tree in all cases, sin= ce the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I = probably missed the discussion on the issue. However, the mapping architect= ure in RFC 5582 describes that a seeker queries a resolver, the resolver co= nsults a forest guide and then goes to the root of the appropriate tree. So= I don=92t see how the RFC5582 architecture should work without the forest = guide URI to be known by resolvers. Moreover, since the forest guide points= to the root of the tree, the query has to start at the root. Or are you ta= lking about some private LoST deployments inside the NENA network where som= e other mechanisms and architectures apply?

Best,
Karl

--20cf307f39c072b3d104e215d602-- From brian.rosen@neustar.biz Mon Jul 22 08:02:46 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D52111E80F2 for ; Mon, 22 Jul 2013 08:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVG+Klr1ycKm for ; Mon, 22 Jul 2013 08:02:41 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9CF11E810F for ; Mon, 22 Jul 2013 08:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374505862; x=1689863342; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=JSp6wgUrrv2yhCu4rRYdXqsoRS6bwTgXcK00ve5T3Lc=; b=K8W6l8xZRjdPwcPKl+tLObfOGFeqDU21ecNl6yCdNmv0yD7nt9dHeSpRpjeqrc vqm86xxOgrOUeuBbt/oOepQg== Received: from ([10.31.58.70]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.28453431; Mon, 22 Jul 2013 11:11:01 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 22 Jul 2013 11:02:25 -0400 From: "Rosen, Brian" To: Karl Heinz Wolf Thread-Topic: [Ecrit] LoST recursion and Forest Guides Thread-Index: AQHOgyFJU8ETq0n8JkKNvkzlp5DbOw== Date: Mon, 22 Jul 2013 15:02:24 +0000 Message-ID: References: <280B2BB7-471B-4539-A269-74FEAB469C95@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.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: pso/O2A5IbQWCa5llt7YGQ== Content-Type: multipart/alternative; boundary="_000_AB1B0B96B2D946509B96D770EAC3FF37neustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:02:46 -0000 --_000_AB1B0B96B2D946509B96D770EAC3FF37neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I want to have LoST discovery find a local LoST server, which nearly always= has the answer you want. No FG, no real resolvers. If the local LoST server doesn't have the answer, then we get to the forest= . If your local LoST server doesn't have the answer, it's next most likely= that you need some adjacent server. So walk up the tree a level and find = it. If something is broken, like the seeker for some reason isn't actually loca= l, then you might need to go all the way up to the root of the tree, and ac= ross (using the FG), and down another tree. This should be really rare, bu= t it can happen. Each server in the tree knows the leaves below (coverage and URI) so it can= recurse or iterate down, and it knows the URI of the next level up so it c= an recurse or iterate up the tree. That has to work, or the FG would have = a zillion one level trees. It doesn't, so the trees have intermediate serv= ers that know about the leaves at their level, and can recure/iterate up. I don't want to see devices start at the FG always. That would mean that t= he FG is in the path of every emergency call (ignoring caching, which obvio= usly helps a lot). That's not a good design. Stay local, and use the fore= st only when you have to go out of area for some reason. Brian On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf > wrote: On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian > wrote: This means that the national forest guide must be prepared to answer querie= s from any device at any time. In particular, it has to be sized for the w= orst case scenario where a very large number of devices make requests of it= , and it cannot refuse a request from any source (as a practical matter). = This makes it a very attractive DDoS target. In fact, I would argue that a= great number of implementations will simply start all queries at the top o= f the tree in all cases, since the forest guide URI will become well known = quickly. Brian, I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture= should work without the forest guide URI to be known by resolvers. Moreove= r, since the forest guide points to the root of the tree, the query has to = start at the root. Or are you talking about some private LoST deployments i= nside the NENA network where some other mechanisms and architectures apply? Best, Karl _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_AB1B0B96B2D946509B96D770EAC3FF37neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <15A8FD2666E71B4A89583BFDD6E946F3@neustar.biz> Content-Transfer-Encoding: quoted-printable
I want to have LoST discovery find a local LoST server, which nearly a= lways has the answer you want.  No FG, no real resolvers.

If the local LoST server doesn't have the answer, then we get to the f= orest.  If your local LoST server doesn't have the answer, it's next m= ost likely that you need some adjacent server.  So walk up the tree a = level and find it.

If something is broken, like the seeker for some reason isn't actually= local, then you might need to go all the way up to the root of the tree, a= nd across (using the FG), and down another tree.  This should be reall= y rare, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so i= t can recurse or iterate down, and it knows the URI of the next level up so= it can recurse or iterate up the tree.  That has to work, or the FG w= ould have a zillion one level trees.  It doesn't, so the trees have intermediate servers that know about t= he leaves at their level, and can recure/iterate up.  

I don't want to see devices start at the FG always.  That would m= ean that the FG is in the path of every emergency call (ignoring caching, w= hich obviously helps a lot).  That's not a good design.  Stay loc= al, and use the forest only when you have to go out of area for some reason.

Brian



On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

This means that the national forest guide must be prepared to answer q= ueries from any device at any time.  In particular, it has to be sized= for the worst case scenario where a very large number of devices make requ= ests of it, and it cannot refuse a request from any source (as a practical matter).  This makes it a very attrac= tive DDoS target.  In fact, I would argue that a great number of imple= mentations will simply start all queries at the top of the tree in all case= s, since the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture should work without the forest = guide URI to be known by resolvers. Moreover, since the forest guide points= to the root of the tree, the query has to start at the root. Or are you ta= lking about some private LoST deployments inside the NENA network where some other mechanisms and architectures appl= y?

Best,
Karl

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

--_000_AB1B0B96B2D946509B96D770EAC3FF37neustarbiz_-- From khwolf1@gmail.com Tue Jul 23 00:04:24 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BD211E80D1 for ; Tue, 23 Jul 2013 00:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-rK5n1-Uh9d for ; Tue, 23 Jul 2013 00:04:23 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id F0BE811E8103 for ; Tue, 23 Jul 2013 00:04:16 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w15so5198673vbf.21 for ; Tue, 23 Jul 2013 00:04:15 -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=1QA9sGryuccQnK59nCXzYi4aE/EkAL8J//QRuFN5eis=; b=tDorArr4ztCtsTGfL/zVuALZ2XtCoIlVNevlHRuMVmSbZptKN/wcletNUlDPB+LrB6 UbwudkZroiAVtZ9MnK8e1RbOet4wbF2GXy5yDriTiAWCJnOGrOECq5WJQedgchMdcJdE OPnzOqk6VO95g39JV+OFp20ycEMqJTQd3ew4pF9wy1VY7bkN22oXLCMb05IdX/xmYliu o7vhAWFgnQJryX/hOR8zFM2uiOQd3oRdswLhZ9wLk9kKQYXSGp9gGMG4hN7LhC1RoNHE 6rXXfn1QdhJoxyYxvEEtHYx2w2CcrlXlqxM91JcfsBg11jhvTkmOmrPYOg0Fbo6yeFjT OqoA== MIME-Version: 1.0 X-Received: by 10.52.164.83 with SMTP id yo19mr564401vdb.62.1374563054421; Tue, 23 Jul 2013 00:04:14 -0700 (PDT) Received: by 10.220.173.5 with HTTP; Tue, 23 Jul 2013 00:04:14 -0700 (PDT) In-Reply-To: References: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> Date: Tue, 23 Jul 2013 09:04:14 +0200 Message-ID: From: Karl Heinz Wolf To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=001a11c21850948f8504e2286696 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 07:04:24 -0000 --001a11c21850948f8504e2286696 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian wrot= e: > I want to have LoST discovery find a local LoST server, which nearly > always has the answer you want. No FG, no real resolvers. > Brian, thanks for your answer. So this local LoST server would then be a LoST mapping server for a specific reagion and a particular service (e.g. urn:service:sos), do I understand this correctly? Then the client would have to discover a real LoST resolver as well which it has to consult for other services. If the local LoST server doesn't have the answer, then we get to the > forest. If your local LoST server doesn't have the answer, it's next mos= t > likely that you need some adjacent server. So walk up the tree a level a= nd > find it. > > If something is broken, like the seeker for some reason isn't actually > local, then you might need to go all the way up to the root of the tree, > and across (using the FG), and down another tree. This should be really > rare, but it can happen. > > Each server in the tree knows the leaves below (coverage and URI) so it > can recurse or iterate down, and it knows the URI of the next level up so > it can recurse or iterate up the tree. That has to work, or the FG would > have a zillion one level trees. It doesn't, so the trees have intermedia= te > servers that know about the leaves at their level, and can recure/iterate > up. > > I don't want to see devices start at the FG always. That would mean > that the FG is in the path of every emergency call (ignoring caching, whi= ch > obviously helps a lot). That's not a good design. Stay local, and use t= he > forest only when you have to go out of area for some reason. > Does this mean the architecture of RFC 5582 is going to be updaded? After all, this architecture is along the lines of the DNS system, where queries would also always start at the DNS root servers when ignoring caching. Best, Karl > > > On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf wrote: > > On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian = wrote: > >> >> This means that the national forest guide must be prepared to answer >> queries from any device at any time. In particular, it has to be sized = for >> the worst case scenario where a very large number of devices make reques= ts >> of it, and it cannot refuse a request from any source (as a practical >> matter). This makes it a very attractive DDoS target. In fact, I would >> argue that a great number of implementations will simply start all queri= es >> at the top of the tree in all cases, since the forest guide URI will bec= ome >> well known quickly. >> > > Brian, > > I got a bit confused here and I probably missed the discussion on the > issue. However, the mapping architecture in RFC 5582 describes that a > seeker queries a resolver, the resolver consults a forest guide and then > goes to the root of the appropriate tree. So I don=92t see how the RFC558= 2 > architecture should work without the forest guide URI to be known by > resolvers. Moreover, since the forest guide points to the root of the tre= e, > the query has to start at the root. Or are you talking about some private > LoST deployments inside the NENA network where some other mechanisms and > architectures apply? > > Best, > Karl > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > --001a11c21850948f8504e2286696 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 22, 2013 at 5:02 PM, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:
I want to have LoST discovery find a local LoST server, which nearly a= lways has the answer you want. =A0No FG, no real resolvers.
=A0
Brian, thanks for your answer. So= this local LoST server would then be a LoST mapping server for a specific = reagion and a particular service (e.g. urn:service:sos), do I understand th= is correctly? Then the client would have to discover a real LoST resolver a= s well which it has to consult for other services.

If the local LoST server doesn't have the answer, then we get to t= he forest. =A0If your local LoST server doesn't have the answer, it'= ;s next most likely that you need some adjacent server. =A0So walk up the t= ree a level and find it.

If something is broken, like the seeker for some reason isn't actu= ally local, then you might need to go all the way up to the root of the tre= e, and across (using the FG), and down another tree. =A0This should be real= ly rare, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so i= t can recurse or iterate down, and it knows the URI of the next level up so= it can recurse or iterate up the tree. =A0That has to work, or the FG woul= d have a zillion one level trees. =A0It doesn't, so the trees have intermediate servers that know about = the leaves at their level, and can recure/iterate up. =A0

I don't want to see devices start at the FG always. =A0That would = mean that the FG is in the path of every emergency call (ignoring caching, = which obviously helps a lot). =A0That's not a good design. =A0Stay loca= l, and use the forest only when you have to go out of area for some reason.

Does this mean the arc= hitecture of RFC 5582 is going to be updaded? After all, this architecture = is along the lines of the DNS system, where queries would also always start= at the DNS root servers when ignoring caching.

Best,
Karl

=A0


On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

This means that the national forest guide must be prepared to answer q= ueries from any device at any time. =A0In particular, it has to be sized fo= r the worst case scenario where a very large number of devices make request= s of it, and it cannot refuse a request from any source (as a practical matter). =A0This makes it a very attractiv= e DDoS target. =A0In fact, I would argue that a great number of implementat= ions will simply start all queries at the top of the tree in all cases, sin= ce the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture should work without the forest = guide URI to be known by resolvers. Moreover, since the forest guide points= to the root of the tree, the query has to start at the root. Or are you ta= lking about some private LoST deployments inside the NENA network where some other mechanisms and architectures appl= y?

Best,
Karl

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


--001a11c21850948f8504e2286696-- From brian.rosen@neustar.biz Tue Jul 23 05:45:45 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EDC11E80FD for ; Tue, 23 Jul 2013 05:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XHZme0M3UZ4 for ; Tue, 23 Jul 2013 05:45:41 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 22C4911E80CC for ; Tue, 23 Jul 2013 05:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374584086; x=1689923001; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=FHu++qvawIixHcy4tOpD12her8GrwaPB2UUXOZaztBM=; b=iL6PlKQR2ySoWDTWjKe90bpCHt3PzGxF7p8RZZMMaZ3QTy3Lwd+cclMs73CkNW s7WjBdQrbB8S7+G0Dj6o0pzQ== Received: from ([10.31.58.69]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.28515310; Tue, 23 Jul 2013 08:54:43 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Tue, 23 Jul 2013 08:45:35 -0400 From: "Rosen, Brian" To: Karl Heinz Wolf Thread-Topic: [Ecrit] LoST recursion and Forest Guides Thread-Index: AQHOgyFJU8ETq0n8JkKNvkzlp5DbOw== Date: Tue, 23 Jul 2013 12:45:34 +0000 Message-ID: <3E394609-851B-40C4-B499-D5024859147D@neustar.biz> References: <280B2BB7-471B-4539-A269-74FEAB469C95@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.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: EEeG20++MEuyJP2aTdY2tQ== Content-Type: multipart/alternative; boundary="_000_3E394609851B40C4B499D5024859147Dneustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 12:45:45 -0000 --_000_3E394609851B40C4B499D5024859147Dneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If the local server didn't have the answer it could recur or iterate up the= tree. The client would never have to discover a resolver, the local serve= r becomes one. Brian On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf > wrote: On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian > wrote: I want to have LoST discovery find a local LoST server, which nearly always= has the answer you want. No FG, no real resolvers. Brian, thanks for your answer. So this local LoST server would then be a Lo= ST mapping server for a specific reagion and a particular service (e.g. urn= :service:sos), do I understand this correctly? Then the client would have t= o discover a real LoST resolver as well which it has to consult for other s= ervices. If the local LoST server doesn't have the answer, then we get to the forest= . If your local LoST server doesn't have the answer, it's next most likely= that you need some adjacent server. So walk up the tree a level and find = it. If something is broken, like the seeker for some reason isn't actually loca= l, then you might need to go all the way up to the root of the tree, and ac= ross (using the FG), and down another tree. This should be really rare, bu= t it can happen. Each server in the tree knows the leaves below (coverage and URI) so it can= recurse or iterate down, and it knows the URI of the next level up so it c= an recurse or iterate up the tree. That has to work, or the FG would have = a zillion one level trees. It doesn't, so the trees have intermediate serv= ers that know about the leaves at their level, and can recure/iterate up. I don't want to see devices start at the FG always. That would mean that t= he FG is in the path of every emergency call (ignoring caching, which obvio= usly helps a lot). That's not a good design. Stay local, and use the fore= st only when you have to go out of area for some reason. Does this mean the architecture of RFC 5582 is going to be updaded? After a= ll, this architecture is along the lines of the DNS system, where queries w= ould also always start at the DNS root servers when ignoring caching. Best, Karl On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf > wrote: On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian > wrote: This means that the national forest guide must be prepared to answer querie= s from any device at any time. In particular, it has to be sized for the w= orst case scenario where a very large number of devices make requests of it= , and it cannot refuse a request from any source (as a practical matter). = This makes it a very attractive DDoS target. In fact, I would argue that a= great number of implementations will simply start all queries at the top o= f the tree in all cases, since the forest guide URI will become well known = quickly. Brian, I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture= should work without the forest guide URI to be known by resolvers. Moreove= r, since the forest guide points to the root of the tree, the query has to = start at the root. Or are you talking about some private LoST deployments i= nside the NENA network where some other mechanisms and architectures apply? Best, Karl _______________________________________________ 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 --_000_3E394609851B40C4B499D5024859147Dneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <894DB2771AC33E43912DCA830847AD45@neustar.biz> Content-Transfer-Encoding: quoted-printable If the local server didn't have the answer it could recur or iterate up the= tree.  The client would never have to discover a resolver, the local = server becomes one.

Brian

On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
I want to have LoST discovery find a local LoST server, which nearly a= lways has the answer you want.  No FG, no real resolvers.
 
Brian, thanks for your answer. So this local LoST server would then be= a LoST mapping server for a specific reagion and a particular service (e.g= . urn:service:sos), do I understand this correctly? Then the client would h= ave to discover a real LoST resolver as well which it has to consult for other services.

If the local LoST server doesn't have the answer, then we get to the f= orest.  If your local LoST server doesn't have the answer, it's next m= ost likely that you need some adjacent server.  So walk up the tree a = level and find it.

If something is broken, like the seeker for some reason isn't actually= local, then you might need to go all the way up to the root of the tree, a= nd across (using the FG), and down another tree.  This should be reall= y rare, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so i= t can recurse or iterate down, and it knows the URI of the next level up so= it can recurse or iterate up the tree.  That has to work, or the FG w= ould have a zillion one level trees.  It doesn't, so the trees have intermediate servers that know about t= he leaves at their level, and can recure/iterate up.  

I don't want to see devices start at the FG always.  That would m= ean that the FG is in the path of every emergency call (ignoring caching, w= hich obviously helps a lot).  That's not a good design.  Stay loc= al, and use the forest only when you have to go out of area for some reason.

Does this mean the architecture of RFC 5582 is going to be updaded? Af= ter all, this architecture is along the lines of the DNS system, where quer= ies would also always start at the DNS root servers when ignoring caching.

Best,
Karl

 

On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

This means that the national forest guide must be prepared to answer q= ueries from any device at any time.  In particular, it has to be sized= for the worst case scenario where a very large number of devices make requ= ests of it, and it cannot refuse a request from any source (as a practical matter).  This makes it a very attrac= tive DDoS target.  In fact, I would argue that a great number of imple= mentations will simply start all queries at the top of the tree in all case= s, since the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture should work without the forest = guide URI to be known by resolvers. Moreover, since the forest guide points= to the root of the tree, the query has to start at the root. Or are you ta= lking about some private LoST deployments inside the NENA network where some other mechanisms and architectures appl= y?

Best,
Karl

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


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

--_000_3E394609851B40C4B499D5024859147Dneustarbiz_-- From khwolf1@gmail.com Tue Jul 23 23:46:49 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC58B11E8393 for ; Tue, 23 Jul 2013 23:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDVAH5M8WbAx for ; Tue, 23 Jul 2013 23:46:48 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B5A7A11E81CC for ; Tue, 23 Jul 2013 23:46:48 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l10so72443oag.3 for ; Tue, 23 Jul 2013 23:46:47 -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=tQQ5pv8/RCcsj7lR3cZa6zp0/pJlW23ULBR1Sv/WqPE=; b=hMSK9sdYJ3n3b1hz1udTct3kz3s+Zwojmfx6HcrfqaSVxmjoB9PKwTkWtp8XZxxeVF XQRqkXmzwYJyVhzrtk3EORxon25cEALX/QLgfhc6l7aoSOwPwopi/jwnEOvW6HRiQBVs j1qOHXBChA8ocHZv0TqXxRm0TntkPachoxm6Ce3wZHEIgEW9H4XXZ8GDJdPHmSM174Qr 9w5i6lhgct+7oVWq1o0A824WGdAHzFinenQ/3Wcy1TJ9sCEFiQ91VnD7hbHhAsw7Zo8R 8H2HxSNApAViAFn8zgA8PxyMKIlVmOuvYyb+XhtZfaXHbcEfyfSo/zx+nVxJcpuIhvT1 sdkg== MIME-Version: 1.0 X-Received: by 10.182.27.41 with SMTP id q9mr4609837obg.66.1374648407870; Tue, 23 Jul 2013 23:46:47 -0700 (PDT) Received: by 10.76.18.39 with HTTP; Tue, 23 Jul 2013 23:46:47 -0700 (PDT) In-Reply-To: <3E394609-851B-40C4-B499-D5024859147D@neustar.biz> References: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> <3E394609-851B-40C4-B499-D5024859147D@neustar.biz> Date: Wed, 24 Jul 2013 08:46:47 +0200 Message-ID: From: Karl Heinz Wolf To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=089e011762390ad29c04e23c46f0 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 06:46:50 -0000 --089e011762390ad29c04e23c46f0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian wrot= e: > > If the local server didn't have the answer it could recur or iterate up > the tree. The client would never have to discover a resolver, the local > server becomes one. > Brian, so you suggest that all queries go to a local LoST server, consequently the urn:service:sos tree would be bothered for each query, also for urn:service:foo, which iterates up the urn:service:sos tree, until reaching the forest guide that is able to tell the tree for service foo? When you say that the local lost server becomes a resolver, I wonder what ist the advantage of discovering a local LoST server? A resolver will verly likely have the responses of all the "local" services in its cache (urn:service:sos as well as any other), and all the other queries can be directed to the right tree via forest guides, without bothering the urn:service:sos tree at all. Best, Karl > On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf wrote: > > On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian = wrote: > >> I want to have LoST discovery find a local LoST server, which nearly >> always has the answer you want. No FG, no real resolvers. >> > > Brian, thanks for your answer. So this local LoST server would then be a > LoST mapping server for a specific reagion and a particular service (e.g. > urn:service:sos), do I understand this correctly? Then the client would > have to discover a real LoST resolver as well which it has to consult for > other services. > > If the local LoST server doesn't have the answer, then we get to the >> forest. If your local LoST server doesn't have the answer, it's next mo= st >> likely that you need some adjacent server. So walk up the tree a level = and >> find it. >> >> If something is broken, like the seeker for some reason isn't actually >> local, then you might need to go all the way up to the root of the tree, >> and across (using the FG), and down another tree. This should be really >> rare, but it can happen. >> >> Each server in the tree knows the leaves below (coverage and URI) so it >> can recurse or iterate down, and it knows the URI of the next level up s= o >> it can recurse or iterate up the tree. That has to work, or the FG woul= d >> have a zillion one level trees. It doesn't, so the trees have intermedi= ate >> servers that know about the leaves at their level, and can recure/iterat= e >> up. >> >> I don't want to see devices start at the FG always. That would mean >> that the FG is in the path of every emergency call (ignoring caching, wh= ich >> obviously helps a lot). That's not a good design. Stay local, and use = the >> forest only when you have to go out of area for some reason. >> > > Does this mean the architecture of RFC 5582 is going to be updaded? > After all, this architecture is along the lines of the DNS system, where > queries would also always start at the DNS root servers when ignoring > caching. > > Best, > Karl > > > >> >> >> On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf wrote= : >> >> On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian < >> Brian.Rosen@neustar.biz> wrote: >> >>> >>> This means that the national forest guide must be prepared to answer >>> queries from any device at any time. In particular, it has to be sized= for >>> the worst case scenario where a very large number of devices make reque= sts >>> of it, and it cannot refuse a request from any source (as a practical >>> matter). This makes it a very attractive DDoS target. In fact, I woul= d >>> argue that a great number of implementations will simply start all quer= ies >>> at the top of the tree in all cases, since the forest guide URI will be= come >>> well known quickly. >>> >> >> Brian, >> >> I got a bit confused here and I probably missed the discussion on the >> issue. However, the mapping architecture in RFC 5582 describes that a >> seeker queries a resolver, the resolver consults a forest guide and then >> goes to the root of the appropriate tree. So I don=92t see how the RFC55= 82 >> architecture should work without the forest guide URI to be known by >> resolvers. Moreover, since the forest guide points to the root of the tr= ee, >> the query has to start at the root. Or are you talking about some privat= e >> LoST deployments inside the NENA network where some other mechanisms and >> architectures apply? >> >> Best, >> Karl >> >> _______________________________________________ >> 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 > > > --089e011762390ad29c04e23c46f0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:

 If the local server didn't have the answer it could recur or iterate up= the tree. =A0The client would never have to discover a resolver, the local= server becomes one.=A0

Brian,

<= div>so you suggest that all queries go to a local LoST server, consequently= the urn:service:sos tree would be bothered for each query, also for urn:se= rvice:foo, which iterates up the urn:service:sos tree, until reaching the f= orest guide that is able to tell the tree for service foo?





On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
I want to have LoST discovery find a local LoST server, which nearly a= lways has the answer you want. =A0No FG, no real resolvers.
=A0
Brian, thanks for your answer. So this local LoST server would then be= a LoST mapping server for a specific reagion and a particular service (e.g= . urn:service:sos), do I understand this correctly? Then the client would h= ave to discover a real LoST resolver as well which it has to consult for other services.

If the local LoST server doesn't have the answer, then we get to t= he forest. =A0If your local LoST server doesn't have the answer, it'= ;s next most likely that you need some adjacent server. =A0So walk up the t= ree a level and find it.

If something is broken, like the seeker for some reason isn't actu= ally local, then you might need to go all the way up to the root of the tre= e, and across (using the FG), and down another tree. =A0This should be real= ly rare, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so i= t can recurse or iterate down, and it knows the URI of the next level up so= it can recurse or iterate up the tree. =A0That has to work, or the FG woul= d have a zillion one level trees. =A0It doesn't, so the trees have intermediate servers that know about = the leaves at their level, and can recure/iterate up. =A0

I don't want to see devices start at the FG always. =A0That would = mean that the FG is in the path of every emergency call (ignoring caching, = which obviously helps a lot). =A0That's not a good design. =A0Stay loca= l, and use the forest only when you have to go out of area for some reason.

Does this mean the architecture of RFC 5582 is going to be updaded? Af= ter all, this architecture is along the lines of the DNS system, where quer= ies would also always start at the DNS root servers when ignoring caching.

Best,
Karl

=A0

On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

This means that the national forest guide must be prepared to answer q= ueries from any device at any time. =A0In particular, it has to be sized fo= r the worst case scenario where a very large number of devices make request= s of it, and it cannot refuse a request from any source (as a practical matter). =A0This makes it a very attractiv= e DDoS target. =A0In fact, I would argue that a great number of implementat= ions will simply start all queries at the top of the tree in all cases, sin= ce the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture should work without the forest = guide URI to be known by resolvers. Moreover, since the forest guide points= to the root of the tree, the query has to start at the root. Or are you ta= lking about some private LoST deployments inside the NENA network where some other mechanisms and architectures appl= y?

Best,
Karl

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


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


--089e011762390ad29c04e23c46f0-- From a.james.winterbottom@gmail.com Wed Jul 24 01:22:28 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C17411E83A0 for ; Wed, 24 Jul 2013 01:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDqu-m19nmOj for ; Wed, 24 Jul 2013 01:22:27 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBA911E83B2 for ; Wed, 24 Jul 2013 01:22:21 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so9382669pbc.11 for ; Wed, 24 Jul 2013 01:22:14 -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:x-mailer:from:subject:date :to; bh=Pz8j8Hi/rDp2ijvSR212IAsUNsg4OiZuoZ4wP7Iuc/4=; b=PaBhUFhDzXH0tyBmL5a9qCG+EfwLl0Z6rehnu+GdvRmyHRisf19+93OknKE5xuheYt iY6epntxyYDMP5gP20U7i/x15O9XHRn4dYMkZsRnQfKFs9eCHC/iumq9Rma5id02jh2W Sj03xh3oHznLeUnN04vqnBcHjqTI6D6X2yNpJy9YO/c5nLQpZ5cFJMBH3aoQ+nOOQA6y FpPM3jyplLhYfSFmT1uARJs6F3UwGwGor/Jk79Wcn4Tu0C1ohPGuBdjx2jMW68W9Tezs yINJOeYoaOEvWrqOg+D4cJs081VmMmeL3veh4PkO0usLo+e42Ec3JfAyJV98MW/MNfqB iwPg== X-Received: by 10.66.139.167 with SMTP id qz7mr41534506pab.157.1374654134299; Wed, 24 Jul 2013 01:22:14 -0700 (PDT) Received: from [192.168.1.14] (202-159-153-217.dyn.iinet.net.au. [202.159.153.217]) by mx.google.com with ESMTPSA id sz3sm18154813pbc.5.2013.07.24.01.22.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 01:22:13 -0700 (PDT) References: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> <3E394609-851B-40C4-B499-D5024859147D@neustar.biz> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-628283C0-0387-438A-8C1C-58D11600DA35 Content-Transfer-Encoding: 7bit Message-Id: <2E8BFE37-2652-48A5-9CF3-5DE0D13CEF8C@gmail.com> X-Mailer: iPad Mail (10A523) From: James Winterbottom Date: Wed, 24 Jul 2013 18:22:09 +1000 To: Karl Heinz Wolf Cc: "Rosen, Brian" , "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:22:28 -0000 --Apple-Mail-628283C0-0387-438A-8C1C-58D11600DA35 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My problem with this approach is that discovery mechanisms are domain name d= riven and this kind of means that local is domain local and not necessarily p= hysically local so I am unclear on how to configure my network to make what i= s being proposed happen. Cheers James Sent from my iPad On 24/07/2013, at 4:46 PM, Karl Heinz Wolf wrote: > On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian wr= ote: >>=20 >> If the local server didn't have the answer it could recur or iterate up t= he tree. The client would never have to discover a resolver, the local serv= er becomes one.=20 >=20 > Brian, >=20 > so you suggest that all queries go to a local LoST server, consequently th= e urn:service:sos tree would be bothered for each query, also for urn:servic= e:foo, which iterates up the urn:service:sos tree, until reaching the forest= guide that is able to tell the tree for service foo?=20 >=20 > When you say that the local lost server becomes a resolver, I wonder what i= st the advantage of discovering a local LoST server? A resolver will verly l= ikely have the responses of all the "local" services in its cache (urn:servi= ce:sos as well as any other), and all the other queries can be directed to t= he right tree via forest guides, without bothering the urn:service:sos tree a= t all.=20 >=20 > Best, > Karl=20 >=20 >>=20 >> On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf wrote: >>=20 >>> On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian w= rote: >>>> I want to have LoST discovery find a local LoST server, which nearly al= ways has the answer you want. No FG, no real resolvers. >>> =20 >>> Brian, thanks for your answer. So this local LoST server would then be a= LoST mapping server for a specific reagion and a particular service (e.g. u= rn:service:sos), do I understand this correctly? Then the client would have t= o discover a real LoST resolver as well which it has to consult for other se= rvices. >>>=20 >>>> If the local LoST server doesn't have the answer, then we get to the fo= rest. If your local LoST server doesn't have the answer, it's next most lik= ely that you need some adjacent server. So walk up the tree a level and fin= d it. >>>>=20 >>>> If something is broken, like the seeker for some reason isn't actually l= ocal, then you might need to go all the way up to the root of the tree, and a= cross (using the FG), and down another tree. This should be really rare, bu= t it can happen. >>>>=20 >>>> Each server in the tree knows the leaves below (coverage and URI) so it= can recurse or iterate down, and it knows the URI of the next level up so i= t can recurse or iterate up the tree. That has to work, or the FG would hav= e a zillion one level trees. It doesn't, so the trees have intermediate ser= vers that know about the leaves at their level, and can recure/iterate up. =20= >>>>=20 >>>> I don't want to see devices start at the FG always. That would mean th= at the FG is in the path of every emergency call (ignoring caching, which ob= viously helps a lot). That's not a good design. Stay local, and use the fo= rest only when you have to go out of area for some reason. >>>=20 >>> Does this mean the architecture of RFC 5582 is going to be updaded? Afte= r all, this architecture is along the lines of the DNS system, where queries= would also always start at the DNS root servers when ignoring caching.=20 >>>=20 >>> Best, >>> Karl >>>=20 >>> =20 >>>>=20 >>>>=20 >>>> On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf wrote:= >>>>=20 >>>>> On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian wrote: >>>>>>=20 >>>>>> This means that the national forest guide must be prepared to answer q= ueries from any device at any time. In particular, it has to be sized for t= he worst case scenario where a very large number of devices make requests of= it, and it cannot refuse a request from any source (as a practical matter).= This makes it a very attractive DDoS target. In fact, I would argue that a= great number of implementations will simply start all queries at the top of= the tree in all cases, since the forest guide URI will become well known qu= ickly. >>>>>=20 >>>>> Brian, >>>>>=20 >>>>> I got a bit confused here and I probably missed the discussion on the i= ssue. However, the mapping architecture in RFC 5582 describes that a seeker q= ueries a resolver, the resolver consults a forest guide and then goes to the= root of the appropriate tree. So I don=E2=80=99t see how the RFC5582 archit= ecture should work without the forest guide URI to be known by resolvers. Mo= reover, since the forest guide points to the root of the tree, the query has= to start at the root. Or are you talking about some private LoST deployment= s inside the NENA network where some other mechanisms and architectures appl= y?=20 >>>>>=20 >>>>> Best, >>>>> Karl >>>>>=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 --Apple-Mail-628283C0-0387-438A-8C1C-58D11600DA35 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
My problem with this approach is that d= iscovery mechanisms are domain name driven and this kind of means that local= is domain local and not necessarily physically local so I am unclear on how= to configure my network to make what is being proposed happen.
Cheers
James

Sent from my iPad

O= n 24/07/2013, at 4:46 PM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <Brian.Rosen@neustar.= biz> wrote:

 If the local server didn't have the answer it could recur or iterate up the t= ree.  The client would never have to discover a resolver, the local ser= ver becomes one. 

Brian,

so you suggest that all queries go to a local LoST server, consequently t= he urn:service:sos tree would be bothered for each query, also for urn:servi= ce:foo, which iterates up the urn:service:sos tree, until reaching the fores= t guide that is able to tell the tree for service foo?

When you say that the local lost server becomes a r= esolver, I wonder what ist the advantage of discovering a local LoST server?= A resolver will verly likely have the responses of all the "local" services= in its cache (urn:service:sos as well as any other), and all the other quer= ies can be directed to the right tree via forest guides, without bothering t= he urn:service:sos tree at all.

Best,
Karl


On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <Brian.Rosen= @neustar.biz> wrote:
I want to have LoST discovery find a local LoST server, which nearly al= ways has the answer you want.  No FG, no real resolvers.
 
Brian, thanks for your answer. So this local LoST server would then be a= LoST mapping server for a specific reagion and a particular service (e.g. u= rn:service:sos), do I understand this correctly? Then the client would have t= o discover a real LoST resolver as well which it has to consult for other services.

If the local LoST server doesn't have the answer, then we get to the fo= rest.  If your local LoST server doesn't have the answer, it's next mos= t likely that you need some adjacent server.  So walk up the tree a lev= el and find it.

If something is broken, like the seeker for some reason isn't actually l= ocal, then you might need to go all the way up to the root of the tree, and a= cross (using the FG), and down another tree.  This should be really rar= e, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so it= can recurse or iterate down, and it knows the URI of the next level up so i= t can recurse or iterate up the tree.  That has to work, or the FG woul= d have a zillion one level trees.  It doesn't, so the trees have intermediate servers that know about th= e leaves at their level, and can recure/iterate up.  

I don't want to see devices start at the FG always.  That would me= an that the FG is in the path of every emergency call (ignoring caching, whi= ch obviously helps a lot).  That's not a good design.  Stay local,= and use the forest only when you have to go out of area for some reason.

Does this mean the architecture of RFC 5582 is going to be updaded? Aft= er all, this architecture is along the lines of the DNS system, where querie= s would also always start at the DNS root servers when ignoring caching.

Best,
Karl

 

On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rosen= @neustar.biz> wrote:

This means that the national forest guide must be prepared to answer qu= eries from any device at any time.  In particular, it has to be sized f= or the worst case scenario where a very large number of devices make request= s of it, and it cannot refuse a request from any source (as a practical matter).  This makes it a very attract= ive DDoS target.  In fact, I would argue that a great number of impleme= ntations will simply start all queries at the top of the tree in all cases, s= ince the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I probably missed the discussion on the issue.= However, the mapping architecture in RFC 5582 describes that a seeker queri= es a resolver, the resolver consults a forest guide and then goes to the roo= t of the appropriate tree. So I don=E2=80=99t see how the RFC5582 architecture should work without the fo= rest guide URI to be known by resolvers. Moreover, since the forest guide po= ints to the root of the tree, the query has to start at the root. Or are you= talking about some private LoST deployments inside the NENA network where some other mechanisms and architectures apply= ?

Best,
Karl

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


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


____________________= ___________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mai= lman/listinfo/ecrit
= --Apple-Mail-628283C0-0387-438A-8C1C-58D11600DA35-- From brian.rosen@neustar.biz Wed Jul 24 06:25:54 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C0311E810A for ; Wed, 24 Jul 2013 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYZ2sdzVxq3H for ; Wed, 24 Jul 2013 06:25:50 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2452211E80F7 for ; Wed, 24 Jul 2013 06:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374672261; x=1690032142; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=QP5fdXFZ6vdgI9nFf98GuRUvZDcyfRJg13PHZHFpsCU=; b=CVPWom3Bk4FngRndudupGvMsF7GsS/Q4XX0FO2yV3u2yiM8ZO3mG3f3h7Ej+6R tHqLDAkFBHpJcd7mKCUuHRWw== Received: from ([10.31.58.69]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.21432704; Wed, 24 Jul 2013 09:24:19 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 24 Jul 2013 09:25:44 -0400 From: "Rosen, Brian" To: Karl Heinz Wolf Thread-Topic: [Ecrit] LoST recursion and Forest Guides Thread-Index: AQHOgyFJU8ETq0n8JkKNvkzlp5DbOw== Date: Wed, 24 Jul 2013 13:25:43 +0000 Message-ID: References: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> <3E394609-851B-40C4-B499-D5024859147D@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.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: phi9GPdyDeolzikGuT58pw== Content-Type: multipart/alternative; boundary="_000_B2D6CE110F46474893BBB58E4AAC91A1neustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:25:54 -0000 --_000_B2D6CE110F46474893BBB58E4AAC91A1neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If there is a service for urn:service:foo, the local LoST server knows how = to serve it, or knows how to refer to some entity that can get it. You can't iterate up the urn:service:sos tree looking for urn:service:foo. The alternatives to searching bottom up is that the FG has to be expensive,= like the DNS root - very widely replicated and dispersed. I don't think t= hat is deployable. If the FG is only used when you need to cross trees (a = query out of area), it's much less costly, much more deployable. This also= applies to intermediate LoST servers. If the path is top down, all the in= termediate servers need to be public. I want the FG to be able to refuse queries that are from entities it does n= ot know (it knows the leaves in the tree below it and the FGs it peers with= ). That is much, much more deployable. The FG can't be a public resource in my opinion. We don't have organizatio= ns who would be willing to deploy those kinds of services for free like we = did for DNS. A public resource as attractive as an FG (or intermediate servers) that ser= ved urn:service:sos would need to withstand the largest DDoS attacks possib= le. That is currently 300+ G and heading towards a terabit of attack traff= ic. If it's not public, it doesn't need that level of threat mitigation. The lowest level (the authoritative server) must be publicly accessible. N= o way to avoid that I think. I'm trying to figure out a way to get the FG = deployed without that level of expense. The lowest level is somewhat less = attractive of a target than an FG would be, but it still would need to have= very significant DDoS mitigation. Brian On Jul 24, 2013, at 2:46 AM, Karl Heinz Wolf > wrote: On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian > wrote: If the local server didn't have the answer it could recur or iterate up the= tree. The client would never have to discover a resolver, the local serve= r becomes one. Brian, so you suggest that all queries go to a local LoST server, consequently the= urn:service:sos tree would be bothered for each query, also for urn:servic= e:foo, which iterates up the urn:service:sos tree, until reaching the fores= t guide that is able to tell the tree for service foo? When you say that the local lost server becomes a resolver, I wonder what i= st the advantage of discovering a local LoST server? A resolver will verly = likely have the responses of all the "local" services in its cache (urn:ser= vice:sos as well as any other), and all the other queries can be directed t= o the right tree via forest guides, without bothering the urn:service:sos t= ree at all. Best, Karl On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf > wrote: On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian > wrote: I want to have LoST discovery find a local LoST server, which nearly always= has the answer you want. No FG, no real resolvers. Brian, thanks for your answer. So this local LoST server would then be a Lo= ST mapping server for a specific reagion and a particular service (e.g. urn= :service:sos), do I understand this correctly? Then the client would have t= o discover a real LoST resolver as well which it has to consult for other s= ervices. If the local LoST server doesn't have the answer, then we get to the forest= . If your local LoST server doesn't have the answer, it's next most likely= that you need some adjacent server. So walk up the tree a level and find = it. If something is broken, like the seeker for some reason isn't actually loca= l, then you might need to go all the way up to the root of the tree, and ac= ross (using the FG), and down another tree. This should be really rare, bu= t it can happen. Each server in the tree knows the leaves below (coverage and URI) so it can= recurse or iterate down, and it knows the URI of the next level up so it c= an recurse or iterate up the tree. That has to work, or the FG would have = a zillion one level trees. It doesn't, so the trees have intermediate serv= ers that know about the leaves at their level, and can recure/iterate up. I don't want to see devices start at the FG always. That would mean that t= he FG is in the path of every emergency call (ignoring caching, which obvio= usly helps a lot). That's not a good design. Stay local, and use the fore= st only when you have to go out of area for some reason. Does this mean the architecture of RFC 5582 is going to be updaded? After a= ll, this architecture is along the lines of the DNS system, where queries w= ould also always start at the DNS root servers when ignoring caching. Best, Karl On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf > wrote: On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian > wrote: This means that the national forest guide must be prepared to answer querie= s from any device at any time. In particular, it has to be sized for the w= orst case scenario where a very large number of devices make requests of it= , and it cannot refuse a request from any source (as a practical matter). = This makes it a very attractive DDoS target. In fact, I would argue that a= great number of implementations will simply start all queries at the top o= f the tree in all cases, since the forest guide URI will become well known = quickly. Brian, I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture= should work without the forest guide URI to be known by resolvers. Moreove= r, since the forest guide points to the root of the tree, the query has to = start at the root. Or are you talking about some private LoST deployments i= nside the NENA network where some other mechanisms and architectures apply? Best, Karl _______________________________________________ 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 --_000_B2D6CE110F46474893BBB58E4AAC91A1neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable If there is a service for urn:service:foo, the local LoST server knows how = to serve it, or knows how to refer to some entity that can get it.
You can't iterate up the urn:service:sos tree looking for urn:service:= foo.

The alternatives to searching bottom up is that the FG has to be expen= sive, like the DNS root - very widely replicated and dispersed.  I don= 't think that is deployable.  If the FG is only used when you need to = cross trees (a query out of area), it's much less costly, much more deployable.  This also applies to intermediate= LoST servers.  If the path is top down, all the intermediate servers = need to be public.

I want the FG to be able to refuse queries that are from entities it d= oes not know (it knows the leaves in the tree below it and the FGs it peers= with).  That is much, much more deployable. 

The FG can't be a public resource in my opinion.  We don't have o= rganizations who would be willing to deploy those kinds of services for fre= e like we did for DNS.

A public resource as attractive as an FG (or intermediate servers) tha= t served urn:service:sos would need to withstand the largest DDoS attacks p= ossible.  That is currently 300+ G and heading towards a terabit o= f attack traffic.  If it's not public, it doesn't need that level of threat mitigation.

The lowest level (the authoritative server) must be publicly accessibl= e.  No way to avoid that I think.  I'm trying to figure out a way= to get the FG deployed without that level of expense.  The lowest lev= el is somewhat less attractive of a target than an FG would be, but it still would need to have very significant DDoS miti= gation.

Brian


On Jul 24, 2013, at 2:46 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

If the local server didn't have the answer it could recur or = iterate up the tree.  The client would never have to discover a resolv= er, the local server becomes one. 

Brian,

so you suggest that all queries go to a local LoST server, consequentl= y the urn:service:sos tree would be bothered for each query, also for urn:s= ervice:foo, which iterates up the urn:service:sos tree, until reaching the = forest guide that is able to tell the tree for service foo?

When you say that the local lost server becomes a resolver, I wonder w= hat ist the advantage of discovering a local LoST server? A resolver will v= erly likely have the responses of all the "local" services in its= cache (urn:service:sos as well as any other), and all the other queries can be directed to the right tree via forest gui= des, without bothering the urn:service:sos tree at all.

Best,
Karl


On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
I want to have LoST discovery find a local LoST server, which nearly a= lways has the answer you want.  No FG, no real resolvers.
 
Brian, thanks for your answer. So this local LoST server would then be= a LoST mapping server for a specific reagion and a particular service (e.g= . urn:service:sos), do I understand this correctly? Then the client would h= ave to discover a real LoST resolver as well which it has to consult for other services.

If the local LoST server doesn't have the answer, then we get to the f= orest.  If your local LoST server doesn't have the answer, it's next m= ost likely that you need some adjacent server.  So walk up the tree a = level and find it.

If something is broken, like the seeker for some reason isn't actually= local, then you might need to go all the way up to the root of the tree, a= nd across (using the FG), and down another tree.  This should be reall= y rare, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so i= t can recurse or iterate down, and it knows the URI of the next level up so= it can recurse or iterate up the tree.  That has to work, or the FG w= ould have a zillion one level trees.  It doesn't, so the trees have intermediate servers that know about t= he leaves at their level, and can recure/iterate up.  

I don't want to see devices start at the FG always.  That would m= ean that the FG is in the path of every emergency call (ignoring caching, w= hich obviously helps a lot).  That's not a good design.  Stay loc= al, and use the forest only when you have to go out of area for some reason.

Does this mean the architecture of RFC 5582 is going to be updaded? Af= ter all, this architecture is along the lines of the DNS system, where quer= ies would also always start at the DNS root servers when ignoring caching.

Best,
Karl

 

On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

This means that the national forest guide must be prepared to answer q= ueries from any device at any time.  In particular, it has to be sized= for the worst case scenario where a very large number of devices make requ= ests of it, and it cannot refuse a request from any source (as a practical matter).  This makes it a very attrac= tive DDoS target.  In fact, I would argue that a great number of imple= mentations will simply start all queries at the top of the tree in all case= s, since the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture should work without the forest = guide URI to be known by resolvers. Moreover, since the forest guide points= to the root of the tree, the query has to start at the root. Or are you ta= lking about some private LoST deployments inside the NENA network where some other mechanisms and architectures appl= y?

Best,
Karl

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


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



--_000_B2D6CE110F46474893BBB58E4AAC91A1neustarbiz_-- From brian.rosen@neustar.biz Wed Jul 24 06:27:54 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988C111E8120 for ; Wed, 24 Jul 2013 06:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or82Z153cTRK for ; Wed, 24 Jul 2013 06:27:41 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id D266511E8104 for ; Wed, 24 Jul 2013 06:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374672372; x=1690032142; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=r/PN6hYxL66DyNRwCP+ZBRB21II7lxzSuZLtRHZiE90=; b=adfRvmubCN2gw+i0FA6ez2BWjI4Reo3PVCBlTF3AEGXfdMtydfWaE3fBJATnqz hhHxz/akv6Dw1TlWEaPqmUVQ== Received: from ([10.31.58.69]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.21432824; Wed, 24 Jul 2013 09:26:11 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.240]) with mapi id 14.02.0342.003; Wed, 24 Jul 2013 09:27:31 -0400 From: "Rosen, Brian" To: James Winterbottom Thread-Topic: [Ecrit] LoST recursion and Forest Guides Thread-Index: AQHOgyFJU8ETq0n8JkKNvkzlp5DbOw== Date: Wed, 24 Jul 2013 13:27:31 +0000 Message-ID: <0667D1B7-C4E1-4CF0-B80B-453E4F830A67@neustar.biz> References: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> <3E394609-851B-40C4-B499-D5024859147D@neustar.biz> <2E8BFE37-2652-48A5-9CF3-5DE0D13CEF8C@gmail.com> In-Reply-To: <2E8BFE37-2652-48A5-9CF3-5DE0D13CEF8C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 5Otd85OjXrahkv7oAdSuOQ== Content-Type: multipart/alternative; boundary="_000_0667D1B7C4E14CF0B80B453E4F830A67neustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:27:55 -0000 --_000_0667D1B7C4E14CF0B80B453E4F830A67neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Your access network is physically local and your access network gives you D= HCP. Use DHCP LoST discovery on the access network and you get your local = server. Brian On Jul 24, 2013, at 4:22 AM, James Winterbottom > wrote: My problem with this approach is that discovery mechanisms are domain name = driven and this kind of means that local is domain local and not necessaril= y physically local so I am unclear on how to configure my network to make w= hat is being proposed happen. Cheers James Sent from my iPad On 24/07/2013, at 4:46 PM, Karl Heinz Wolf > wrote: On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian > wrote: If the local server didn't have the answer it could recur or iterate up the= tree. The client would never have to discover a resolver, the local serve= r becomes one. Brian, so you suggest that all queries go to a local LoST server, consequently the= urn:service:sos tree would be bothered for each query, also for urn:servic= e:foo, which iterates up the urn:service:sos tree, until reaching the fores= t guide that is able to tell the tree for service foo? When you say that the local lost server becomes a resolver, I wonder what i= st the advantage of discovering a local LoST server? A resolver will verly = likely have the responses of all the "local" services in its cache (urn:ser= vice:sos as well as any other), and all the other queries can be directed t= o the right tree via forest guides, without bothering the urn:service:sos t= ree at all. Best, Karl On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf > wrote: On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian > wrote: I want to have LoST discovery find a local LoST server, which nearly always= has the answer you want. No FG, no real resolvers. Brian, thanks for your answer. So this local LoST server would then be a Lo= ST mapping server for a specific reagion and a particular service (e.g. urn= :service:sos), do I understand this correctly? Then the client would have t= o discover a real LoST resolver as well which it has to consult for other s= ervices. If the local LoST server doesn't have the answer, then we get to the forest= . If your local LoST server doesn't have the answer, it's next most likely= that you need some adjacent server. So walk up the tree a level and find = it. If something is broken, like the seeker for some reason isn't actually loca= l, then you might need to go all the way up to the root of the tree, and ac= ross (using the FG), and down another tree. This should be really rare, bu= t it can happen. Each server in the tree knows the leaves below (coverage and URI) so it can= recurse or iterate down, and it knows the URI of the next level up so it c= an recurse or iterate up the tree. That has to work, or the FG would have = a zillion one level trees. It doesn't, so the trees have intermediate serv= ers that know about the leaves at their level, and can recure/iterate up. I don't want to see devices start at the FG always. That would mean that t= he FG is in the path of every emergency call (ignoring caching, which obvio= usly helps a lot). That's not a good design. Stay local, and use the fore= st only when you have to go out of area for some reason. Does this mean the architecture of RFC 5582 is going to be updaded? After a= ll, this architecture is along the lines of the DNS system, where queries w= ould also always start at the DNS root servers when ignoring caching. Best, Karl On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf > wrote: On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian > wrote: This means that the national forest guide must be prepared to answer querie= s from any device at any time. In particular, it has to be sized for the w= orst case scenario where a very large number of devices make requests of it= , and it cannot refuse a request from any source (as a practical matter). = This makes it a very attractive DDoS target. In fact, I would argue that a= great number of implementations will simply start all queries at the top o= f the tree in all cases, since the forest guide URI will become well known = quickly. Brian, I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture= should work without the forest guide URI to be known by resolvers. Moreove= r, since the forest guide points to the root of the tree, the query has to = start at the root. Or are you talking about some private LoST deployments i= nside the NENA network where some other mechanisms and architectures apply? Best, Karl _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_0667D1B7C4E14CF0B80B453E4F830A67neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <69C74615003A014680D5836AABE33507@neustar.biz> Content-Transfer-Encoding: quoted-printable Your access network is physically local and your access network gives you D= HCP.  Use DHCP LoST discovery on the access network and you get your l= ocal server.  

Brian

On Jul 24, 2013, at 4:22 AM, James Winterbottom <a.james.winterbottom@gmail.com> wrot= e:

My problem with this approach is that discovery mechanisms are domain = name driven and this kind of means that local is domain local and not neces= sarily physically local so I am unclear on how to configure my network to m= ake what is being proposed happen.

Cheers
James

Sent from my iPad

On 24/07/2013, at 4:46 PM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

If the local server didn't have the answer it could recur or = iterate up the tree.  The client would never have to discover a resolv= er, the local server becomes one. 

Brian,

so you suggest that all queries go to a local LoST server, consequentl= y the urn:service:sos tree would be bothered for each query, also for urn:s= ervice:foo, which iterates up the urn:service:sos tree, until reaching the = forest guide that is able to tell the tree for service foo?

When you say that the local lost server becomes a resolver, I wonder w= hat ist the advantage of discovering a local LoST server? A resolver will v= erly likely have the responses of all the "local" services in its= cache (urn:service:sos as well as any other), and all the other queries can be directed to the right tree via forest gui= des, without bothering the urn:service:sos tree at all.

Best,
Karl


On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
I want to have LoST discovery find a local LoST server, which nearly a= lways has the answer you want.  No FG, no real resolvers.
 
Brian, thanks for your answer. So this local LoST server would then be= a LoST mapping server for a specific reagion and a particular service (e.g= . urn:service:sos), do I understand this correctly? Then the client would h= ave to discover a real LoST resolver as well which it has to consult for other services.

If the local LoST server doesn't have the answer, then we get to the f= orest.  If your local LoST server doesn't have the answer, it's next m= ost likely that you need some adjacent server.  So walk up the tree a = level and find it.

If something is broken, like the seeker for some reason isn't actually= local, then you might need to go all the way up to the root of the tree, a= nd across (using the FG), and down another tree.  This should be reall= y rare, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so i= t can recurse or iterate down, and it knows the URI of the next level up so= it can recurse or iterate up the tree.  That has to work, or the FG w= ould have a zillion one level trees.  It doesn't, so the trees have intermediate servers that know about t= he leaves at their level, and can recure/iterate up.  

I don't want to see devices start at the FG always.  That would m= ean that the FG is in the path of every emergency call (ignoring caching, w= hich obviously helps a lot).  That's not a good design.  Stay loc= al, and use the forest only when you have to go out of area for some reason.

Does this mean the architecture of RFC 5582 is going to be updaded? Af= ter all, this architecture is along the lines of the DNS system, where quer= ies would also always start at the DNS root servers when ignoring caching.

Best,
Karl

 

On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

This means that the national forest guide must be prepared to answer q= ueries from any device at any time.  In particular, it has to be sized= for the worst case scenario where a very large number of devices make requ= ests of it, and it cannot refuse a request from any source (as a practical matter).  This makes it a very attrac= tive DDoS target.  In fact, I would argue that a great number of imple= mentations will simply start all queries at the top of the tree in all case= s, since the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture should work without the forest = guide URI to be known by resolvers. Moreover, since the forest guide points= to the root of the tree, the query has to start at the root. Or are you ta= lking about some private LoST deployments inside the NENA network where some other mechanisms and architectures appl= y?

Best,
Karl

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


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


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

--_000_0667D1B7C4E14CF0B80B453E4F830A67neustarbiz_-- From khwolf1@gmail.com Thu Jul 25 03:47:53 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A35321F90C3 for ; Thu, 25 Jul 2013 03:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QudUpG3iz5qW for ; Thu, 25 Jul 2013 03:47:52 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id E5E0E21F8419 for ; Thu, 25 Jul 2013 03:47:51 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so1101149obb.8 for ; Thu, 25 Jul 2013 03:47:45 -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=vFaKS881MsmFbWLLNjM2mAFBABr0V3H6D6oI9XEJC4M=; b=jnl2K8bbSvW1ZtOD1ZsASmbUHEh9yA7TxqASXde4DMLYltaigU5ZCfNOsCIR2TuEpz g9eL14l8szt6IGIXfdXIvKDLVe+ba9ZYhgpYmHAp+kFaU+ro5EkoQ/vm1jwq0kYzmcHq tl3Z8v1dMru35mmqql85OLzlUWYmvaBG3jA/muEBYcRj0/ZhZJonX0jeF7zrO05mx1/p GI0tX5EjvNR3htCAlHQZBMm2Fdqx2fQDndS/j1iUo4sdTAgURc+EtzAEr55cCls0Dznx 7w5OYrNIOx5jGxgsf8qSKjbEQs4dRoeQh4IAv5BqoU0xSDdK0GGUH7bXgFxyEUd4E6uO sI9w== MIME-Version: 1.0 X-Received: by 10.182.176.67 with SMTP id cg3mr34219518obc.65.1374749265791; Thu, 25 Jul 2013 03:47:45 -0700 (PDT) Received: by 10.76.18.39 with HTTP; Thu, 25 Jul 2013 03:47:45 -0700 (PDT) In-Reply-To: References: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> <3E394609-851B-40C4-B499-D5024859147D@neustar.biz> Date: Thu, 25 Jul 2013 12:47:45 +0200 Message-ID: From: Karl Heinz Wolf To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=e89a8ff1cecea491ab04e253c18d Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 10:47:53 -0000 --e89a8ff1cecea491ab04e253c18d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jul 24, 2013 at 3:25 PM, Rosen, Brian wrot= e: > If there is a service for urn:service:foo, the local LoST server knows > how to serve it, or knows how to refer to some entity that can get it. > Sounds to me that the local LoST server would then actually be a mapping server + forest guide. Who should actually operate the local LoST server? Would the operator of the local urn:service:sos mapping server of a county really want to peer with all other service operators like urn:service:foo to exchange mappings via LoST sync so that the local LoST server is able to know how to serve them, as you mentioned? Anyway, this seems like lots of peering agreements. Best, Karl > You can't iterate up the urn:service:sos tree looking for urn:service:foo= . > > The alternatives to searching bottom up is that the FG has to be > expensive, like the DNS root - very widely replicated and dispersed. I > don't think that is deployable. If the FG is only used when you need to > cross trees (a query out of area), it's much less costly, much > more deployable. This also applies to intermediate LoST servers. If the > path is top down, all the intermediate servers need to be public. > > I want the FG to be able to refuse queries that are from entities it > does not know (it knows the leaves in the tree below it and the FGs it > peers with). That is much, much more deployable. > > The FG can't be a public resource in my opinion. We don't have > organizations who would be willing to deploy those kinds of services for > free like we did for DNS. > > A public resource as attractive as an FG (or intermediate servers) that > served urn:service:sos would need to withstand the largest DDoS attacks > possible. That is currently 300+ G and heading towards a terabit of atta= ck > traffic. If it's not public, it doesn't need that level of threat > mitigation. > > The lowest level (the authoritative server) must be publicly accessible. > No way to avoid that I think. I'm trying to figure out a way to get the > FG deployed without that level of expense. The lowest level is somewhat > less attractive of a target than an FG would be, but it still would need = to > have very significant DDoS mitigation. > > Brian > > > On Jul 24, 2013, at 2:46 AM, Karl Heinz Wolf wrote: > > On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian = wrote: > >> >> If the local server didn't have the answer it could recur or iterate up >> the tree. The client would never have to discover a resolver, the local >> server becomes one. >> > > Brian, > > so you suggest that all queries go to a local LoST server, consequently > the urn:service:sos tree would be bothered for each query, also for > urn:service:foo, which iterates up the urn:service:sos tree, until reachi= ng > the forest guide that is able to tell the tree for service foo? > > When you say that the local lost server becomes a resolver, I wonder > what ist the advantage of discovering a local LoST server? A resolver wil= l > verly likely have the responses of all the "local" services in its cache > (urn:service:sos as well as any other), and all the other queries can be > directed to the right tree via forest guides, without bothering the > urn:service:sos tree at all. > > Best, > Karl > > >> On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf wrote: >> >> On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian wrote: >> >>> I want to have LoST discovery find a local LoST server, which nearly >>> always has the answer you want. No FG, no real resolvers. >>> >> >> Brian, thanks for your answer. So this local LoST server would then be >> a LoST mapping server for a specific reagion and a particular service (e= .g. >> urn:service:sos), do I understand this correctly? Then the client would >> have to discover a real LoST resolver as well which it has to consult fo= r >> other services. >> >> If the local LoST server doesn't have the answer, then we get to the >>> forest. If your local LoST server doesn't have the answer, it's next m= ost >>> likely that you need some adjacent server. So walk up the tree a level= and >>> find it. >>> >>> If something is broken, like the seeker for some reason isn't actually >>> local, then you might need to go all the way up to the root of the tree= , >>> and across (using the FG), and down another tree. This should be reall= y >>> rare, but it can happen. >>> >>> Each server in the tree knows the leaves below (coverage and URI) so >>> it can recurse or iterate down, and it knows the URI of the next level = up >>> so it can recurse or iterate up the tree. That has to work, or the FG >>> would have a zillion one level trees. It doesn't, so the trees have >>> intermediate servers that know about the leaves at their level, and can >>> recure/iterate up. >>> >>> I don't want to see devices start at the FG always. That would mean >>> that the FG is in the path of every emergency call (ignoring caching, w= hich >>> obviously helps a lot). That's not a good design. Stay local, and use= the >>> forest only when you have to go out of area for some reason. >>> >> >> Does this mean the architecture of RFC 5582 is going to be updaded? >> After all, this architecture is along the lines of the DNS system, where >> queries would also always start at the DNS root servers when ignoring >> caching. >> >> Best, >> Karl >> >> >> >>> >>> >>> On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf >>> wrote: >>> >>> On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian < >>> Brian.Rosen@neustar.biz> wrote: >>> >>>> >>>> This means that the national forest guide must be prepared to answer >>>> queries from any device at any time. In particular, it has to be size= d for >>>> the worst case scenario where a very large number of devices make requ= ests >>>> of it, and it cannot refuse a request from any source (as a practical >>>> matter). This makes it a very attractive DDoS target. In fact, I wou= ld >>>> argue that a great number of implementations will simply start all que= ries >>>> at the top of the tree in all cases, since the forest guide URI will b= ecome >>>> well known quickly. >>>> >>> >>> Brian, >>> >>> I got a bit confused here and I probably missed the discussion on the >>> issue. However, the mapping architecture in RFC 5582 describes that a >>> seeker queries a resolver, the resolver consults a forest guide and the= n >>> goes to the root of the appropriate tree. So I don=92t see how the RFC5= 582 >>> architecture should work without the forest guide URI to be known by >>> resolvers. Moreover, since the forest guide points to the root of the t= ree, >>> the query has to start at the root. Or are you talking about some priva= te >>> LoST deployments inside the NENA network where some other mechanisms an= d >>> architectures apply? >>> >>> Best, >>> Karl >>> >>> _______________________________________________ >>> 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 >> >> >> > > --e89a8ff1cecea491ab04e253c18d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 24, 2013 at 3:25 PM, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:
If there is a service for urn:service:foo, the local LoST server knows how = to serve it, or knows how to refer to some entity that can get it.

Sounds to me that the local LoST server would= then actually be a mapping server + forest guide. Who should actually oper= ate the local LoST server? Would the operator of the local urn:service:sos = mapping server of a county really want to peer with all other service opera= tors like urn:service:foo to exchange mappings via LoST sync so that the lo= cal LoST server is able to know how to serve them, as you mentioned? Anyway= , this seems like lots of peering agreements.

Best,
Karl
=A0
You can't iterate up the urn:service:sos tree looking for urn:serv= ice:foo.

The alternatives to searching bottom up is that the FG has to be expen= sive, like the DNS root - very widely replicated and dispersed. =A0I don= 9;t think that is deployable. =A0If the FG is only used when you need to cr= oss trees (a query out of area), it's much less costly, much
more= deployable. =A0This also applies to intermediate LoST servers. =A0If the p= ath is top down, all the intermediate servers need to be public.

I want the FG to be able to refuse queries that are from entities it d= oes not know (it knows the leaves in the tree below it and the FGs it peers= with). =A0That is much, much more deployable.=A0

The FG can't be a public resource in my opinion. =A0We don't h= ave organizations who would be willing to deploy those kinds of services fo= r free like we did for DNS.

A public resource as attractive as an FG (or intermediate servers) tha= t served urn:service:sos would need to withstand the largest DDoS attacks p= ossible. =A0That is currently 300+ G and heading towards a terabit of attac= k traffic. =A0If it's not public, it doesn't need that level of threat mitigation.

The lowest level (the authoritative server) must be publicly accessibl= e. =A0No way to avoid that I think. =A0I'm trying to figure out a way t= o get the FG deployed without that level of expense. =A0The lowest level is= somewhat less attractive of a target than an FG would be, but it still would need to have very significant DDoS miti= gation.

Brian



On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

If the local server didn't have the answer it could recur= or iterate up the tree. =A0The client would never have to discover a resol= ver, the local server becomes one.=A0

Brian,

so you suggest that all queries go to a local LoST server, consequentl= y the urn:service:sos tree would be bothered for each query, also for urn:s= ervice:foo, which iterates up the urn:service:sos tree, until reaching the = forest guide that is able to tell the tree for service foo?

When you say that the local lost server becomes a resolver, I wonder w= hat ist the advantage of discovering a local LoST server? A resolver will v= erly likely have the responses of all the "local" services in its= cache (urn:service:sos as well as any other), and all the other queries can be directed to the right tree via forest gui= des, without bothering the urn:service:sos tree at all.

Best,
Karl


On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
I want to have LoST discovery find a local LoST server, which nearly a= lways has the answer you want. =A0No FG, no real resolvers.
=A0
Brian, thanks for your answer. So this local LoST server would then be= a LoST mapping server for a specific reagion and a particular service (e.g= . urn:service:sos), do I understand this correctly? Then the client would h= ave to discover a real LoST resolver as well which it has to consult for other services.

If the local LoST server doesn't have the answer, then we get to t= he forest. =A0If your local LoST server doesn't have the answer, it'= ;s next most likely that you need some adjacent server. =A0So walk up the t= ree a level and find it.

If something is broken, like the seeker for some reason isn't actu= ally local, then you might need to go all the way up to the root of the tre= e, and across (using the FG), and down another tree. =A0This should be real= ly rare, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so i= t can recurse or iterate down, and it knows the URI of the next level up so= it can recurse or iterate up the tree. =A0That has to work, or the FG woul= d have a zillion one level trees. =A0It doesn't, so the trees have intermediate servers that know about = the leaves at their level, and can recure/iterate up. =A0

I don't want to see devices start at the FG always. =A0That would = mean that the FG is in the path of every emergency call (ignoring caching, = which obviously helps a lot). =A0That's not a good design. =A0Stay loca= l, and use the forest only when you have to go out of area for some reason.

Does this mean the architecture of RFC 5582 is going to be updaded? Af= ter all, this architecture is along the lines of the DNS system, where quer= ies would also always start at the DNS root servers when ignoring caching.

Best,
Karl

=A0

On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

This means that the national forest guide must be prepared to answer q= ueries from any device at any time. =A0In particular, it has to be sized fo= r the worst case scenario where a very large number of devices make request= s of it, and it cannot refuse a request from any source (as a practical matter). =A0This makes it a very attractiv= e DDoS target. =A0In fact, I would argue that a great number of implementat= ions will simply start all queries at the top of the tree in all cases, sin= ce the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture should work without the forest = guide URI to be known by resolvers. Moreover, since the forest guide points= to the root of the tree, the query has to start at the root. Or are you ta= lking about some private LoST deployments inside the NENA network where some other mechanisms and architectures appl= y?

Best,
Karl

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


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




--e89a8ff1cecea491ab04e253c18d-- From brian.rosen@neustar.biz Thu Jul 25 06:55:36 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A5621F9A96 for ; Thu, 25 Jul 2013 06:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIvWM+R5v324 for ; Thu, 25 Jul 2013 06:55:32 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 531E521F9AA2 for ; Thu, 25 Jul 2013 06:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1374760491; x=1690113250; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=AbhWoQlk8TVBEXsW4Px0dZ645CD3AXevruszJToJbt0=; b=aV/Abcz7hS3HXgKsa5x/qXhhiKbfp/koTi7EdcYYqGTuWMJobVYqTyLCHAgkmy 0CtxsSGOV0/HMwQk5pJTPxMA== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.22906774; Thu, 25 Jul 2013 09:54:50 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.178]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 25 Jul 2013 09:55:14 -0400 From: "Rosen, Brian" To: Karl Heinz Wolf Thread-Topic: [Ecrit] LoST recursion and Forest Guides Thread-Index: AQHOgyFJU8ETq0n8JkKNvkzlp5DbOw== Date: Thu, 25 Jul 2013 13:55:13 +0000 Message-ID: <6C467183-6A62-477D-ADEB-3C10229C0788@neustar.biz> References: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> <3E394609-851B-40C4-B499-D5024859147D@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.17] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 4p8Hs2y03tgv9O8OthgNOQ== Content-Type: multipart/alternative; boundary="_000_6C4671836A62477DADEB3C10229C0788neustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 13:55:36 -0000 --_000_6C4671836A62477DADEB3C10229C0788neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable No, it's just a LoST server that knows about trees its in. Nothing more, n= othing less. It might be run by the access network or, in the case of urn:service:sos, t= he local emergency authorities. It's just in a tree (or perhaps more than one tree if it serves multiple "t= op level" services). It doesn't know about forest guides unless it is at t= he top of the tree (which might be common for some places with urn:service:= sos where the "tree" is one level, one server). If it doesn't know a mapping, if refers/recurs up the tree. If it's at the= top of the tree (a root server), it uses mappings it obtains from a FG to = refer/recur to another tree. Unless it's at the top of the tree, it's only sending its service boundary = and URI to its parent. That's not LoST sync really because it's only one w= ay. It refers anything it isn't authoritative for to its parent, but doesn= 't have any coverage info from the parent. It doesn't need any. Brian On Jul 25, 2013, at 6:47 AM, Karl Heinz Wolf > wrote: On Wed, Jul 24, 2013 at 3:25 PM, Rosen, Brian > wrote: If there is a service for urn:service:foo, the local LoST server knows how = to serve it, or knows how to refer to some entity that can get it. Sounds to me that the local LoST server would then actually be a mapping se= rver + forest guide. Who should actually operate the local LoST server? Wou= ld the operator of the local urn:service:sos mapping server of a county rea= lly want to peer with all other service operators like urn:service:foo to e= xchange mappings via LoST sync so that the local LoST server is able to kno= w how to serve them, as you mentioned? Anyway, this seems like lots of peer= ing agreements. Best, Karl You can't iterate up the urn:service:sos tree looking for urn:service:foo. The alternatives to searching bottom up is that the FG has to be expensive,= like the DNS root - very widely replicated and dispersed. I don't think t= hat is deployable. If the FG is only used when you need to cross trees (a = query out of area), it's much less costly, much more deployable. This also applies to intermediate LoST servers. If the p= ath is top down, all the intermediate servers need to be public. I want the FG to be able to refuse queries that are from entities it does n= ot know (it knows the leaves in the tree below it and the FGs it peers with= ). That is much, much more deployable. The FG can't be a public resource in my opinion. We don't have organizatio= ns who would be willing to deploy those kinds of services for free like we = did for DNS. A public resource as attractive as an FG (or intermediate servers) that ser= ved urn:service:sos would need to withstand the largest DDoS attacks possib= le. That is currently 300+ G and heading towards a terabit of attack traff= ic. If it's not public, it doesn't need that level of threat mitigation. The lowest level (the authoritative server) must be publicly accessible. N= o way to avoid that I think. I'm trying to figure out a way to get the FG = deployed without that level of expense. The lowest level is somewhat less = attractive of a target than an FG would be, but it still would need to have= very significant DDoS mitigation. Brian On Jul 24, 2013, at 2:46 AM, Karl Heinz Wolf > wrote: On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian > wrote: If the local server didn't have the answer it could recur or iterate up the= tree. The client would never have to discover a resolver, the local serve= r becomes one. Brian, so you suggest that all queries go to a local LoST server, consequently the= urn:service:sos tree would be bothered for each query, also for urn:servic= e:foo, which iterates up the urn:service:sos tree, until reaching the fores= t guide that is able to tell the tree for service foo? When you say that the local lost server becomes a resolver, I wonder what i= st the advantage of discovering a local LoST server? A resolver will verly = likely have the responses of all the "local" services in its cache (urn:ser= vice:sos as well as any other), and all the other queries can be directed t= o the right tree via forest guides, without bothering the urn:service:sos t= ree at all. Best, Karl On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf > wrote: On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian > wrote: I want to have LoST discovery find a local LoST server, which nearly always= has the answer you want. No FG, no real resolvers. Brian, thanks for your answer. So this local LoST server would then be a Lo= ST mapping server for a specific reagion and a particular service (e.g. urn= :service:sos), do I understand this correctly? Then the client would have t= o discover a real LoST resolver as well which it has to consult for other s= ervices. If the local LoST server doesn't have the answer, then we get to the forest= . If your local LoST server doesn't have the answer, it's next most likely= that you need some adjacent server. So walk up the tree a level and find = it. If something is broken, like the seeker for some reason isn't actually loca= l, then you might need to go all the way up to the root of the tree, and ac= ross (using the FG), and down another tree. This should be really rare, bu= t it can happen. Each server in the tree knows the leaves below (coverage and URI) so it can= recurse or iterate down, and it knows the URI of the next level up so it c= an recurse or iterate up the tree. That has to work, or the FG would have = a zillion one level trees. It doesn't, so the trees have intermediate serv= ers that know about the leaves at their level, and can recure/iterate up. I don't want to see devices start at the FG always. That would mean that t= he FG is in the path of every emergency call (ignoring caching, which obvio= usly helps a lot). That's not a good design. Stay local, and use the fore= st only when you have to go out of area for some reason. Does this mean the architecture of RFC 5582 is going to be updaded? After a= ll, this architecture is along the lines of the DNS system, where queries w= ould also always start at the DNS root servers when ignoring caching. Best, Karl On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf > wrote: On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian > wrote: This means that the national forest guide must be prepared to answer querie= s from any device at any time. In particular, it has to be sized for the w= orst case scenario where a very large number of devices make requests of it= , and it cannot refuse a request from any source (as a practical matter). = This makes it a very attractive DDoS target. In fact, I would argue that a= great number of implementations will simply start all queries at the top o= f the tree in all cases, since the forest guide URI will become well known = quickly. Brian, I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture= should work without the forest guide URI to be known by resolvers. Moreove= r, since the forest guide points to the root of the tree, the query has to = start at the root. Or are you talking about some private LoST deployments i= nside the NENA network where some other mechanisms and architectures apply? Best, Karl _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_6C4671836A62477DADEB3C10229C0788neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable No, it's just a LoST server that knows about trees its in.  Nothing mo= re, nothing less.

It might be run by the access network or, in the case of urn:service:s= os, the local emergency authorities.

It's just in a tree (or perhaps more than one tree if it serves multip= le "top level" services).  It doesn't know about forest guid= es unless it is at the top of the tree (which might be common for some plac= es with urn:service:sos where the "tree" is one level, one server).

If it doesn't know a mapping, if refers/recurs up the tree.  If i= t's at the top of the tree (a root server), it uses mappings it obtains fro= m a FG to refer/recur to another tree.

Unless it's at the top of the tree, it's only sending its service boun= dary and URI to its parent.  That's not LoST sync really because it's = only one way.  It refers anything it isn't authoritative for to its pa= rent, but doesn't have any coverage info from the parent.  It doesn't need any.

Brian

On Jul 25, 2013, at 6:47 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Wed, Jul 24, 2013 at 3:25 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
If there is a service for urn:service:f= oo, the local LoST server knows how to serve it, or knows how to refer to s= ome entity that can get it.

Sounds to me that the local LoST server would then actually be a mappi= ng server + forest guide. Who should actually operate the local LoST se= rver? Would the operator of the local urn:service:sos mapping server of a c= ounty really want to peer with all other service operators like urn:service:foo to exchange mappings via LoST sync = so that the local LoST server is able to know how to serve them, as you men= tioned? Anyway, this seems like lots of peering agreements.

Best,
Karl
 
You can't iterate up the urn:service:sos tree looking for urn:service:= foo.

The alternatives to searching bottom up is that the FG has to be expen= sive, like the DNS root - very widely replicated and dispersed.  I don= 't think that is deployable.  If the FG is only used when you need to = cross trees (a query out of area), it's much less costly, much
more deployable.  This also applies to intermediate LoST servers.=  If the path is top down, all the intermediate servers need to be pub= lic.

I want the FG to be able to refuse queries that are from entities it d= oes not know (it knows the leaves in the tree below it and the FGs it peers= with).  That is much, much more deployable. 

The FG can't be a public resource in my opinion.  We don't have o= rganizations who would be willing to deploy those kinds of services for fre= e like we did for DNS.

A public resource as attractive as an FG (or intermediate servers) tha= t served urn:service:sos would need to withstand the largest DDoS attacks p= ossible.  That is currently 300+ G and heading towards a terabit o= f attack traffic.  If it's not public, it doesn't need that level of threat mitigation.

The lowest level (the authoritative server) must be publicly accessibl= e.  No way to avoid that I think.  I'm trying to figure out a way= to get the FG deployed without that level of expense.  The lowest lev= el is somewhat less attractive of a target than an FG would be, but it still would need to have very significant DDoS miti= gation.

Brian


On Jul 24, 2013, at 2:46 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

If the local server didn't have the answer it could recur or = iterate up the tree.  The client would never have to discover a resolv= er, the local server becomes one. 

Brian,

so you suggest that all queries go to a local LoST server, consequentl= y the urn:service:sos tree would be bothered for each query, also for urn:s= ervice:foo, which iterates up the urn:service:sos tree, until reaching the = forest guide that is able to tell the tree for service foo?

When you say that the local lost server becomes a resolver, I wonder w= hat ist the advantage of discovering a local LoST server? A resolver will v= erly likely have the responses of all the "local" services in its= cache (urn:service:sos as well as any other), and all the other queries can be directed to the right tree via forest gui= des, without bothering the urn:service:sos tree at all.

Best,
Karl


On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
I want to have LoST discovery find a local LoST server, which nearly a= lways has the answer you want.  No FG, no real resolvers.
 
Brian, thanks for your answer. So this local LoST server would then be= a LoST mapping server for a specific reagion and a particular service (e.g= . urn:service:sos), do I understand this correctly? Then the client would h= ave to discover a real LoST resolver as well which it has to consult for other services.

If the local LoST server doesn't have the answer, then we get to the f= orest.  If your local LoST server doesn't have the answer, it's next m= ost likely that you need some adjacent server.  So walk up the tree a = level and find it.

If something is broken, like the seeker for some reason isn't actually= local, then you might need to go all the way up to the root of the tree, a= nd across (using the FG), and down another tree.  This should be reall= y rare, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so i= t can recurse or iterate down, and it knows the URI of the next level up so= it can recurse or iterate up the tree.  That has to work, or the FG w= ould have a zillion one level trees.  It doesn't, so the trees have intermediate servers that know about t= he leaves at their level, and can recure/iterate up.  

I don't want to see devices start at the FG always.  That would m= ean that the FG is in the path of every emergency call (ignoring caching, w= hich obviously helps a lot).  That's not a good design.  Stay loc= al, and use the forest only when you have to go out of area for some reason.

Does this mean the architecture of RFC 5582 is going to be updaded? Af= ter all, this architecture is along the lines of the DNS system, where quer= ies would also always start at the DNS root servers when ignoring caching.

Best,
Karl

 

On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

This means that the national forest guide must be prepared to answer q= ueries from any device at any time.  In particular, it has to be sized= for the worst case scenario where a very large number of devices make requ= ests of it, and it cannot refuse a request from any source (as a practical matter).  This makes it a very attrac= tive DDoS target.  In fact, I would argue that a great number of imple= mentations will simply start all queries at the top of the tree in all case= s, since the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture should work without the forest = guide URI to be known by resolvers. Moreover, since the forest guide points= to the root of the tree, the query has to start at the root. Or are you ta= lking about some private LoST deployments inside the NENA network where some other mechanisms and architectures appl= y?

Best,
Karl

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


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




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

--_000_6C4671836A62477DADEB3C10229C0788neustarbiz_-- From trac+ecrit@trac.tools.ietf.org Sun Jul 28 14:49:11 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A7421F9E80 for ; Sun, 28 Jul 2013 14:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id junoV0VNKzLV for ; Sun, 28 Jul 2013 14:49:09 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6048621F9E79 for ; Sun, 28 Jul 2013 14:49:08 -0700 (PDT) Received: from localhost ([127.0.0.1]:58209 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V3Yps-0005iO-HV; Sun, 28 Jul 2013 23:49:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Sun, 28 Jul 2013 21:49:04 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/ecrit/trac/ticket/16#comment:1 Message-ID: <080.c15a464f19bcdb51ba92b3da7abea0c9@trac.tools.ietf.org> References: <065.a67b4f0b0474478ba0c3849e74c58167@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <065.a67b4f0b0474478ba0c3849e74c58167@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130728214908.6048621F9E79@ietfa.amsl.com> Resent-Date: Sun, 28 Jul 2013 14:49:08 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #16: Re-organization of Section 3.1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 21:49:11 -0000 #16: Re-organization of Section 3.1 Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed Comment: Addressed in -06. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Sun Jul 28 14:49:57 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C233021F9E54 for ; Sun, 28 Jul 2013 14:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+hK3SU4k62o for ; Sun, 28 Jul 2013 14:49:57 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 01F5421F9E4F for ; Sun, 28 Jul 2013 14:49:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:58221 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V3Yqg-0004yo-EC; Sun, 28 Jul 2013 23:49:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Sun, 28 Jul 2013 21:49:54 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/ecrit/trac/ticket/17#comment:1 Message-ID: <080.b3b562db661049a240eebeb77b55a6a5@trac.tools.ietf.org> References: <065.3817af94c27189bfb7e27cf718565131@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <065.3817af94c27189bfb7e27cf718565131@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130728214957.01F5421F9E4F@ietfa.amsl.com> Resent-Date: Sun, 28 Jul 2013 14:49:57 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #17: Rewrite of Section 4 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 21:49:57 -0000 #17: Rewrite of Section 4 Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed Comment: Addressed in -06. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From RMarshall@telecomsys.com Mon Jul 29 00:34:58 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A349721F85F4 for ; Mon, 29 Jul 2013 00:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.109 X-Spam-Level: X-Spam-Status: No, score=-101.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 872vaQV7Anfb for ; Mon, 29 Jul 2013 00:34:54 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB86021F9C22 for ; Mon, 29 Jul 2013 00:34:19 -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.1/8.14.1) with ESMTP id r6T7Y7Be032677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 29 Jul 2013 00:34:08 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.68]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Mon, 29 Jul 2013 00:34:07 -0700 From: Roger Marshall To: "'ecrit@ietf.org'" Thread-Topic: Ecrit agenda for the IETF87 Berlin meeting Thread-Index: Ac6DOO5Y+7xiwVMrQ8Gbk0eJR33ThAI9AaYA Date: Mon, 29 Jul 2013 07:34:07 +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.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC39ED20SEAEXMB2telecomsy_" MIME-Version: 1.0 Subject: Re: [Ecrit] Ecrit agenda for the IETF87 Berlin meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 07:34:58 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC39ED20SEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda bash: I'm sending an updated ecrit agenda for this afternoon's 13:00= -15:00 meeting that includes: -- one additional presentation item: ID presentation (second from end) that= was requested prior. -- updated presenters -- revised ordering per subjects -roger. See the agenda below, which is also posted in the Meeting Materials Manager= , http://www.ietf.org/proceedings/87/agenda/agenda-87-ecrit ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall) 10 min * Additional Data related to an Emergency Call (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss latest changes and if ready for WGLC 10 min * (Brian) Updating Additional Data related to an Emergency Call usin= g Subscribe/Notify (Brian) http://tools.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00/ Intention: Discuss new draft 15 min. * Trustworthy Location Information (Bernard) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss impact of recent rewrite 15 min * eCall - background, current status, and requirements discussion li= nked to current ETSI work (Ban Al-Bakri) 15 min * Internet Protocol-based In-Vehicle Emergency Call (Randy) http://tools.ietf.org/id/draft-rosen-ecrit-ecall/ Intention: Discussion of draft & WG adoption question 10 min * Uniform Resource Name (URN) extension for automatic and manual Eme= rgency Services (Roland) draft-jesske-ecrit-ecall-urn-extension-01 Intention: Discussion of changes to draft 10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts us= ing the Session Initiation Protocol (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Intention: Discuss recent updates to draft 10 min * Service Coverage Scope for Service URN (Brian) http://tools.ietf.org/id/draft-mongrain-ecrit-service-coverage-scope-urn/ Intention: Discuss new draft 10 min * A LoST extension to support return of complete and similar locatio= n info (Brian) http://tools.ietf.org/id/draft-marshall-ecrit-similar-location Intention: Discussion of changes to draft 5 min * Discussion From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= oger Marshall Sent: Wednesday, July 17, 2013 3:07 PM To: 'ecrit@ietf.org' Subject: [Ecrit] Ecrit agenda for the IETF87 Berlin meeting See the agenda below, which is also posted in the Meeting Materials Manager= , http://www.ietf.org/proceedings/87/agenda/agenda-87-ecrit ECRIT Agenda - 13:00-15:00, Monday, July 29, 2013 Berlin 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall) 20 min * Additional Data related to an Emergency Call (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss latest changes and if ready for WGLC 15 min. * Trustworthy Location Information (Bernard) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss impact of recent rewrite 10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts us= ing the Session Initiation Protocol (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Intention: Discuss recent updates to draft 15 min * Internet Protocol-based In-Vehicle Emergency Call (Hannes) http://tools.ietf.org/id/draft-rosen-ecrit-ecall/ Intention: Discussion of draft & WG adoption question 10 min * A LoST extension to support return of complete and similar locatio= n info (Brian) http://tools.ietf.org/id/draft-marshall-ecrit-similar-location Intention: Discussion of changes to draft 15 min * eCall - background, current status, and requirements discussion li= nked to current ETSI work (Ban Al-Bakri) 10 min * Service Coverage Scope for Service URN (Brian) http://tools.ietf.org/id/draft-mongrain-ecrit-service-coverage-scope-urn/ Intention: Discuss new draft 10 min * Uniform Resource Name (URN) extension for automatic and manual Eme= rgency Services (Roland) draft-jesske-ecrit-ecall-urn-extension-01 Intention: Discussion of changes to draft 5 min * Open Discussion 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_FBD5AAFFD0978846BF6D3FAB4C892ACC39ED20SEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agenda bash: I’m= sending an updated ecrit agenda for this afternoon’s 13:00-15:00 mee= ting that includes:

 

-- one additional pres= entation item: ID presentation (second from end) that was requested prior.<= o:p>

-- updated presenters<= o:p>

-- revised ordering pe= r subjects

 

-roger.

 

 

See the agenda below, = which is also posted in the Meeting Materials Manager,

http://www.ietf.org/pr= oceedings/87/agenda/agenda-87-ecrit

 

 

ECRIT Agenda - 13:00-1= 5:00, Monday, July 29, 2013 Berlin

 

10 min * Agenda Bashin= g, Draft Status Update (Marc Linsner, Roger Marshall)

 

10 min * Additional Da= ta related to an Emergency Call (Brian)

http://datatracker.iet= f.org/doc/draft-ietf-ecrit-additional-data/

Intention: Discuss lat= est changes and if ready for WGLC

 

10 min * (Brian) Updat= ing Additional Data related to an Emergency Call using Subscribe/Notify (Br= ian)

http://tools.ietf.org/= id/draft-rosen-ecrit-addldata-subnot-00/

Intention: Discuss new= draft

 

15 min. * Trustworthy = Location Information (Bernard)

http://datatracker.iet= f.org/doc/draft-ietf-ecrit-trustworthy-location/

Intention: Discuss imp= act of recent rewrite

 

15 min * eCall - backg= round, current status, and requirements discussion linked to current ETSI w= ork (Ban Al-Bakri)

 

15 min * Internet Prot= ocol-based In-Vehicle Emergency Call (Randy)

http://tools.ietf.org/= id/draft-rosen-ecrit-ecall/

Intention: Discussion = of draft & WG adoption question

 

10 min * Uniform Resou= rce Name (URN) extension for automatic and manual Emergency Services (Rolan= d)

draft-jesske-ecrit-eca= ll-urn-extension-01

Intention: Discussion = of changes to draft

 

10 min * Common Alerti= ng Protocol (CAP) based Data-Only Emergency Alerts using the Session Initia= tion Protocol (Brian)

http://datatracker.iet= f.org/doc/draft-ietf-ecrit-data-only-ea/

Intention: Discuss rec= ent updates to draft

 

10 min * Service Cover= age Scope for Service URN (Brian)

http://tools.ietf.org/= id/draft-mongrain-ecrit-service-coverage-scope-urn/

Intention: Discuss new= draft

 

10 min * A LoST extens= ion to support return of complete and similar location info (Brian)

http://tools.ietf.org/= id/draft-marshall-ecrit-similar-location

Intention: Discussion = of changes to draft

 

5 min * Discussion

 

 

From: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: Wednesday, July 17, 2013 3:07 PM
To: 'ecrit@ietf.org'
Subject: [Ecrit] Ecrit agenda for the IETF87 Berlin meeting

 

See the agenda below, = which is also posted in the Meeting Materials Manager,

http://www.ietf.org/proceed= ings/87/agenda/agenda-87-ecrit

 

 

ECRIT Agenda - 13:00-15:00, Monday, July 2= 9, 2013 Berlin

 

10 min * Agenda Bashing, Draft Status Upda= te (Marc Linsner, Roger Marshall)

 

20 min * Additional Data related to an Eme= rgency Call (Brian)

http://datatracker.ietf.org/doc/draft-i= etf-ecrit-additional-data/

Intention: Discuss latest changes and if r= eady for WGLC

 

15 min. * Trustworthy Location Information= (Bernard)

http://datatracker.ietf.org/doc/dr= aft-ietf-ecrit-trustworthy-location/

Intention: Discuss impact of recent rewrit= e

 

10 min * Common Alerting Protocol (CAP) ba= sed Data-Only Emergency Alerts using the Session Initiation Protocol (Brian= )

http://datatracker.ietf.org/doc/draft-ietf= -ecrit-data-only-ea/

Intention: Discuss recent updates to draft=

 

15 min * Internet Protocol-based In-Vehicl= e Emergency Call (Hannes)

http://tools.ietf.org/id/draft-rosen-ecrit-ecall/

Intention: Discussion of draft & WG ad= option question

 

10 min * A LoST extension to support retur= n of complete and similar location info (Brian)

http://tools.ietf.org/id/draft-marshall-ec= rit-similar-location

Intention: Discussion of changes to draft<= o:p>

 

15 min * eCall - background, current statu= s, and requirements discussion linked to current ETSI work (Ban Al-Bakri)

 

10 min * Service Coverage Scope for Servic= e URN (Brian)

http://tools.ietf.org/id/draft-= mongrain-ecrit-service-coverage-scope-urn/

Intention: Discuss new draft

 

10 min * Uniform Resource Name (URN) exten= sion for automatic and manual Emergency Services (Roland)=

draft-jesske-ecrit-ecall-urn-extension-01<= o:p>

Intention: Discussion of changes to draft<= o:p>

 

5 min * Open Discussion<= /p>

CONFIDENTIALITY NOTICE: The information contained in this mess= age may be privileged and/or confidential. If you are not the intended reci= pient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or= copying of this communication or any attachment(s) is strictly prohibited.= If you have received this message in error, please notify the sender immed= iately, and delete it and all attachments from your computer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC39ED20SEAEXMB2telecomsy_-- From hgs@cs.columbia.edu Mon Jul 29 10:31:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0BB21F9F31 for ; Mon, 29 Jul 2013 10:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNvLpQ4w42AQ for ; Mon, 29 Jul 2013 10:31:30 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 57B7411E80D9 for ; Mon, 29 Jul 2013 10:29:11 -0700 (PDT) Received: from dhcp-56bd.meeting.ietf.org (dhcp-56bd.meeting.ietf.org [130.129.86.189]) (user=hgs10 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r6THSx12027942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 29 Jul 2013 13:29:01 -0400 (EDT) From: Henning Schulzrinne Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 29 Jul 2013 13:28:59 -0400 To: ECRIT Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Subject: [Ecrit] Service URNs for specialized law enforcement and similar services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:31:38 -0000 We discussed at length today how to provide URNs for direct access to = specialized first responder services. Here are some observations: (1) While there are some generic descriptions, such as "sheriff" or = "transit police", there are numerous variations by issues handled (e.g., = "special victims unit", "SWAT team", "US Postal Inspector") and = geography ("county police", "state police", "university campus police", = "park police", "military police"). There are no clear boundaries in some = cases between types of emergency handled and geography. For example, the = US Postal Inspector isn't restricted to US post offices and deals with a = wide variety of crimes, from mail fraud to mailing ricin. The FCC = enforcement bureau has badges and enforces, among other things, antenna = safety violations anywhere in the US. Geography often overlaps - the NJ Transit and Amtrak police both deal = with the North East Corridor and Penn Station. (2) Something we did not discuss: People often need to access "out of = area" services. For example, I might want to contact transit police = after I leave the train, e.g., if I saw something suspicious, want to = ask about a lost item or need to follow up on an earlier issue. In = particular, it must be possible to reach NJ state police even if I'm = just across the border in NY and I need to be able to reach the Amtrak = police when I'm on NJ Transit. This is obviously trivial with using = numbers, but it would be really confusing to be connected to NJ state = police if I just talked to the NY version. (3) We also didn't really discuss why we need a URN to begin with. I see = three reasons: (a) Automated location disclosure [and location-based routing] - you can = disclose location if it's below 'sos', but not with some random number. = That's both good and bad, as it is not clear that location and identity = disclosure are always desirable for these services. The legal status is = also different. (b) Automated discovery - I should be able to discover all emergency = services that are applicable to my area, as that's really painful right = now. At least in the US, numbers for these services are not widely known = (every sheriff's department has their own and so does every transit = police department). (c) Fall back - you can fall back to a generic emergency service if that = service doesn't handle the local area. However, that's not always = appropriate. If I'm *not* on the Columbia campus and call the Columbia = University police number about a lost item, I don't want to be connected = to 911. (4) Unlike 911, these numbers are often used for emergencies and = "business" non-emergency issues, such as reporting a crime that took = place in the past rather than just crimes in progress. I'll follow up with some opinions, but I hope this is reasonably = non-controversial. Henning= From ivo.sedlacek@ericsson.com Tue Jul 30 00:12:33 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6368521E80BB for ; Tue, 30 Jul 2013 00:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GycI+kf0wF+v for ; Tue, 30 Jul 2013 00:12:28 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DD59C11E81BC for ; Tue, 30 Jul 2013 00:12:27 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-33-51f7675a1e82 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 04.AD.11907.A5767F15; Tue, 30 Jul 2013 09:12:26 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.144]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Tue, 30 Jul 2013 09:12:26 +0200 From: Ivo Sedlacek To: Henning Schulzrinne , ECRIT Thread-Topic: [Ecrit] Service URNs for specialized law enforcement and similar services Thread-Index: AQHOjIGfOvNZ4Hf7PEiGRtTd1gey/Jl8zI3Q Date: Tue, 30 Jul 2013 07:12:25 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610110EE9F@ESESSMB301.ericsson.se> References: In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/mixed; boundary="_002_39B5E4D390E9BD4890E2B3107900610110EE9FESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA12SfyzUcRjH+3zv634t69shT6TNbWz6cX7MSptQabP8UaoZ1sY136Eku6Mx /XBkIW7MLL5thBtdZZFLxlQnNj9z1CWMJDRcplXOj6519/2cZf33ep73+3me7+d5vnyOSMl1 4ickpdCyJGmimCskyyNMNw5GxRnDvKbHDvgpqmdt/N4r1UQQEfJrTEuEqFRrxBkiSugfSycm XKNlngExwviBiSyUfFuJ0soKsnmZKCcjHwn4QPlC/fqEDeZdoJt8ys1HQr6I6kIwlb/Ew4EK wZ3uPGRxcSkJFGs62Qp76iR87W7jWdiOioCS6ioS5yOh1JRLYPaB3hET6yEpN5gzrLO1tlQo fCrWmnvyzQOOgybXw5IWUCdguWCUtSDKBfS/C9mxHMoRxmYqCfyh9vB5qI+L2QHmv/yxPsAV 9PfqCOxPgFpVH8KjdkJP+QxZhOyZLa2YLTZmiw3nJTDXy1h5P9RWLXIw74Gm0jyzX2jmHAQ9 T9a4DLujVgQv3y7wcNCIYHq87p/S3K4jcFCKIHNWaQ3qEczrlGxnETWMYDJPjIXXCFQLg1ws dCKYVbtgoQbBavkQK2xegmG37AYN/Wr2HXbUJfjQsMzD+auw0DSPMEtgdbSCgz1HYHlJwdZa rmJQNJOM9SpDihHWs506DCWtRVzMMljStVg5FQq1bWzPzRP9v1eggkH/o47HbDkXZhcwVFbY PECBjxBfTssvXonz8XqGzP+0VrPh14Lemfw7kDOfFDvaaiT9YSIqTppCX6bpZFoWLUtNpOUd iOALnDJRTZBCXFxHeo7vzlJ5uV7vkRqH9nY+Xk9fiT/m3jAY/CJ+xdFtLlqdIfZ85YtibzHZ mdmE02Lk90L0zeum0cFoMJ3quh/SmPaxc5tdh+GCoFEvcY7xKJsyhEvan5dsnB9ID9KGnh4N GH54VlQaeOjoT3fvN+TdHa3nbKLC/SLUVWJSHi/13seRyaV/AVOqyxWhAwAA Subject: Re: [Ecrit] Service URNs for specialized law enforcement and similar services X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 07:12:33 -0000 --_002_39B5E4D390E9BD4890E2B3107900610110EE9FESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, the issue occurs also outside of USA. I have given in past (see attached) the Czech republic and Poland cases of = PSAPs of different police forces which offer similar, but not completely th= e same, services in the same location.=20 The difference in offered services comes from different legal status of the= police forces: - the one established by national goverment is responsible all crimes - the one established by municipal authorities is responsible for minor cri= mes It would be good to cover those in the discussion as well. It might be good to extend the list to state: (5) in some countries, in a given location, there are several PSAPs of emer= gency services (e.g. police forces) which offer similar, but not completely= the same, service. A unique URN is needed for each of them. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of H= enning Schulzrinne Sent: 29. =E8ervence 2013 19:29 To: ECRIT Subject: [Ecrit] Service URNs for specialized law enforcement and similar s= ervices We discussed at length today how to provide URNs for direct access to speci= alized first responder services. Here are some observations: (1) While there are some generic descriptions, such as "sheriff" or "transi= t police", there are numerous variations by issues handled (e.g., "special = victims unit", "SWAT team", "US Postal Inspector") and geography ("county p= olice", "state police", "university campus police", "park police", "militar= y police"). There are no clear boundaries in some cases between types of em= ergency handled and geography. For example, the US Postal Inspector isn't r= estricted to US post offices and deals with a wide variety of crimes, from = mail fraud to mailing ricin. The FCC enforcement bureau has badges and enfo= rces, among other things, antenna safety violations anywhere in the US. Geography often overlaps - the NJ Transit and Amtrak police both deal with = the North East Corridor and Penn Station. (2) Something we did not discuss: People often need to access "out of area"= services. For example, I might want to contact transit police after I leav= e the train, e.g., if I saw something suspicious, want to ask about a lost = item or need to follow up on an earlier issue. In particular, it must be po= ssible to reach NJ state police even if I'm just across the border in NY an= d I need to be able to reach the Amtrak police when I'm on NJ Transit. This= is obviously trivial with using numbers, but it would be really confusing = to be connected to NJ state police if I just talked to the NY version. (3) We also didn't really discuss why we need a URN to begin with. I see th= ree reasons: (a) Automated location disclosure [and location-based routing] - you can di= sclose location if it's below 'sos', but not with some random number. That'= s both good and bad, as it is not clear that location and identity disclosu= re are always desirable for these services. The legal status is also differ= ent. (b) Automated discovery - I should be able to discover all emergency servic= es that are applicable to my area, as that's really painful right now. At l= east in the US, numbers for these services are not widely known (every sher= iff's department has their own and so does every transit police department)= . (c) Fall back - you can fall back to a generic emergency service if that se= rvice doesn't handle the local area. However, that's not always appropriate= . If I'm *not* on the Columbia campus and call the Columbia University poli= ce number about a lost item, I don't want to be connected to 911. (4) Unlike 911, these numbers are often used for emergencies and "business"= non-emergency issues, such as reporting a crime that took place in the pas= t rather than just crimes in progress. I'll follow up with some opinions, but I hope this is reasonably non-contro= versial. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_002_39B5E4D390E9BD4890E2B3107900610110EE9FESESSMB301ericsso_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 30 Jul 2013 07:12:24 GMT"; modification-date="Tue, 30 Jul 2013 07:12:24 GMT" Received: from esessmw0247.eemea.ericsson.se (153.88.115.93) by ESESSHC014.ericsson.se (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.2.318.1; Thu, 13 Dec 2012 14:22:36 +0100 Received: from sessmg10.ericsson.net (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.95) with Microsoft SMTP Server id 8.3.279.1; Thu, 13 Dec 2012 14:22:29 +0100 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id FF.DE.16113.496D9C05; Thu, 13 Dec 2012 14:22:29 +0100 (CET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92CE21F8920; Thu, 13 Dec 2012 05:22:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51D021F891F for ; Thu, 13 Dec 2012 05:22:25 -0800 (PST) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7t-JWbuA8nu for ; Thu, 13 Dec 2012 05:22:16 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A489121F8920 for ; Thu, 13 Dec 2012 05:22:15 -0800 (PST) Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 81.5F.24873.686D9C05; Thu, 13 Dec 2012 14:22:14 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.80]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.001; Thu, 13 Dec 2012 14:22:03 +0100 From: Ivo Sedlacek To: "ecrit@ietf.org" Subject: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos Thread-Index: Ac3ZNDemJoLW/FsDQJGuJ+8WXF/LOA== Sender: "ecrit-bounces@ietf.org" Date: Thu, 13 Dec 2012 13:22:02 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610103F703@ESESSMB301.ericsson.se> List-Help: List-Subscribe: , List-Unsubscribe: , Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Exchange-Organization-AuthSource: esessmw0247.eemea.ericsson.se X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-brightmail-tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+JvjW7btZMBBhcWqFo0LnrK6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujF1Pp7MXzLOtmNi0gK2BsdW0i5GTQ0LARGJl7ydWCFtM4sK9 9WxdjFwcQgKHGCV23FkL5SxmlNjwdRc7SBWbgJ7ExC1HwDpEBFQlNpxZyQhiCwskSbQd/8UC EU+X2Nd6hA3C1pP4cXMeM4jNAlT/pnEbWA2vgLfExcbrYHFGAVmJq396weYwC4hL3Hoynwni IgGJJXvOM0PYohIvH/+DulRR4uOrfVD1+RKtB94xQswUlDg58wnLBEahWUhGzUJSNgtJGURc T+LZqVlQtrbEsoWvmSFsXYlLD9exIosvYGRfxciem5iZk15utIkRGPgHt/xW3cF455zIIUZp DhYlcV7rrXv8hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCyFmSLe7PxMv57YGhY9dr7VZFS UeUlHgaHn3f3MfEKTlVcv8Nmq74O65nMCv+W67KOwXOmH7ndU9Lu2cw+4YKWt0+VWsmXs/oC Fjdb54av4eHdd7NnzSrfaLe0xxuefIjVfZd15s+F298nME0xv9ckm2iyWfh3fxHTkmr+U3/+ 2st2Hva3CFZiKc5INNRiLipOBACzS7fmSgIAAA== x-auditid: c1b4fb3e-b7fd46d000003ef1-26-50c9d694ab5d x-originating-ip: [153.88.183.18] x-virus-scanned: amavisd-new at amsl.com list-id: x-mailman-version: 2.1.12 delivered-to: ecrit@ietfa.amsl.com x-beenthere: ecrit@ietf.org x-original-to: ecrit@ietfa.amsl.com list-post: x-spam-flag: NO list-archive: errors-to: ecrit-bounces@ietf.org dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1355404947; bh=ZQIghe/LLqUvxm2kNhqi6Qn9Cx3cjBSULaE7kSMJo2w=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=hBIia4ax2tcuVpb8ji1TD4orR5QFUP8dIM74g6ay9j1EOrl5gjo4u1CG7CUH3aw4r GQqMty0sWQhCyaaPKftnmNskAB2P9ng9pGqAhS3gkm+CuyPnusURijaqJpIXjGtHLc Un1tYR5U/A/dNe08bkC5itWMoFSPcWSZDsSQjWmM= x-spam-level: x-spam-status: No, score=-5.253 tagged_above=-999 required=5 tests=[AWL=0.995, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] x-spam-score: -5.253 Content-Type: multipart/mixed; boundary="_004_39B5E4D390E9BD4890E2B3107900610103F703ESESSMB301ericsso_" MIME-Version: 1.0 --_004_39B5E4D390E9BD4890E2B3107900610103F703ESESSMB301ericsso_ Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610103F703ESESSMB301ericsso_" --_000_39B5E4D390E9BD4890E2B3107900610103F703ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, in the Czech republic, the national regulator defined two police related em= ergency services: A) emergency service provided by the national police (number 158 in the pub= lic switched telephone network); and B) emergency service provided by the municipal police (number 156 in the pu= blic switched telephone network). The regulation is http://aplikace.mvcr.cz/archiv2008/sbirka/2007/sb043-07.p= df which lists the numbers 156 and 158 in section 4.5. with note 2) which s= tates "=C8=EDslo je n=E1rodn=EDm =E8=EDslem pro t=EDs=F2ov=E9 vol=E1n=ED" (= =3D the number is a national number for emergency calls). Is it appropriate to register the following URNs for those services with IA= NA? - urn:service:sos.police.national - The 'police.national' service refers to= the police department or other law enforcement authorities of the national= government. - urn:service:sos.police.municipal - The 'police.municipal' service refers = to the police department or other law enforcement authorities of the munici= pal authorities. Or should those be registered with a prefix indicating that those are appli= cable to Czech republic only, as other countries may have similar (but not = necessarily identical) services: - urn:service:sos.police.czech.national - The 'police.czech.national' servi= ce refers to the police department or other law enforcement authorities of = the national government. - urn:service:sos.police.czech.municipal - The 'police.czech.municipal' ser= vice refers to the police department or other law enforcement authorities o= f municipal authorities. I assume this question belongs to IANA, but as the expert reviewer most lik= ely will be from the ECRIT, I am sending it here. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer --_000_39B5E4D390E9BD4890E2B3107900610103F703ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-2" Content-ID: <59222A20F60CEA42AD55108AE0001D0C@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hello,

 

in the Czech republic, the national regulator def= ined two police related emergency services:

A) emergency service provided by the national pol= ice (number 158 in the public switched telephone network); and

B) emergency service provided by the municipal po= lice (number 156 in the public switched telephone network).

 

The regulation is http://aplikace.mvcr.cz/archiv2= 008/sbirka/2007/sb043-07.pdf which lists the numbers 156 and 158 in section= 4.5. with note 2) which states "=C8=EDslo je n=E1rodn=EDm =E8=EDslem = pro t=EDs=F2ov=E9 vol=E1n=ED" (=3D the number is a national number for emergency calls).

 

Is it appropriate to register the following URNs = for those services with IANA?

- urn:service:sos.police.national - The 'police.n= ational' service refers to the police department or other law enforcement a= uthorities of the national government.

- urn:service:sos.police.municipal - The 'police.= municipal' service refers to the police department or other law enforcement= authorities of the municipal authorities.

 

Or should those be registered with a prefix indic= ating that those are applicable to Czech republic only, as other countries = may have similar (but not necessarily identical) services:

- urn:service:sos.police.czech.national - The 'po= lice.czech.national' service refers to the police department or other law e= nforcement authorities of the national government.

- urn:service:sos.police.czech.municipal - The 'p= olice.czech.municipal' service refers to the police department or other law= enforcement authorities of municipal authorities.

 

I assume this question belongs to IANA, but as th= e expert reviewer most likely will be from the ECRIT, I am sending it here.=

 

Kind regards

 

Ivo Sedlacek

 

 

This Communication is Confidential. We only send = and receive email on the basis of the terms set out at www.ericsson.com/ema= il_disclaimer

--_000_39B5E4D390E9BD4890E2B3107900610103F703ESESSMB301ericsso_-- --_004_39B5E4D390E9BD4890E2B3107900610103F703ESESSMB301ericsso_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=130; creation-date="Thu, 13 Dec 2012 13:22:36 GMT"; modification-date="Thu, 13 Dec 2012 13:22:36 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1h aWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZWNyaXQNCg== --_004_39B5E4D390E9BD4890E2B3107900610103F703ESESSMB301ericsso_-- --_002_39B5E4D390E9BD4890E2B3107900610110EE9FESESSMB301ericsso_-- From internet-drafts@ietf.org Tue Jul 30 05:11:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86D621F9FD8; Tue, 30 Jul 2013 05:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIakxDTbzK3A; Tue, 30 Jul 2013 05:11:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B00F21F9473; Tue, 30 Jul 2013 05:11:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730121138.13724.76244.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 05:11:38 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-trustworthy-location-07.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:11:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Trustworthy Location Author(s) : Hannes Tschofenig Henning Schulzrinne Bernard Aboba Filename : draft-ietf-ecrit-trustworthy-location-07.txt Pages : 23 Date : 2013-07-30 Abstract: For some location-based applications, such as emergency calling or roadside assistance, the trustworthiness of location information is critically important. This document describes how to convey location in a manner that is inherently secure and reliable. 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-trustworthy-location-07 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 trac+ecrit@trac.tools.ietf.org Tue Jul 30 05:15:42 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4111E81D2 for ; Tue, 30 Jul 2013 05:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoXg5ngTtVyk for ; Tue, 30 Jul 2013 05:15:41 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3568F11E81CC for ; Tue, 30 Jul 2013 05:15:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:59000 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1V48pw-0003uq-Hd; Tue, 30 Jul 2013 14:15:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Tue, 30 Jul 2013 12:15:32 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/ecrit/trac/ticket/15#comment:1 Message-ID: <080.793e37f0d10e61d161cf3d077f3bc0c6@trac.tools.ietf.org> References: <065.2ea1df71cf6659845d5501a8885c7938@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <065.2ea1df71cf6659845d5501a8885c7938@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130730121541.3568F11E81CC@ietfa.amsl.com> Resent-Date: Tue, 30 Jul 2013 05:15:40 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #15: Definitions of Place Shifting, Time Shifting, Location Theft and Location swapping X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:15:42 -0000 #15: Definitions of Place Shifting, Time Shifting, Location Theft and Location swapping Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From khwolf1@gmail.com Wed Jul 31 00:24:02 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AC421E8090 for ; Wed, 31 Jul 2013 00:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdE+SLTNsLPw for ; Wed, 31 Jul 2013 00:24:00 -0700 (PDT) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 36D4F21E8051 for ; Wed, 31 Jul 2013 00:24:00 -0700 (PDT) Received: by mail-vb0-f42.google.com with SMTP id e12so351995vbg.1 for ; Wed, 31 Jul 2013 00:23:58 -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=/eBZ4UeEAfYRsAIHwmcMcbOmFQpV0YpUgo9AFaQX5wk=; b=uiXhLVthyM1dqtib+QlwFRfpvrvWmwXJLr3CrvZgxR3aN+lhsTfKGpkCALG21Ji8Y/ M9koIGxJHfoJkWcWUezx95gXN2jeBVElF4r4tbVAiOg5cX4FU/Tt3ao37lEG0d69qKCf ot3JP9uMdkyBKh3lJo4reZQTdzuKv5DCeJrzDhUiyPGWlFLotYG4Js/3NrRm+h/+38NR Zed7j97i2suldHTVJbg6qWvaghGqI6I80uAS8Bg0c+AAv2nZdV8OASj7VW6bzddpgZuD +4CiySH6FRh1IlbTfr9fdd+1Rut9i2ZXrL2KhiuF/p8YX44JHVy3BUq2Hbyl681GQeD2 6hIw== MIME-Version: 1.0 X-Received: by 10.220.173.72 with SMTP id o8mr11040717vcz.75.1375255437860; Wed, 31 Jul 2013 00:23:57 -0700 (PDT) Received: by 10.220.173.5 with HTTP; Wed, 31 Jul 2013 00:23:57 -0700 (PDT) In-Reply-To: <6C467183-6A62-477D-ADEB-3C10229C0788@neustar.biz> References: <280B2BB7-471B-4539-A269-74FEAB469C95@neustar.biz> <3E394609-851B-40C4-B499-D5024859147D@neustar.biz> <6C467183-6A62-477D-ADEB-3C10229C0788@neustar.biz> Date: Wed, 31 Jul 2013 09:23:57 +0200 Message-ID: From: Karl Heinz Wolf To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=089e0149c390d967b804e2c99b21 Cc: "ecrit@ietf.org WG" Subject: Re: [Ecrit] LoST recursion and Forest Guides X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:24:02 -0000 --089e0149c390d967b804e2c99b21 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jul 25, 2013 at 3:55 PM, Rosen, Brian wrot= e: > No, it's just a LoST server that knows about trees its in. Nothing more= , > nothing less. > > It might be run by the access network or, in the case of > urn:service:sos, the local emergency authorities. > > It's just in a tree (or perhaps more than one tree if it serves multiple > "top level" services). It doesn't know about forest guides unless it is = at > the top of the tree (which might be common for some places with > urn:service:sos where the "tree" is one level, one server). > > If it doesn't know a mapping, if refers/recurs up the tree. If it's at > the top of the tree (a root server), it uses mappings it obtains from a F= G > to refer/recur to another tree. > Brian, seems that the architecture you are talking about is somehow differnet from RFC 5582, so could you please point me to the document describing your architecture so that I can follow up better? Thank you. > Unless it's at the top of the tree, it's only sending its service boundar= y > and URI to its parent. That's not LoST sync really because it's only one > way. It refers anything it isn't authoritative for to its parent, but > doesn't have any coverage info from the parent. It doesn't need any. > LoST sync can also be used to push coverage reagions up a tree. karl > > Brian > > On Jul 25, 2013, at 6:47 AM, Karl Heinz Wolf wrote: > > On Wed, Jul 24, 2013 at 3:25 PM, Rosen, Brian = wrote: > >> If there is a service for urn:service:foo, the local LoST server knows >> how to serve it, or knows how to refer to some entity that can get it. >> > > Sounds to me that the local LoST server would then actually be a mapping > server + forest guide. Who should actually operate the local LoST server? > Would the operator of the local urn:service:sos mapping server of a count= y > really want to peer with all other service operators like urn:service:foo > to exchange mappings via LoST sync so that the local LoST server is able = to > know how to serve them, as you mentioned? Anyway, this seems like lots of > peering agreements. > > Best, > Karl > > >> You can't iterate up the urn:service:sos tree looking for >> urn:service:foo. >> > >> The alternatives to searching bottom up is that the FG has to be >> expensive, like the DNS root - very widely replicated and dispersed. I >> don't think that is deployable. If the FG is only used when you need to >> cross trees (a query out of area), it's much less costly, much >> > more deployable. This also applies to intermediate LoST servers. If >> the path is top down, all the intermediate servers need to be public. >> >> I want the FG to be able to refuse queries that are from entities it >> does not know (it knows the leaves in the tree below it and the FGs it >> peers with). That is much, much more deployable. >> >> The FG can't be a public resource in my opinion. We don't have >> organizations who would be willing to deploy those kinds of services for >> free like we did for DNS. >> >> A public resource as attractive as an FG (or intermediate servers) that >> served urn:service:sos would need to withstand the largest DDoS attacks >> possible. That is currently 300+ G and heading towards a terabit of att= ack >> traffic. If it's not public, it doesn't need that level of threat >> mitigation. >> >> The lowest level (the authoritative server) must be publicly >> accessible. No way to avoid that I think. I'm trying to figure out a w= ay >> to get the FG deployed without that level of expense. The lowest level = is >> somewhat less attractive of a target than an FG would be, but it still >> would need to have very significant DDoS mitigation. >> >> Brian >> >> >> On Jul 24, 2013, at 2:46 AM, Karl Heinz Wolf wrote: >> >> On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian wrote: >> >>> >>> If the local server didn't have the answer it could recur or iterate up >>> the tree. The client would never have to discover a resolver, the loca= l >>> server becomes one. >>> >> >> Brian, >> >> so you suggest that all queries go to a local LoST server, consequently >> the urn:service:sos tree would be bothered for each query, also for >> urn:service:foo, which iterates up the urn:service:sos tree, until reach= ing >> the forest guide that is able to tell the tree for service foo? >> >> When you say that the local lost server becomes a resolver, I wonder >> what ist the advantage of discovering a local LoST server? A resolver wi= ll >> verly likely have the responses of all the "local" services in its cache >> (urn:service:sos as well as any other), and all the other queries can be >> directed to the right tree via forest guides, without bothering the >> urn:service:sos tree at all. >> >> Best, >> Karl >> >> >>> On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf wrote= : >>> >>> On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian >> > wrote: >>> >>>> I want to have LoST discovery find a local LoST server, which nearly >>>> always has the answer you want. No FG, no real resolvers. >>>> >>> >>> Brian, thanks for your answer. So this local LoST server would then be >>> a LoST mapping server for a specific reagion and a particular service (= e.g. >>> urn:service:sos), do I understand this correctly? Then the client would >>> have to discover a real LoST resolver as well which it has to consult f= or >>> other services. >>> >>> If the local LoST server doesn't have the answer, then we get to the >>>> forest. If your local LoST server doesn't have the answer, it's next = most >>>> likely that you need some adjacent server. So walk up the tree a leve= l and >>>> find it. >>>> >>>> If something is broken, like the seeker for some reason isn't >>>> actually local, then you might need to go all the way up to the root o= f the >>>> tree, and across (using the FG), and down another tree. This should b= e >>>> really rare, but it can happen. >>>> >>>> Each server in the tree knows the leaves below (coverage and URI) so >>>> it can recurse or iterate down, and it knows the URI of the next level= up >>>> so it can recurse or iterate up the tree. That has to work, or the FG >>>> would have a zillion one level trees. It doesn't, so the trees have >>>> intermediate servers that know about the leaves at their level, and ca= n >>>> recure/iterate up. >>>> >>>> I don't want to see devices start at the FG always. That would mean >>>> that the FG is in the path of every emergency call (ignoring caching, = which >>>> obviously helps a lot). That's not a good design. Stay local, and us= e the >>>> forest only when you have to go out of area for some reason. >>>> >>> >>> Does this mean the architecture of RFC 5582 is going to be updaded? >>> After all, this architecture is along the lines of the DNS system, wher= e >>> queries would also always start at the DNS root servers when ignoring >>> caching. >>> >>> Best, >>> Karl >>> >>> >>> >>>> >>>> >>>> On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf >>>> wrote: >>>> >>>> On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian < >>>> Brian.Rosen@neustar.biz> wrote: >>>> >>>>> >>>>> This means that the national forest guide must be prepared to answer >>>>> queries from any device at any time. In particular, it has to be siz= ed for >>>>> the worst case scenario where a very large number of devices make req= uests >>>>> of it, and it cannot refuse a request from any source (as a practical >>>>> matter). This makes it a very attractive DDoS target. In fact, I wo= uld >>>>> argue that a great number of implementations will simply start all qu= eries >>>>> at the top of the tree in all cases, since the forest guide URI will = become >>>>> well known quickly. >>>>> >>>> >>>> Brian, >>>> >>>> I got a bit confused here and I probably missed the discussion on the >>>> issue. However, the mapping architecture in RFC 5582 describes that a >>>> seeker queries a resolver, the resolver consults a forest guide and th= en >>>> goes to the root of the appropriate tree. So I don=92t see how the RFC= 5582 >>>> architecture should work without the forest guide URI to be known by >>>> resolvers. Moreover, since the forest guide points to the root of the = tree, >>>> the query has to start at the root. Or are you talking about some priv= ate >>>> LoST deployments inside the NENA network where some other mechanisms a= nd >>>> architectures apply? >>>> >>>> Best, >>>> Karl >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >> >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > --089e0149c390d967b804e2c99b21 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 25, 2013 at 3:55 PM, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:
No, it's just a LoST server that knows about trees its in. =A0Nothing m= ore, nothing less.

It might be run by the access network or, in the case of urn:service:s= os, the local emergency authorities.

It's just in a tree (or perhaps more than one tree if it serves mu= ltiple "top level" services). =A0It doesn't know about forest= guides unless it is at the top of the tree (which might be common for some= places with urn:service:sos where the "tree" is one level, one server).

If it doesn't know a mapping, if refers/recurs up the tree. =A0If = it's at the top of the tree (a root server), it uses mappings it obtain= s from a FG to refer/recur to another tree.

Brian, seems that the architecture you are talking about is = somehow differnet from RFC 5582, so could you please point me to the docume= nt describing your architecture so that I can follow up better? Thank you.<= br>
=A0
Unless it's at the top of the tree, it's only sending its serv= ice boundary and URI to its parent. =A0That's not LoST sync really beca= use it's only one way. =A0It refers anything it isn't authoritative= for to its parent, but doesn't have any coverage info from the parent. =A0It doesn't need any.

<= /div>
LoST sync can also be used to push coverage reagions up a tree.
karl
=A0

Brian


On Wed, Jul 24, 2013 at 3:25 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
If there is a service for urn:service:f= oo, the local LoST server knows how to serve it, or knows how to refer to s= ome entity that can get it.

Sounds to me that the local LoST server would then actually be a mappi= ng server + forest guide. Who should actually operate the local LoST server= ? Would the operator of the local urn:service:sos mapping server of a count= y really want to peer with all other service operators like urn:service:foo to exchange mappings via LoST sync = so that the local LoST server is able to know how to serve them, as you men= tioned? Anyway, this seems like lots of peering agreements.

Best,
Karl
=A0
You can't iterate up the urn:service:sos tree looking for urn:serv= ice:foo.

The alternatives to searching bottom up is that the FG has to be expen= sive, like the DNS root - very widely replicated and dispersed. =A0I don= 9;t think that is deployable. =A0If the FG is only used when you need to cr= oss trees (a query out of area), it's much less costly, much
more deployable. =A0This also applies to intermediate LoST servers. = =A0If the path is top down, all the intermediate servers need to be public.=

I want the FG to be able to refuse queries that are from entities it d= oes not know (it knows the leaves in the tree below it and the FGs it peers= with). =A0That is much, much more deployable.=A0

The FG can't be a public resource in my opinion. =A0We don't h= ave organizations who would be willing to deploy those kinds of services fo= r free like we did for DNS.

A public resource as attractive as an FG (or intermediate servers) tha= t served urn:service:sos would need to withstand the largest DDoS attacks p= ossible. =A0That is currently 300+ G and heading towards a terabit of attac= k traffic. =A0If it's not public, it doesn't need that level of threat mitigation.

The lowest level (the authoritative server) must be publicly accessibl= e. =A0No way to avoid that I think. =A0I'm trying to figure out a way t= o get the FG deployed without that level of expense. =A0The lowest level is= somewhat less attractive of a target than an FG would be, but it still would need to have very significant DDoS miti= gation.

Brian


On Jul 24, 2013, at 2:46 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Tue, Jul 23, 2013 at 2:45 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

If the local server didn't have the answer it could recur= or iterate up the tree. =A0The client would never have to discover a resol= ver, the local server becomes one.=A0

Brian,

so you suggest that all queries go to a local LoST server, consequentl= y the urn:service:sos tree would be bothered for each query, also for urn:s= ervice:foo, which iterates up the urn:service:sos tree, until reaching the = forest guide that is able to tell the tree for service foo?

When you say that the local lost server becomes a resolver, I wonder w= hat ist the advantage of discovering a local LoST server? A resolver will v= erly likely have the responses of all the "local" services in its= cache (urn:service:sos as well as any other), and all the other queries can be directed to the right tree via forest gui= des, without bothering the urn:service:sos tree at all.

Best,
Karl


On Jul 23, 2013, at 3:04 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Mon, Jul 22, 2013 at 5:02 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
I want to have LoST discovery find a local LoST server, which nearly a= lways has the answer you want. =A0No FG, no real resolvers.
=A0
Brian, thanks for your answer. So this local LoST server would then be= a LoST mapping server for a specific reagion and a particular service (e.g= . urn:service:sos), do I understand this correctly? Then the client would h= ave to discover a real LoST resolver as well which it has to consult for other services.

If the local LoST server doesn't have the answer, then we get to t= he forest. =A0If your local LoST server doesn't have the answer, it'= ;s next most likely that you need some adjacent server. =A0So walk up the t= ree a level and find it.

If something is broken, like the seeker for some reason isn't actu= ally local, then you might need to go all the way up to the root of the tre= e, and across (using the FG), and down another tree. =A0This should be real= ly rare, but it can happen.

Each server in the tree knows the leaves below (coverage and URI) so i= t can recurse or iterate down, and it knows the URI of the next level up so= it can recurse or iterate up the tree. =A0That has to work, or the FG woul= d have a zillion one level trees. =A0It doesn't, so the trees have intermediate servers that know about = the leaves at their level, and can recure/iterate up. =A0

I don't want to see devices start at the FG always. =A0That would = mean that the FG is in the path of every emergency call (ignoring caching, = which obviously helps a lot). =A0That's not a good design. =A0Stay loca= l, and use the forest only when you have to go out of area for some reason.

Does this mean the architecture of RFC 5582 is going to be updaded? Af= ter all, this architecture is along the lines of the DNS system, where quer= ies would also always start at the DNS root servers when ignoring caching.

Best,
Karl

=A0

On Jul 22, 2013, at 4:55 AM, Karl Heinz Wolf <khwolf1@gmail.com> wrote:

On Wed, Jul 17, 2013 at 9:10 PM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:

This means that the national forest guide must be prepared to answer q= ueries from any device at any time. =A0In particular, it has to be sized fo= r the worst case scenario where a very large number of devices make request= s of it, and it cannot refuse a request from any source (as a practical matter). =A0This makes it a very attractiv= e DDoS target. =A0In fact, I would argue that a great number of implementat= ions will simply start all queries at the top of the tree in all cases, sin= ce the forest guide URI will become well known quickly.

Brian,

I got a bit confused here and I probably missed the discussion on the issue= . However, the mapping architecture in RFC 5582 describes that a seeker que= ries a resolver, the resolver consults a forest guide and then goes to the = root of the appropriate tree. So I don=92t see how the RFC5582 architecture should work without the forest = guide URI to be known by resolvers. Moreover, since the forest guide points= to the root of the tree, the query has to start at the root. Or are you ta= lking about some private LoST deployments inside the NENA network where some other mechanisms and architectures appl= y?

Best,
Karl

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


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




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


--089e0149c390d967b804e2c99b21-- From internet-drafts@ietf.org Wed Jul 31 04:45:09 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3A211E80E4; Wed, 31 Jul 2013 04:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OF96KZR7Xux; Wed, 31 Jul 2013 04:45:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2BA21F9DAA; Wed, 31 Jul 2013 04:45:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130731114507.1062.89644.idtracker@ietfa.amsl.com> Date: Wed, 31 Jul 2013 04:45:07 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-11.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:45:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens James Winterbottom Filename : draft-ietf-ecrit-additional-data-11.txt Pages : 82 Date : 2013-07-31 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call, the caller or the location which the PSAP may be able to use. This document describes data structures and a mechanism to convey such data to the PSAP. The mechanism uses a Uniform Resource Identifier (URI), which may point to either an external resource or an object in the body of the SIP message. The mechanism thus allows the data to be passed by reference (when the URI points to an external resource) or by value (when it points into the body of the message). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-11 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 bs7652@att.com Wed Jul 31 10:07:08 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7104F11E8101 for ; Wed, 31 Jul 2013 10:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTC8GGEGaQoE for ; Wed, 31 Jul 2013 10:06:57 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 2631021F8F32 for ; Wed, 31 Jul 2013 10:06:31 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 61449f15.0.5060579.00-283.13990353.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 31 Jul 2013 17:06:31 +0000 (UTC) X-MXL-Hash: 51f9441753428579-751ea45740206b85f0a30c701ebab204f402677c Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6VH6U5S004571 for ; Wed, 31 Jul 2013 13:06:30 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6VH6OHl004552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Jul 2013 13:06:25 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor) for ; Wed, 31 Jul 2013 17:06:12 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Wed, 31 Jul 2013 13:06:12 -0400 From: "STARK, BARBARA H" To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-additional-data-10: comments on data provider elements Thread-Index: Ac6OEDrgjythGmndTMus/OV+lhBf4Q== Date: Wed, 31 Jul 2013 17:06:11 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130317C8F@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.111.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=YP8oP26x c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=qNrsC2a8x_wA:10 a=vnYdWsK-GNEA:10 a=ofMgfj31e3cA:10 a=9Ax] X-AnalysisOut: [d0npj4SAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=_HXNQYFi-rsA:10 a=Ly5wNtV0GDuqd] X-AnalysisOut: [lXJz2sA:9 a=CjuIK1q_8ugA:10 a=4gnFQk1Vt_JULMZT:21 a=Tp04xI] X-AnalysisOut: [DEX3s9z-Ae:21] Subject: [Ecrit] draft-ietf-ecrit-additional-data-10: comments on data provider elements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:07:08 -0000 I finished my review of draft-ietf-ecrit-additional-data-10. I'm sending my= comments divided among 5 emails. These are miscellaneous comments on data = provider elements. Barbara ------------------- 3.1. Data Provider Information This block is intended to be provided by any service provider in the path of the call or the access network provider. It includes identification and contact information. This block SHOULD be provided by every service provider in the call path, and by the access network provider . Devices MAY use this block to provide identifying information. The MIME subtype is "application/ emergencyCall.ProviderInfo+xml". Comment 1: How are you expecting an access provider to know to include this block? Wha= t is the trigger? This could be a problematic recommendation as some access= providers are explicitly forbidden from altering anything in the IP payloa= ds of the packets they transport/route. If IP payload is encrypted, then it= can't be done. But if the expectation is that this would happen when provi= ding location (so it's in the Reference/Value Provided-By of supplied locat= ion), then that's ok but it might be useful to mention this. ------------------- 3.1.2. Data Provider ID Data Element: Data Provider ID Use : Conditional. Must be provided if the service provider is located in a jurisdiction that maintains such ids . Devices are not required to provide it. Description: A jurisdiction specific code for the provider shown in the element that created the structure of the call. This data SHOULD be provided if the local jurisdiction maintains such an ID list. For example, in North America, this would be a "NENA Company ID". Devices SHOULD NOT use this element. Comment 2: Needs to say something about access provider use. Comment 3: I don't think this sort of condition (dependency on whether some= undefined organization in undefined jurisdictions do or don't do something= ) belongs in a RFC. Compliance is difficult to ascertain. My opinion is tha= t this information would be better as guidance rather than normative. Comment 4: The first use of "provider" in Description may need to be more s= pecific. "Provider" as a stand-alone term is undefined, but it may be that = only service providers will have jurisdiction specific codes, and not neces= sarily an access network provider. -------------------- 3.1.5. Data Provider Contact URI Use: Required Description: For a service provider the contact SHOULD be a contact URI. This MUST be a SIP URI. If a telephone number is the contact address it should be provided in the form of sip:telephonenumber@serviceprovider:user=3Dphone. If the call is from a device, this would reflect the contact information of the owner of the device. When provided by a service provider, this would be a URI to a 24/7 support organization tasked to provide PSAP support for this emergency call. Comment 5: This is confusing. A ContactURI *should* be a ContactURI? What e= lse could it be? Comment 6: What is the antecedent of "This" (This MUST be a SIP URI)? Is "T= his" the optional contact URI from the previous sentence (if contact is Con= tactURI then it MUST be a SIP URI)? Comment 7: Is the 2nd should a normative SHOULD? Or is this more of "will" = or non-normative "may"? -------------------- 3.1.6. Data Provider Languages(s) Supported How Used by Call Taker: If call taker cannot speak language(s) supported by the service provider, a translation service will need to be added to the conversation. Comment 8: Is this really the call taker or maybe also someone else at PSAP= ? From bs7652@att.com Wed Jul 31 10:08:32 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9559B21E80DB for ; Wed, 31 Jul 2013 10:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L16ndQ5uF-t for ; Wed, 31 Jul 2013 10:08:24 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7A90421F86AE for ; Wed, 31 Jul 2013 10:08:23 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 68449f15.0.6539919.00-440.18005359.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 31 Jul 2013 17:08:23 +0000 (UTC) X-MXL-Hash: 51f944876e6f3df1-a0671f66bc14f9d16e4e5b72f05370c90e728b94 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6VH8Mrl006159 for ; Wed, 31 Jul 2013 13:08:22 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6VH8J5Q006130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Jul 2013 13:08:19 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor) for ; Wed, 31 Jul 2013 17:08:03 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Wed, 31 Jul 2013 13:08:03 -0400 From: "STARK, BARBARA H" To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-additional-data-10: service provider subscontractor Thread-Index: Ac6OEIEENnQrpZZyS3mjkh4ZLkfyoQ== Date: Wed, 31 Jul 2013 17:08:02 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130317CA8@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.111.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=WbS7nTdX c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=qNrsC2a8x_wA:10 a=FvzCDQIwRYgA:10 a=ofMgfj31e3cA:10 a=9Ax] X-AnalysisOut: [d0npj4SAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=-KXJSTBuv94A:10 a=Vptp3fKF6CAxC] X-AnalysisOut: [J5LAlsA:9 a=CjuIK1q_8ugA:10] Subject: [Ecrit] draft-ietf-ecrit-additional-data-10: service provider subscontractor X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:08:32 -0000 I have several comments around items related to service provider subcontrac= tor. -------------------- 3.1.4. Type of Data Provider Token: Service Provider Subcontractor Comment 9: This is a fuzzy concept to me. I really don't understand what th= is is. Which to me suggests it's ambiguous as to how or when to use it. Comment 10: Can a Service Provider Subcontractor only be a "Service Provide= r (Calling or Origination telecom SP), or can it also be one of the other t= ypes?, If it can be one of the other types, which value is to be used? Mean= ing of this Type element seems a bit overloaded to me. Token: Expert Advice Provider =20 Comment 11: Who does this provide advice to? ----------------------- 3.1.8. Subcontractor Principal=20 Data Element: Subcontractor Principal XML Element: Description: If the data provider is a subcontractor to another provider such as an access infrastructure provider or telematics provider, this element contains the DataProviderString of the service provider to indicate which provider the subcontractor is working for. This data is required if the Data Provider type is subcontractor . Comment 12: This element is not in xml in Section 6.1 Comment 13: There's no Use provided for this element. Comment 14: As commented above, I think the info that the type field is try= ing to convey is overloaded, by trying to also convey subcontracting. But = also, I'm not really understanding this subcontractor concept. Is this anyt= hing like a wholesale relationship (ISP provides access by wholesaling the = service of an access network provider)? Comment 15: Does the last sentence of Description belong in a Use statement= ? -------------------------- 3.1.9. Subcontractor Priority=20 Data Element: Subcontractor Priority Use: Required Comment 16: This element is not in xml in Section 6.1 Comment 17: Is this really Required, or is it Conditional (on Subcontractor= Principal being provided, or some other condition)? From bs7652@att.com Wed Jul 31 10:09:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6015311E81A2 for ; Wed, 31 Jul 2013 10:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFNXbbLezUSx for ; Wed, 31 Jul 2013 10:09:14 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 703C421E80F7 for ; Wed, 31 Jul 2013 10:09:03 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id fa449f15.0.6416340.00-464.17724200.nbfkord-smmo05.seg.att.com (envelope-from ); Wed, 31 Jul 2013 17:09:03 +0000 (UTC) X-MXL-Hash: 51f944af097a4a9d-8d0a793585ab2f0366b64302e55235f0c653b1e7 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6VH92nf006750 for ; Wed, 31 Jul 2013 13:09:03 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6VH8vak006707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Jul 2013 13:08:58 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi131.aldc.att.com (RSA Interceptor) for ; Wed, 31 Jul 2013 17:08:43 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Wed, 31 Jul 2013 13:08:43 -0400 From: "STARK, BARBARA H" To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-additional-data-10: soft client as device Thread-Index: Ac6OEJs7k9t0cPxpTQuRI+IyUmp0rw== Date: Wed, 31 Jul 2013 17:08:42 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130317CBE@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.111.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=qNrsC2a8x_wA:10 a=1k7-LZXC-hUA:10 a=ofMgfj31e3cA:10 a=9Ax] X-AnalysisOut: [d0npj4SAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=esOR6Bu4smEA:10 a=mtWgtnttA9sms] X-AnalysisOut: [x7n4N4A:9 a=CjuIK1q_8ugA:10] Subject: [Ecrit] draft-ietf-ecrit-additional-data-10: soft client as device X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:09:26 -0000 There are a couple of places where it seems like a soft client can't proper= ly describe itself Figure 5 : Device Classification Registry Comment 18: It seems to me that a soft client might know that it is a soft = client and what its underlying OS is, but it may not know what type of comp= uting device it is on. Should there be any less specific choices for such c= ases, like "Soft client, computing device unknown"? ------------ 3.3.5. Type of Device Identifier Comment 19: If the call is from a soft client, is it expected that the soft= client know this info about the underlying computing device? From bs7652@att.com Wed Jul 31 10:09:45 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAF321E80FD for ; Wed, 31 Jul 2013 10:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OhW60ruta0G for ; Wed, 31 Jul 2013 10:09:38 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 67BA521E80DE for ; Wed, 31 Jul 2013 10:09:25 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 4c449f15.0.5062380.00-335.13995532.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 31 Jul 2013 17:09:26 +0000 (UTC) X-MXL-Hash: 51f944c61dd1c8db-b370993da65cbd3c0976c30fe004970ec9dd3717 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6VH9N9E007061 for ; Wed, 31 Jul 2013 13:09:23 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6VH9JRJ007001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Jul 2013 13:09:20 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by alpi133.aldc.att.com (RSA Interceptor) for ; Wed, 31 Jul 2013 17:09:09 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0342.003; Wed, 31 Jul 2013 13:09:09 -0400 From: "STARK, BARBARA H" To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-additional-data-10: mandatory elements in blocks Thread-Index: Ac6OEKbOIQwHJMBLRa2SBTmbqdFMVg== Date: Wed, 31 Jul 2013 17:09:08 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130317CDF@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.111.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=YP8oP26x c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=qNrsC2a8x_wA:10 a=PsnWzLtaR6kA:10 a=ofMgfj31e3cA:10 a=9Ax] X-AnalysisOut: [d0npj4SAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=2POlmEBW2eUA:10 a=_L9Q3VuVd4Q99] X-AnalysisOut: [UNe08oA:9 a=CjuIK1q_8ugA:10] Subject: [Ecrit] draft-ietf-ecrit-additional-data-10: mandatory elements in blocks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:09:45 -0000 Comments related to blocks with no mandatory elements. The Use statements for an element should not be considered a statement as t= o whether the block itself is mandatory or optional. Bock usage/inclusion U= se statements need to be elsewhere. So Use of an element is restricted to u= se of that element within a block that exists. ------------- 3.3. Device Information Comment 20: It's sort of weird that there's not a single required element f= or this block. But, ok. Does this mean it's possible to have the block pres= ent with nothing in it? -------------- 3.4.1. xCard for Subscriber's Data Use: Conditional : Some services (e.g., prepaid phones, initialized phones, etc.) may not have this information. Comment 21: What's the condition? Or is it really just Optional? As with DeviceInfo block, there are no required elements. But in this case,= this is the only possible element. So it seems that if a Subscriber block = exists, then this SubscriberData element is Required. Otherwise it makes no= sense for the Subscriber block to exist. -------------- 3.5.1. Comment Data Element: EmergencyCall.Comment Use: Optional Comment 22: Again, it makes no sense for the one possible element of a bloc= k to be optional when that block is present. This is a statement about the = existence of this element in the block and not about the block itself. All = blocks are effectively optional. From bs7652@att.com Wed Jul 31 10:11:32 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FDC21F8F32 for ; Wed, 31 Jul 2013 10:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jz5xI5Zgagv for ; Wed, 31 Jul 2013 10:11:24 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 797CA21F9343 for ; Wed, 31 Jul 2013 10:11:16 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 43549f15.0.5063540.00-333.13998832.nbfkord-smmo07.seg.att.com (envelope-from ); Wed, 31 Jul 2013 17:11:16 +0000 (UTC) X-MXL-Hash: 51f945340c500d6e-5866273df1668be276bf93bece04e00cade2d574 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6VHBFvI008916 for ; Wed, 31 Jul 2013 13:11:16 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6VHB9dL008842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Jul 2013 13:11:10 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by alpi133.aldc.att.com (RSA Interceptor) for ; Wed, 31 Jul 2013 17:10:47 GMT Received: from GAALPA1MSGUSR9L.ITServices.sbc.com ([130.8.36.69]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.02.0342.003; Wed, 31 Jul 2013 13:10:47 -0400 From: "STARK, BARBARA H" To: "ecrit@ietf.org" Thread-Topic: draft-ietf-ecrit-additional-data-10: Comments that shouldn't be controversial Thread-Index: Ac6OEOSqFFeQiqM6RDeMCKvb/8HM6w== Date: Wed, 31 Jul 2013 17:10:45 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61130317D01@GAALPA1MSGUSR9L.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.111.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=YP8oP26x c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=qNrsC2a8x_wA:10 a=TtRkBHEu1jQA:10 a=ofMgfj31e3cA:10 a=9Ax] X-AnalysisOut: [d0npj4SAA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=VKpzcmLlYEkA:10 a=weQFf2NtTvIZe] X-AnalysisOut: [XWb0GwA:9 a=CjuIK1q_8ugA:10] Subject: [Ecrit] draft-ietf-ecrit-additional-data-10: Comments that shouldn't be controversial X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:11:32 -0000 I've grouped all of my comments that I don't expect to be controversial (or= to require much discussion) in this email. I also provided the authors with a set of spelling errors that I'm not goin= g to send to the list. ---------- 2. Terminology 'Conditional': means they must be present unless the specified condition is met, in which case the they may be present.=20 Comment 23: "unless the specified condition is met" is not right. One possi= bility would be "if the specific condition is met". ----------- 3.1.2. Data Provider ID Use : Conditional. Must be provided if the service provider is located in a jurisdiction that maintains such ids . Devices are not required to provide it. Description: A jurisdiction specific code for the provider shown in the element that created the structure of the call. This data SHOULD be provided if the local jurisdiction maintains such an ID list. For example, in North America, this would be a "NENA Company ID". Devices SHOULD NOT use this element. Comment 24: Normative language from Description belongs in Use ------------ 3.1.6. Data Provider Languages(s) Supported Use: Conditional=20 Description: The language used by the entity at the Data Provider Contact URI as an alpha 2-character code as defined in ISO 639-1:2002 Codes for the representation of names of languages -- Part 1: Alpha-2 code Multiple instances of this element may occur. Order is significant; preferred language should appear first. This data is required if a Data Provider Contact URI is provided.=20 The content must reflect the languages supported at the contact URI. Comment 25: Conditional on what? Should the conditional sentence in Descrip= tion (penultimate sentence) be moved to Use to be consistent with other Use= fields? Comment 26: Since Contact URI is required, and this field is conditional up= on a required field, doesn't that make this required? ------------ 3.3.6. Device/Service Specific Additional Data Structure VEDs / VEDS Comment 26: I don't know this acronym. Can you spell it out? And use it con= sistently (VEDs or VEDS)? ------------ 7. Security Considerations PKI Comment 27: Spell this out. From gunnar.hellstrom@omnitor.se Wed Jul 31 11:41:44 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39C221F99C1 for ; Wed, 31 Jul 2013 11:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVL0Vw36iF0M for ; Wed, 31 Jul 2013 11:41:39 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id BB9C421F9A3B for ; Wed, 31 Jul 2013 11:41:31 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Wed, 31 Jul 2013 20:41:21 +0200 (CEST) Received: from [192.168.43.175] (109.58.145.63.bredband.tre.se [109.58.145.63]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 64A2B3A160 for ; Wed, 31 Jul 2013 20:41:21 +0200 (CEST) Message-ID: <51F95A4E.4070408@omnitor.se> Date: Wed, 31 Jul 2013 20:41:18 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ecrit@ietf.org References: <2D09D61DDFA73D4C884805CC7865E61130317CA8@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130317CA8@GAALPA1MSGUSR9L.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10: service provider subscontractor X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 18:41:44 -0000 Barbara and Hannes, The service provider topic was up for discussion between April 30 and May 6, under the subject "draft-ietf-ecrit-additional-data-07". I do not think the discussions and proposals at that time led to any modifications to the draft. I also have a feeling that the specification is "overloaded" in this area, but I would like to see comments from people closer to operations about the usefulness of the values and subdivisions in the service provider area. Please review also these earlier comments together with Barbara's new. Regards Gunnar On 2013-07-31 19:08, STARK, BARBARA H wrote: > I have several comments around items related to service provider subcontractor. > -------------------- > 3.1.4. Type of Data Provider > Token: Service Provider Subcontractor > Comment 9: This is a fuzzy concept to me. I really don't understand what this is. Which to me suggests it's ambiguous as to how or when to use it. > Comment 10: Can a Service Provider Subcontractor only be a "Service Provider (Calling or Origination telecom SP), or can it also be one of the other types?, If it can be one of the other types, which value is to be used? Meaning of this Type element seems a bit overloaded to me. > > Token: Expert Advice Provider > Comment 11: Who does this provide advice to? > ----------------------- > 3.1.8. Subcontractor Principal > > Data Element: Subcontractor Principal > > XML Element: > > Description: If the data provider is a subcontractor to another > provider such as an access infrastructure provider or telematics > provider, this element contains the DataProviderString of the > service provider to indicate which provider the subcontractor is > working for. This data is required if the Data Provider type is > subcontractor . > > Comment 12: This element is not in xml in Section 6.1 > Comment 13: There's no Use provided for this element. > Comment 14: As commented above, I think the info that the type field is trying to convey is overloaded, by trying to also convey subcontracting. But also, I'm not really understanding this subcontractor concept. Is this anything like a wholesale relationship (ISP provides access by wholesaling the service of an access network provider)? > Comment 15: Does the last sentence of Description belong in a Use statement? > -------------------------- > 3.1.9. Subcontractor Priority > > Data Element: Subcontractor Priority > > Use: Required > > Comment 16: This element is not in xml in Section 6.1 > Comment 17: Is this really Required, or is it Conditional (on SubcontractorPrincipal being provided, or some other condition)? > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit