From christer.holmberg@ericsson.com Tue Feb 4 22:51:51 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224261A004D for ; Tue, 4 Feb 2014 22:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8YRkEuegPUS for ; Tue, 4 Feb 2014 22:51:49 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 514841A0053 for ; Tue, 4 Feb 2014 22:51:47 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-90-52f1df8213ad Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 40.C2.04853.28FD1F25; Wed, 5 Feb 2014 07:51:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Wed, 5 Feb 2014 07:51:46 +0100 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: Additional Call Data: Info Package Thread-Index: Ac7hlsOij6NR7T2TRuS2sC2Tb3Y2RxAp9Juw Date: Wed, 5 Feb 2014 06:51:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D15A5FA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C519ED4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C519ED4@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D15A5FAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+JvjW7T/Y9BBqf/6FpMO3mZ2aJx0VNW ByaPJUt+MnnsaHjOHMAUxWWTkpqTWZZapG+XwJVxe801loKF7YwVXz++ZGlg3FjexcjJISFg IvGscR0LhC0mceHeerYuRi4OIYETjBJ79m9iBUkICSxilOiao93FyMHBJmAh0f1PGyQsIqAq seHMSkaQMLOAm8S6owkgYWEBfYn9t3awg4RFBAwk1u9Vhqg2kviwqxOsmkVARaL1oDhImFfA V+LDxfXMEHt8Je6+OQhmcwr4ScyeMZENxGYEOuz7qTVMIDazgLjErSfzmSAOFpBYsuc8M4Qt KvHy8T9WkPESAkoS07amQZTnSzyet5gJYpWgxMmZT1gmMIrOQjJpFpKyWUjKIOI6Egt2f2KD sLUlli18zQxjnznwmAlZfAEj+ypGyeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMB4O7jl t9EOxpN77A8xSnOwKInzXmetCRISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAqP9qWfYbE7HZ ub8/rXaOzpp3NbXZoSbhGENwYsZyFp3+Pw+yn83p1GyfHDot6YfMl/cvz6zvvv/7nkd1xy+7 eCPLvYrPd9zLnX0xzKj2a8OGmM5M63e9EtH23+44CATHSlR/ZmJZHTZv5s7YQ4ftb5WUvK9a ejAz5lR9tKihg9RhoxK/rRePKLEUZyQaajEXFScCAJK9ejKFAgAA Cc: "Rosen, Brian \(Brian.Rosen@neustar.biz\)" Subject: Re: [Ecrit] Additional Call Data: Info Package X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 06:51:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D15A5FAESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'd like to remind those interested about the Info Package text, for provid= ing additional call data, that I sent on the list in November (as requested= in Vancouver). Regards, Christer From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: 15. marraskuuta 2013 2:11 To: ecrit@ietf.org Cc: Rosen, Brian (Brian.Rosen@neustar.biz) Subject: [Ecrit] Additional Call Data: Info Package Hi, I put together the first version of an Info Package used to send Additional= Call Data for an emergency call, using INFO requests. At this point I have not written a draft, because I think it would fit in d= raft-rosen-ecrit-addldata-subnot, eventhough we may want to change/remove t= he "subnot" part in the draft name. Regards, Christer ----------------------------------------------- 5. Info Package for Additional Call Data 5.1. General The Info Package is used to update Additional Call Data related to an emerg= ency call, as described in [I-D.ietf-ecrit-additional-data]. 5.2. Overal Description TBD 5.3. Applicability The Info Package is only to be used within an emergency call. 5.4. Info Package Name The name of the Info Package is: infoAdditionaCallData 5.5. Info Package Parameters 5.5.1. General An Info Package name parameter, maxRate, is defined for the Info Package. T= he parameter can be inserted by a Public Safety Answering Point (PSAP), in = the Recv-Info header field of a response the INVITE request establishing th= e emergency call, to indicate the maximum number of INFO requests, associat= ed with the Info Package, that can be sent towards the PSAP per second. 5.5.2. ABNF maxRate =3D "maxRate" EQUAL (1*2DIGIT ["." 1*10DIGIT]) 5.6. SIP option tags No SIP option tags are defined for the Info Package. 5.7. INFO message body parts Additional Call Data is carried in the message body defined in section XXX. The MIME type value for the message body is: 'application/emergencyCall.Svc= Info+xml', defined in section XXX. The Content Disposition value for the message body, when associated with th= e Info Package, is "info-package" (see RFC 6086 [XX]). 5.8. Info Package usage restrictions No usage restrictions are defined for the Info Package. 5.9. Rate of INFO requests A PSAP can indicate the maximum rate for sending INFO requests associated w= ith the Info Package, using the maxRate Info Package parameter. In the absence of a maxRate parameter, INFO requests associated with the In= fo Package MUST NOT be sent more frequently than once every twenty seconds. 5.10. Security considerations Security considerations for the Info Package update mechanism are identical to those in [I-D.ietf-ecrit-additional-data]. ----------------------------------------------- --_000_7594FB04B1934943A5C02806D1A2204B1D15A5FAESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I’d like to remi= nd those interested about the Info Package text, for providing additional c= all data, that I sent on the list in November (as requested in Vancouver).<= o:p>

 

Regards,

 

Christer

 

From: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 15. marraskuuta 2013 2:11
To: ecrit@ietf.org
Cc: Rosen, Brian (Brian.Rosen@neustar.biz)
Subject: [Ecrit] Additional Call Data: Info Package

 

Hi,

 

I put together the first version of an Info Package = used to send Additional Call Data for an emergency call, using INFO request= s.

 

At this point I have not written a draft, because I = think it would fit in draft-rosen-ecrit-addldata-subnot, eventhough we may = want to change/remove the “subnot” part in the draft name.=

 

Regards,

 

Christer

 

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

 

5.  Info Package for Additional Call Data

 

5.1.  General

 

The Info Package is used to update Additional Call Data related to an em= ergency call, as described in [I-D.ietf-ecrit-additional-data].<= /span>

 

5.2.  Overal Description

 

TBD

 

5.3.  Applicability

 

The Info Package is only to be used within an emergency call.=

 

5.4.  Info Package Name

 

The name of the Info Package is: infoAdditionaCallData=

 

5.5.  Info Package Parameters

 

5.5.1.  General

 

An Info Package name parameter, maxRate, is defined for the Info Package= . The parameter can be inserted by a Public Safety Answering Point (PSAP), = in the Recv-Info header field of a response the INVITE request establishing the emergency call, to indicate the maximum nu= mber of INFO requests, associated with the Info Package, that can be sent t= owards the PSAP per second.

 

5.5.2.  ABNF

 

maxRate =3D "maxRate" EQUAL (1*2DIGIT ["." 1*10DIG=
IT])

 

5.6.  SIP option tags

 

No SIP option tags are defined for the Info Package.

 

5.7.  INFO message body parts

 

Additional Call Data is carried in the message body defined in section X= XX.

 

The MIME type value for the message body is: 'application/emergencyCall.= SvcInfo+xml', defined in section XXX.

 

The Content Disposition value for the message body, when associated with= the Info Package, is "info-package" (see RFC 6086 [XX]).

 

5.8.  Info Package usage restrictions

 

No usage restrictions are defined for the Info Package.

 

5.9.  Rate of INFO requests

 

A PSAP can indicate the maximum rate for sending INFO requests associate= d with the Info Package, using the maxRate Info Package parameter.

 

In the absence of a maxRate parameter, INFO requests associated with the= Info Package MUST NOT be sent more frequently than once every twenty secon= ds.

 

5.10.  Security considerations

 

Security considerations for the Info Package update mechanism are

   identical to those in [I-D.ietf-ecrit-additional-data].

 

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

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D15A5FAESESSMB209erics_-- From Hannes.Tschofenig@gmx.net Thu Feb 6 01:23:52 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFBA1A0374 for ; Thu, 6 Feb 2014 01:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0di-YACzX1i for ; Thu, 6 Feb 2014 01:23:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id E46011A0381 for ; Thu, 6 Feb 2014 01:23:42 -0800 (PST) Received: from 3capp-gmx-bs42.server.lan ([172.19.170.94]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MZic4-1VwQh115DS-00LZtu for ; Thu, 06 Feb 2014 10:23:41 +0100 Received: from [217.140.96.21] by 3capp-gmx-bs42.server.lan with HTTP; Thu Feb 06 10:23:41 CET 2014 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: ecrit@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Thu, 6 Feb 2014 10:23:41 +0100 (CET) Importance: normal Sensitivity: Normal Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-Provags-ID: V03:K0:OqdrDyIDl+nVRXe56E+F+dJEDRxNTZAv2CT8fEWvnK7 w0LMq8eNNpERMf+iDS6HzjWztTRhlsUpuRnHXpWHMXMfeDrKjh YyMYslVADFm0VfT4ju906Chkw3ii50cywAd9/3iBA/zecOoHUM NAnpYMdKXCHuV4/YdsLLrTvX4iZ29nYL7WgX0ptt3jmSWfQyhJ P5WqYulmC+YyIV9g5dEPicy2MCHA288W3FYXzpDRB5ypLJ9z7e Bv0OgACX7dlntGaOhlhRCDGhTO7SlxFdHtFTDcHG80CEsCHUrH dC7hR8= Subject: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 09:23:52 -0000 Hi all,=C2=A0 I am going to chair a BoF at the next IETF meeting related to Internet of = Things authentication and authorization. Folks in the group are currently c= ollecting use cases to derive requirements and the following emergency serv= ices related use case was brought forward. It would be great if the emergen= cy services community could take a look at it and give me feedback whether = you consider this use case realistic, whether you have heard about projects= working on these topics, whether you have seen other approaches providing = similar functionality, etc.=20 Here is the relevant text from http://tools.ietf.org/html/draft-seitz-core= -sec-usecases-00:=20 --------- 2.3. Personal Health Monitoring The use of wearable health monitoring technology is expected to grow stron= gly, as a multitude of novel devices are developed and marketed. These devi= ces are typically battery driven, and located physically on the user. They = monitor some bodily function, such as e.g. temperature, blood pressure, or = pulse. They are connected to the Internet, either through an intermediary b= ase-station or directly, using wireless technologies. Through this connecti= on they report the monitored data to some entity, which may either be the u= ser herself, or some medical personnel in charge of the user. Medical data has always been considered as very sensitive, and therefore r= equires good protection against unauthorized disclosure. A frequent, confli= cting requirement is the capability for medical personnel to gain emergency= access, even if no specific access rights exist. As a result, the importa= nce of secure audit logs increases in such scenarios. Since the users are n= ot typically trained in security (or even computer use), the configuration = must use secure default settings, and the interface must be well adapted to= novice users. Also the system must require very little maintenance, so e.= g. frequent changes of battery are unacceptable. 2.3.1 John and the heart rate monitor John has a heart condition, that can result in sudden cardiac arrests. He = therefore uses a device called HeartGuard that monitors his heart rate and = his position. In case of a cardiac arrest it automatically sends an alarm t= o an emergency service, transmitting John's current location. The device al= so functions as a implanted cardioverter defibrilator, i.e. it can deliver = a shock in order to try and normalize Johns heart rate. John can configure = additional persons that get notified in an emergency, for example his daugh= ter Jill. Furthermore the device stores data on John's heart rate, which ca= n later be accessed by a physician to assess the condition of John's heart.= However John is a rather private person, and is worried that Jill might us= e HeartGuard to monitor his location while there is no emergency. Furthermo= re he doesn't want his health insurance to get access to the HeartGuard dat= a, since they might refuse to renew his insurance if they decided he was to= o big a risk for them. --------- Ciao Hannes =C2=A0 From Brian.Rosen@neustar.biz Fri Feb 7 06:48:31 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930401A1F66 for ; Fri, 7 Feb 2014 06:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGn8Q29dnetw for ; Fri, 7 Feb 2014 06:48:29 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 16F5A1A1F77 for ; Fri, 7 Feb 2014 06:48:29 -0800 (PST) Received: from stntexhc10.cis.neustar.com (unknown [10.31.58.69]) by chihiron1.nc.neustar.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 0add_c266_a95ca410_c293_45a9_a590_25e968cf8018; Fri, 07 Feb 2014 09:48:19 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc10.cis.neustar.com ([169.254.4.83]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 09:48:19 -0500 From: "Rosen, Brian" To: Hannes Tschofenig Thread-Topic: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case Thread-Index: AQHPJBOjKeVvbZ7Y80mWku3vpJswiQ== Date: Fri, 7 Feb 2014 14:48:18 +0000 Message-ID: <67ADB9EF-85B0-46E5-B3EB-4967626C2E94@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.26] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 87ExVk2OumieuTfVM8yAQg== Content-Type: text/plain; charset="us-ascii" Content-ID: <2767FFCBE5903B4D96E76AC89DA4C9F0@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ecrit Subject: Re: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:48:31 -0000 We expect emergency services to have credentials in a PKI with known (per c= ountry) roots of trust. That will be helpful in this scenario. I think yo= u want to differentiate between unmediated and mediated access. Mediated a= ccess means there is some service between the device and the emergency serv= ices. That is the most common scenario today. Whether unmediated access b= ecomes common in the future is speculation. I kind of hope it does, but no= t too optimistic. Too much revenue opportunities are lost when vendors all= ow direct access. Brian On Feb 6, 2014, at 4:23 AM, Hannes Tschofenig w= rote: > Hi all,=20 >=20 > I am going to chair a BoF at the next IETF meeting related to Internet of= Things authentication and authorization. Folks in the group are currently = collecting use cases to derive requirements and the following emergency ser= vices related use case was brought forward. It would be great if the emerge= ncy services community could take a look at it and give me feedback whether= you consider this use case realistic, whether you have heard about project= s working on these topics, whether you have seen other approaches providing= similar functionality, etc.=20 >=20 > Here is the relevant text from http://tools.ietf.org/html/draft-seitz-cor= e-sec-usecases-00:=20 > --------- > 2.3. Personal Health Monitoring >=20 > The use of wearable health monitoring technology is expected to grow stro= ngly, as a multitude of novel devices are developed and marketed. These dev= ices are typically battery driven, and located physically on the user. They= monitor some bodily function, such as e.g. temperature, blood pressure, or= pulse. They are connected to the Internet, either through an intermediary = base-station or directly, using wireless technologies. Through this connect= ion they report the monitored data to some entity, which may either be the = user herself, or some medical personnel in charge of the user. >=20 > Medical data has always been considered as very sensitive, and therefore = requires good protection against unauthorized disclosure. A frequent, confl= icting requirement is the capability for medical personnel to gain emergenc= y access, even if no specific access rights exist. As a result, the import= ance of secure audit logs increases in such scenarios. Since the users are = not typically trained in security (or even computer use), the configuration= must use secure default settings, and the interface must be well adapted t= o novice users. Also the system must require very little maintenance, so e= .g. frequent changes of battery are unacceptable. >=20 > 2.3.1 John and the heart rate monitor >=20 > John has a heart condition, that can result in sudden cardiac arrests. He= therefore uses a device called HeartGuard that monitors his heart rate and= his position. In case of a cardiac arrest it automatically sends an alarm = to an emergency service, transmitting John's current location. The device a= lso functions as a implanted cardioverter defibrilator, i.e. it can deliver= a shock in order to try and normalize Johns heart rate. John can configure= additional persons that get notified in an emergency, for example his daug= hter Jill. Furthermore the device stores data on John's heart rate, which c= an later be accessed by a physician to assess the condition of John's heart= . However John is a rather private person, and is worried that Jill might u= se HeartGuard to monitor his location while there is no emergency. Furtherm= ore he doesn't want his health insurance to get access to the HeartGuard da= ta, since they might refuse to renew his insurance if they decided he was t= oo big a risk for them. >=20 > --------- >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Fri Feb 7 06:48:51 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32971A1F72 for ; Fri, 7 Feb 2014 06:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7kBbkeV3B1s for ; Fri, 7 Feb 2014 06:48:50 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id E909F1A1F65 for ; Fri, 7 Feb 2014 06:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1391784615; x=1707143181; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=u69wsdvyWZ ybeebh4qsQHvdx7hl5NkHDerKmuyL3fDI=; b=VXwInvIYtCSUHAdXrPq2h+G2p+ 0uj8ExvJD4X0mcjsiovuYmzbyGrZoxQfWEp0xmhA0oc5AW6BLroipIVhe+FA== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.34373884; Fri, 07 Feb 2014 09:50:14 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 09:48:32 -0500 From: "Rosen, Brian" To: Hannes Tschofenig Thread-Topic: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case Thread-Index: AQHPJBOrKeVvbZ7Y80mWku3vpJswiQ== Date: Fri, 7 Feb 2014 14:48:31 +0000 Message-ID: <9BFFBE9A-C80B-4601-9310-92F8384B7221@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.26] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: vg/mT3EUv6HxEycYwVZGHw== Content-Type: text/plain; charset="us-ascii" Content-ID: <3A3211029E15694E86B3F6A7EB4EEA6A@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ecrit Subject: Re: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:48:52 -0000 We expect emergency services to have credentials in a PKI with known (per c= ountry) roots of trust. That will be helpful in this scenario. I think yo= u want to differentiate between unmediated and mediated access. Mediated a= ccess means there is some service between the device and the emergency serv= ices. That is the most common scenario today. Whether unmediated access b= ecomes common in the future is speculation. I kind of hope it does, but no= t too optimistic. Too much revenue opportunities are lost when vendors all= ow direct access. Brian On Feb 6, 2014, at 4:23 AM, Hannes Tschofenig w= rote: > Hi all,=20 >=20 > I am going to chair a BoF at the next IETF meeting related to Internet of= Things authentication and authorization. Folks in the group are currently = collecting use cases to derive requirements and the following emergency ser= vices related use case was brought forward. It would be great if the emerge= ncy services community could take a look at it and give me feedback whether= you consider this use case realistic, whether you have heard about project= s working on these topics, whether you have seen other approaches providing= similar functionality, etc.=20 >=20 > Here is the relevant text from http://tools.ietf.org/html/draft-seitz-cor= e-sec-usecases-00:=20 > --------- > 2.3. Personal Health Monitoring >=20 > The use of wearable health monitoring technology is expected to grow stro= ngly, as a multitude of novel devices are developed and marketed. These dev= ices are typically battery driven, and located physically on the user. They= monitor some bodily function, such as e.g. temperature, blood pressure, or= pulse. They are connected to the Internet, either through an intermediary = base-station or directly, using wireless technologies. Through this connect= ion they report the monitored data to some entity, which may either be the = user herself, or some medical personnel in charge of the user. >=20 > Medical data has always been considered as very sensitive, and therefore = requires good protection against unauthorized disclosure. A frequent, confl= icting requirement is the capability for medical personnel to gain emergenc= y access, even if no specific access rights exist. As a result, the import= ance of secure audit logs increases in such scenarios. Since the users are = not typically trained in security (or even computer use), the configuration= must use secure default settings, and the interface must be well adapted t= o novice users. Also the system must require very little maintenance, so e= .g. frequent changes of battery are unacceptable. >=20 > 2.3.1 John and the heart rate monitor >=20 > John has a heart condition, that can result in sudden cardiac arrests. He= therefore uses a device called HeartGuard that monitors his heart rate and= his position. In case of a cardiac arrest it automatically sends an alarm = to an emergency service, transmitting John's current location. The device a= lso functions as a implanted cardioverter defibrilator, i.e. it can deliver= a shock in order to try and normalize Johns heart rate. John can configure= additional persons that get notified in an emergency, for example his daug= hter Jill. Furthermore the device stores data on John's heart rate, which c= an later be accessed by a physician to assess the condition of John's heart= . However John is a rather private person, and is worried that Jill might u= se HeartGuard to monitor his location while there is no emergency. Furtherm= ore he doesn't want his health insurance to get access to the HeartGuard da= ta, since they might refuse to renew his insurance if they decided he was t= oo big a risk for them. >=20 > --------- >=20 > Ciao > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Fri Feb 7 08:47:12 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD251A03EF for ; Fri, 7 Feb 2014 08:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVsw3TGguMcI for ; Fri, 7 Feb 2014 08:47:10 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 948D21A0177 for ; Fri, 7 Feb 2014 08:47:10 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta06.westchester.pa.mail.comcast.net with comcast id PRs31n0041ZXKqc56UnA5M; Fri, 07 Feb 2014 16:47:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id PUnA1n0053ZTu2S3hUnA3R; Fri, 07 Feb 2014 16:47:10 +0000 Message-ID: <52F50E0E.7070701@alum.mit.edu> Date: Fri, 07 Feb 2014 11:47:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ECRIT References: <67ADB9EF-85B0-46E5-B3EB-4967626C2E94@neustar.biz> In-Reply-To: <67ADB9EF-85B0-46E5-B3EB-4967626C2E94@neustar.biz> 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=1391791630; bh=ao2ASVi5sly3RdLwaVuisLM50WQEMjDYv2M3g8YywYE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FPonYacdiyFGRihMRd60dZpTNMaWH0vgxhPF84VoX7kKf9ROTtoLGf3aVfVU34BwE aFqSSZ6UJTFvHyw9iqXZYqvibgNx7fZPx7onjmyTQnb9jlU7P82XRpywpzJiGCDJZh HsD4O4F6MUqpku4xcmxJpBo8EWvj7B7f7VOg0VtbRVfqmBnAJFI4WJknBk/jRcB/a3 zvcxnvb6VRL2E1Ar0BVCLZsIgAVmNBE4Zi/pEmt7444NEXo47x36uI+oPNnTyNlvsG fjlZ8S0f4OP0D3W35hTclBrtKBcCickSEDMzcobLzNaRwfsOf3GbqDm6LDIZMKeVrb IVo6f0SdzqJCw== Subject: Re: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:47:12 -0000 Every time I see an add for home security services (where they want to tap my bank account every month even though I might go years without an event) I wonder why I can't have a home security system that makes automated emergency calls direct to the public emergency services. (And same for the "Help, I've fallen and can't get up" services.) Is there something that prevents that? I guess that a home security system that worked that way might result in many false alarms that might annoy the police or fire services. But is it illegal? Thanks, Paul On 2/7/14 9:48 AM, Rosen, Brian wrote: > We expect emergency services to have credentials in a PKI with known (per country) roots of trust. That will be helpful in this scenario. I think you want to differentiate between unmediated and mediated access. Mediated access means there is some service between the device and the emergency services. That is the most common scenario today. Whether unmediated access becomes common in the future is speculation. I kind of hope it does, but not too optimistic. Too much revenue opportunities are lost when vendors allow direct access. > > Brian > > On Feb 6, 2014, at 4:23 AM, Hannes Tschofenig wrote: > >> Hi all, >> >> I am going to chair a BoF at the next IETF meeting related to Internet of Things authentication and authorization. Folks in the group are currently collecting use cases to derive requirements and the following emergency services related use case was brought forward. It would be great if the emergency services community could take a look at it and give me feedback whether you consider this use case realistic, whether you have heard about projects working on these topics, whether you have seen other approaches providing similar functionality, etc. >> >> Here is the relevant text from http://tools.ietf.org/html/draft-seitz-core-sec-usecases-00: >> --------- >> 2.3. Personal Health Monitoring >> >> The use of wearable health monitoring technology is expected to grow strongly, as a multitude of novel devices are developed and marketed. These devices are typically battery driven, and located physically on the user. They monitor some bodily function, such as e.g. temperature, blood pressure, or pulse. They are connected to the Internet, either through an intermediary base-station or directly, using wireless technologies. Through this connection they report the monitored data to some entity, which may either be the user herself, or some medical personnel in charge of the user. >> >> Medical data has always been considered as very sensitive, and therefore requires good protection against unauthorized disclosure. A frequent, conflicting requirement is the capability for medical personnel to gain emergency access, even if no specific access rights exist. As a result, the importance of secure audit logs increases in such scenarios. Since the users are not typically trained in security (or even computer use), the configuration must use secure default settings, and the interface must be well adapted to novice users. Also the system must require very little maintenance, so e.g. frequent changes of battery are unacceptable. >> >> 2.3.1 John and the heart rate monitor >> >> John has a heart condition, that can result in sudden cardiac arrests. He therefore uses a device called HeartGuard that monitors his heart rate and his position. In case of a cardiac arrest it automatically sends an alarm to an emergency service, transmitting John's current location. The device also functions as a implanted cardioverter defibrilator, i.e. it can deliver a shock in order to try and normalize Johns heart rate. John can configure additional persons that get notified in an emergency, for example his daughter Jill. Furthermore the device stores data on John's heart rate, which can later be accessed by a physician to assess the condition of John's heart. However John is a rather private person, and is worried that Jill might use HeartGuard to monitor his location while there is no emergency. Furthermore he doesn't want his health insurance to get access to the HeartGuard data, since they might refuse to renew his insurance if they decided he was too big a risk ! > for them. >> >> --------- >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From brian.rosen@neustar.biz Fri Feb 7 08:50:52 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA841A0425 for ; Fri, 7 Feb 2014 08:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxDLWWrUMcnm for ; Fri, 7 Feb 2014 08:50:51 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C4DA01A0500 for ; Fri, 7 Feb 2014 08:50:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1391792000; x=1707143240; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=DZkq5xvRB2 ZiBgrJHTLDdit+M3XvZ42+sgLd0OQ61XA=; b=tKfICVbzcVg3Q0/aKlUM++ooA4 TSfu45o9cj40bqQ0BzzEFeTrSfA5Diu2zhUARqbrCX5H2pbJTKWSUJ60E7Ow== Received: from ([10.31.58.71]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.40827058; Fri, 07 Feb 2014 11:53:19 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Fri, 7 Feb 2014 11:50:42 -0500 From: "Rosen, Brian" To: Paul Kyzivat Thread-Topic: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case Thread-Index: AQHPJBOjKeVvbZ7Y80mWku3vpJswiQ== Date: Fri, 7 Feb 2014 16:50:42 +0000 Message-ID: <0388ABE1-8464-4482-B0F2-BB3DADF48194@neustar.biz> References: <67ADB9EF-85B0-46E5-B3EB-4967626C2E94@neustar.biz> <52F50E0E.7070701@alum.mit.edu> In-Reply-To: <52F50E0E.7070701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.26] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 60HGDvpYe0Yf8xM9HBr1uw== Content-Type: text/plain; charset="Windows-1252" Content-ID: <0632050F2F3DF94EAB665BA0985D6047@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:50:52 -0000 Yes. Too many false positives. There are actually laws in some jurisdicti= ons that prohibit devices from autodialing emergency calls. As we improve = sensors, we can make it possible for that to happen. The =93Data Only=94 o= r =93Non Human Initiated=94 calls are designed for that. The emergency ser= vices folks are concerned by any form of autodialing, but if we give them a= ppropriate controls, I think we can gain acceptance. Brian On Feb 7, 2014, at 11:47 AM, Paul Kyzivat wrote: > Every time I see an add for home security services (where they want to ta= p my bank account every month even though I might go years without an event= ) I wonder why I can't have a home security system that makes automated eme= rgency calls direct to the public emergency services. (And same for the "He= lp, I've fallen and can't get up" services.) >=20 > Is there something that prevents that? I guess that a home security syste= m that worked that way might result in many false alarms that might annoy t= he police or fire services. But is it illegal? >=20 > Thanks, > Paul >=20 > On 2/7/14 9:48 AM, Rosen, Brian wrote: >> We expect emergency services to have credentials in a PKI with known (pe= r country) roots of trust. That will be helpful in this scenario. I think= you want to differentiate between unmediated and mediated access. Mediate= d access means there is some service between the device and the emergency s= ervices. That is the most common scenario today. Whether unmediated acces= s becomes common in the future is speculation. I kind of hope it does, but= not too optimistic. Too much revenue opportunities are lost when vendors = allow direct access. >>=20 >> Brian >>=20 >> On Feb 6, 2014, at 4:23 AM, Hannes Tschofenig wrote: >>=20 >>> Hi all, >>>=20 >>> I am going to chair a BoF at the next IETF meeting related to Internet = of Things authentication and authorization. Folks in the group are currentl= y collecting use cases to derive requirements and the following emergency s= ervices related use case was brought forward. It would be great if the emer= gency services community could take a look at it and give me feedback wheth= er you consider this use case realistic, whether you have heard about proje= cts working on these topics, whether you have seen other approaches providi= ng similar functionality, etc. >>>=20 >>> Here is the relevant text from http://tools.ietf.org/html/draft-seitz-c= ore-sec-usecases-00: >>> --------- >>> 2.3. Personal Health Monitoring >>>=20 >>> The use of wearable health monitoring technology is expected to grow st= rongly, as a multitude of novel devices are developed and marketed. These d= evices are typically battery driven, and located physically on the user. Th= ey monitor some bodily function, such as e.g. temperature, blood pressure, = or pulse. They are connected to the Internet, either through an intermediar= y base-station or directly, using wireless technologies. Through this conne= ction they report the monitored data to some entity, which may either be th= e user herself, or some medical personnel in charge of the user. >>>=20 >>> Medical data has always been considered as very sensitive, and therefor= e requires good protection against unauthorized disclosure. A frequent, con= flicting requirement is the capability for medical personnel to gain emerge= ncy access, even if no specific access rights exist. As a result, the impo= rtance of secure audit logs increases in such scenarios. Since the users ar= e not typically trained in security (or even computer use), the configurati= on must use secure default settings, and the interface must be well adapted= to novice users. Also the system must require very little maintenance, so= e.g. frequent changes of battery are unacceptable. >>>=20 >>> 2.3.1 John and the heart rate monitor >>>=20 >>> John has a heart condition, that can result in sudden cardiac arrests. = He therefore uses a device called HeartGuard that monitors his heart rate a= nd his position. In case of a cardiac arrest it automatically sends an alar= m to an emergency service, transmitting John's current location. The device= also functions as a implanted cardioverter defibrilator, i.e. it can deliv= er a shock in order to try and normalize Johns heart rate. John can configu= re additional persons that get notified in an emergency, for example his da= ughter Jill. Furthermore the device stores data on John's heart rate, which= can later be accessed by a physician to assess the condition of John's hea= rt. However John is a rather private person, and is worried that Jill might= use HeartGuard to monitor his location while there is no emergency. Furthe= rmore he doesn't want his health insurance to get access to the HeartGuard = data, since they might refuse to renew his insurance if they decided he was= too big a risk ! >> for them. >>>=20 >>> --------- >>>=20 >>> Ciao >>> Hannes >>>=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 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From keith.drage@alcatel-lucent.com Mon Feb 10 09:56:47 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E093B1A0500 for ; Mon, 10 Feb 2014 09:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkW2xh_8LCNr for ; Mon, 10 Feb 2014 09:56:44 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6AE1A0565 for ; Mon, 10 Feb 2014 09:56:44 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1AHufUo029569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 11:56:42 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1AHueiH009146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 18:56:40 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 18:56:40 +0100 From: "DRAGE, Keith (Keith)" To: "Rosen, Brian" , Paul Kyzivat Thread-Topic: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case Thread-Index: AQHPJolzDOPs2QxiPEClXx0pPSZNzw== Date: Mon, 10 Feb 2014 17:56:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12F6BD@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <67ADB9EF-85B0-46E5-B3EB-4967626C2E94@neustar.biz> <52F50E0E.7070701@alum.mit.edu> <0388ABE1-8464-4482-B0F2-BB3DADF48194@neustar.biz> In-Reply-To: <0388ABE1-8464-4482-B0F2-BB3DADF48194@neustar.biz> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:56:48 -0000 Every country is different. For example, in the UK, burglar alarms may be connected to the police emerg= ency control room, but this is not an emergency call and does not use the e= mergency network. Other burglar alarms go to a private control room. Again, for the UK, medical devices dial a private control room, and it is t= he control room that decides whether to make an emergency call for an ambul= ance. Keith=20 > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian > Sent: 07 February 2014 16:51 > To: Paul Kyzivat > Cc: ECRIT > Subject: Re: [Ecrit] Your feedback on an Internet of Things=20 > Health Monitoring Use Case >=20 > Yes. Too many false positives. There are actually laws in=20 > some jurisdictions that prohibit devices from autodialing=20 > emergency calls. As we improve sensors, we can make it=20 > possible for that to happen. The "Data Only" or "Non Human=20 > Initiated" calls are designed for that. The emergency=20 > services folks are concerned by any form of autodialing, but=20 > if we give them appropriate controls, I think we can gain acceptance. >=20 > Brian >=20 > On Feb 7, 2014, at 11:47 AM, Paul Kyzivat=20 > wrote: >=20 > > Every time I see an add for home security services (where=20 > they want to=20 > > tap my bank account every month even though I might go=20 > years without=20 > > an event) I wonder why I can't have a home security system=20 > that makes=20 > > automated emergency calls direct to the public emergency services.=20 > > (And same for the "Help, I've fallen and can't get up" services.) > >=20 > > Is there something that prevents that? I guess that a home=20 > security system that worked that way might result in many=20 > false alarms that might annoy the police or fire services.=20 > But is it illegal? > >=20 > > Thanks, > > Paul > >=20 > > On 2/7/14 9:48 AM, Rosen, Brian wrote: > >> We expect emergency services to have credentials in a PKI=20 > with known (per country) roots of trust. That will be=20 > helpful in this scenario. I think you want to differentiate=20 > between unmediated and mediated access. Mediated access=20 > means there is some service between the device and the=20 > emergency services. That is the most common scenario today. =20 > Whether unmediated access becomes common in the future is=20 > speculation. I kind of hope it does, but not too optimistic.=20 > Too much revenue opportunities are lost when vendors allow=20 > direct access. > >>=20 > >> Brian > >>=20 > >> On Feb 6, 2014, at 4:23 AM, Hannes Tschofenig=20 > wrote: > >>=20 > >>> Hi all, > >>>=20 > >>> I am going to chair a BoF at the next IETF meeting=20 > related to Internet of Things authentication and=20 > authorization. Folks in the group are currently collecting=20 > use cases to derive requirements and the following emergency=20 > services related use case was brought forward. It would be=20 > great if the emergency services community could take a look=20 > at it and give me feedback whether you consider this use case=20 > realistic, whether you have heard about projects working on=20 > these topics, whether you have seen other approaches=20 > providing similar functionality, etc. > >>>=20 > >>> Here is the relevant text from=20 > http://tools.ietf.org/html/draft-seitz-core-sec-usecases-00: > >>> --------- > >>> 2.3. Personal Health Monitoring > >>>=20 > >>> The use of wearable health monitoring technology is=20 > expected to grow strongly, as a multitude of novel devices=20 > are developed and marketed. These devices are typically=20 > battery driven, and located physically on the user. They=20 > monitor some bodily function, such as e.g. temperature, blood=20 > pressure, or pulse. They are connected to the Internet,=20 > either through an intermediary base-station or directly,=20 > using wireless technologies. Through this connection they=20 > report the monitored data to some entity, which may either be=20 > the user herself, or some medical personnel in charge of the user. > >>>=20 > >>> Medical data has always been considered as very=20 > sensitive, and therefore requires good protection against=20 > unauthorized disclosure. A frequent, conflicting requirement=20 > is the capability for medical personnel to gain emergency=20 > access, even if no specific access rights exist. As a=20 > result, the importance of secure audit logs increases in such=20 > scenarios. Since the users are not typically trained in=20 > security (or even computer use), the configuration must use=20 > secure default settings, and the interface must be well=20 > adapted to novice users. Also the system must require very=20 > little maintenance, so e.g. frequent changes of battery are=20 > unacceptable. > >>>=20 > >>> 2.3.1 John and the heart rate monitor > >>>=20 > >>> John has a heart condition, that can result in sudden=20 > cardiac arrests. He therefore uses a device called HeartGuard=20 > that monitors his heart rate and his position. In case of a=20 > cardiac arrest it automatically sends an alarm to an=20 > emergency service, transmitting John's current location. The=20 > device also functions as a implanted cardioverter=20 > defibrilator, i.e. it can deliver a shock in order to try and=20 > normalize Johns heart rate. John can configure additional=20 > persons that get notified in an emergency, for example his=20 > daughter Jill. Furthermore the device stores data on John's=20 > heart rate, which can later be accessed by a physician to=20 > assess the condition of John's heart. However John is a=20 > rather private person, and is worried that Jill might use=20 > HeartGuard to monitor his location while there is no=20 > emergency. Furthermore he doesn't want his health insurance=20 > to get access to the HeartGuard data, since they might refuse=20 > to renew his insurance if they decided he was too big a risk ! > >> for them. > >>>=20 > >>> --------- > >>>=20 > >>> Ciao > >>> Hannes > >>>=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 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From Brian.Rosen@neustar.biz Mon Feb 10 09:59:58 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9991A0402 for ; Mon, 10 Feb 2014 09:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTL40D9ao9O4 for ; Mon, 10 Feb 2014 09:59:55 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 344B21A0386 for ; Mon, 10 Feb 2014 09:59:55 -0800 (PST) Received: from stntexhc10.cis.neustar.com (stntexhc10.va.neustar.com [10.31.58.69]) by chihiron1.nc.neustar.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 4edb_5885_cc0bd9e7_c34d_439f_91d4_371345fd6a93; Mon, 10 Feb 2014 12:59:14 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc10.cis.neustar.com ([169.254.4.83]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 12:58:46 -0500 From: "Rosen, Brian" To: "DRAGE, Keith (Keith)" , Paul Kyzivat Thread-Topic: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case Thread-Index: AQHPJBOjKeVvbZ7Y80mWku3vpJswiZqvHo+A//+swoA= Date: Mon, 10 Feb 2014 17:58:46 +0000 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B12F6BD@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.33.193.26] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: SA2Jn2+3oDFlCVfyys3F9g== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9FDA72655FE3894E989D5BD2045D2568@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Your feedback on an Internet of Things Health Monitoring Use Case X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:59:58 -0000 That=B9s pretty much how it works in the US Brian On 2/10/14, 12:56 PM, "DRAGE, Keith (Keith)" wrote: >Every country is different. > >For example, in the UK, burglar alarms may be connected to the police >emergency control room, but this is not an emergency call and does not >use the emergency network. Other burglar alarms go to a private control >room. > >Again, for the UK, medical devices dial a private control room, and it is >the control room that decides whether to make an emergency call for an >ambulance. > >Keith=20 > >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian >> Sent: 07 February 2014 16:51 >> To: Paul Kyzivat >> Cc: ECRIT >> Subject: Re: [Ecrit] Your feedback on an Internet of Things >> Health Monitoring Use Case >>=20 >> Yes. Too many false positives. There are actually laws in >> some jurisdictions that prohibit devices from autodialing >> emergency calls. As we improve sensors, we can make it >> possible for that to happen. The "Data Only" or "Non Human >> Initiated" calls are designed for that. The emergency >> services folks are concerned by any form of autodialing, but >> if we give them appropriate controls, I think we can gain acceptance. >>=20 >> Brian >>=20 >> On Feb 7, 2014, at 11:47 AM, Paul Kyzivat >> wrote: >>=20 >> > Every time I see an add for home security services (where >> they want to=20 >> > tap my bank account every month even though I might go >> years without=20 >> > an event) I wonder why I can't have a home security system >> that makes=20 >> > automated emergency calls direct to the public emergency services. >> > (And same for the "Help, I've fallen and can't get up" services.) >> >=20 >> > Is there something that prevents that? I guess that a home >> security system that worked that way might result in many >> false alarms that might annoy the police or fire services. >> But is it illegal? >> >=20 >> > Thanks, >> > Paul >> >=20 >> > On 2/7/14 9:48 AM, Rosen, Brian wrote: >> >> We expect emergency services to have credentials in a PKI >> with known (per country) roots of trust. That will be >> helpful in this scenario. I think you want to differentiate >> between unmediated and mediated access. Mediated access >> means there is some service between the device and the >> emergency services. That is the most common scenario today. >> Whether unmediated access becomes common in the future is >> speculation. I kind of hope it does, but not too optimistic. >> Too much revenue opportunities are lost when vendors allow >> direct access. >> >>=20 >> >> Brian >> >>=20 >> >> On Feb 6, 2014, at 4:23 AM, Hannes Tschofenig >> wrote: >> >>=20 >> >>> Hi all, >> >>>=20 >> >>> I am going to chair a BoF at the next IETF meeting >> related to Internet of Things authentication and >> authorization. Folks in the group are currently collecting >> use cases to derive requirements and the following emergency >> services related use case was brought forward. It would be >> great if the emergency services community could take a look >> at it and give me feedback whether you consider this use case >> realistic, whether you have heard about projects working on >> these topics, whether you have seen other approaches >> providing similar functionality, etc. >> >>>=20 >> >>> Here is the relevant text from >> http://tools.ietf.org/html/draft-seitz-core-sec-usecases-00: >> >>> --------- >> >>> 2.3. Personal Health Monitoring >> >>>=20 >> >>> The use of wearable health monitoring technology is >> expected to grow strongly, as a multitude of novel devices >> are developed and marketed. These devices are typically >> battery driven, and located physically on the user. They >> monitor some bodily function, such as e.g. temperature, blood >> pressure, or pulse. They are connected to the Internet, >> either through an intermediary base-station or directly, >> using wireless technologies. Through this connection they >> report the monitored data to some entity, which may either be >> the user herself, or some medical personnel in charge of the user. >> >>>=20 >> >>> Medical data has always been considered as very >> sensitive, and therefore requires good protection against >> unauthorized disclosure. A frequent, conflicting requirement >> is the capability for medical personnel to gain emergency >> access, even if no specific access rights exist. As a >> result, the importance of secure audit logs increases in such >> scenarios. Since the users are not typically trained in >> security (or even computer use), the configuration must use >> secure default settings, and the interface must be well >> adapted to novice users. Also the system must require very >> little maintenance, so e.g. frequent changes of battery are >> unacceptable. >> >>>=20 >> >>> 2.3.1 John and the heart rate monitor >> >>>=20 >> >>> John has a heart condition, that can result in sudden >> cardiac arrests. He therefore uses a device called HeartGuard >> that monitors his heart rate and his position. In case of a >> cardiac arrest it automatically sends an alarm to an >> emergency service, transmitting John's current location. The >> device also functions as a implanted cardioverter >> defibrilator, i.e. it can deliver a shock in order to try and >> normalize Johns heart rate. John can configure additional >> persons that get notified in an emergency, for example his >> daughter Jill. Furthermore the device stores data on John's >> heart rate, which can later be accessed by a physician to >> assess the condition of John's heart. However John is a >> rather private person, and is worried that Jill might use >> HeartGuard to monitor his location while there is no >> emergency. Furthermore he doesn't want his health insurance >> to get access to the HeartGuard data, since they might refuse >> to renew his insurance if they decided he was too big a risk ! >> >> for them. >> >>>=20 >> >>> --------- >> >>>=20 >> >>> Ciao >> >>> Hannes >> >>>=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 >> >=20 >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 From internet-drafts@ietf.org Mon Feb 10 19:58:37 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACE91A0786; Mon, 10 Feb 2014 19:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GewBL-VWGTau; Mon, 10 Feb 2014 19:58:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D90B1A077E; Mon, 10 Feb 2014 19:58:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140211035836.16810.85343.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 19:58:36 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-18.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 03:58:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Authors : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens James Winterbottom Filename : draft-ietf-ecrit-additional-data-18.txt Pages : 97 Date : 2014-02-10 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-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-18 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 internet-drafts@ietf.org Tue Feb 11 19:07:26 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294971A07C7; Tue, 11 Feb 2014 19:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5-hTKy1ykvL; Tue, 11 Feb 2014 19:07:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA551A0633; Tue, 11 Feb 2014 19:07:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212030723.22215.51564.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 19:07:23 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-19.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 03:07:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Authors : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens James Winterbottom Filename : draft-ietf-ecrit-additional-data-19.txt Pages : 97 Date : 2014-02-11 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-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-19 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 internet-drafts@ietf.org Wed Feb 12 16:44:59 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441D91A00A5; Wed, 12 Feb 2014 16:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dQ7O4-gcjHK; Wed, 12 Feb 2014 16:44:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 295511A0091; Wed, 12 Feb 2014 16:44:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213004456.14626.16683.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 16:44:56 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-20.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 00:44:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Authors : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens James Winterbottom Filename : draft-ietf-ecrit-additional-data-20.txt Pages : 97 Date : 2014-02-12 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-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 13:07:13 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EEA1A03E6 for ; Fri, 14 Feb 2014 13:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0oPg9RDkyxt for ; Fri, 14 Feb 2014 13:07:09 -0800 (PST) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4024B1A03DA for ; Fri, 14 Feb 2014 13:07:09 -0800 (PST) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id s1EL6uif015437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 14 Feb 2014 13:06:57 -0800 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.2]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0218.012; Fri, 14 Feb 2014 13:06:57 -0800 From: Roger Marshall To: "ecrit_ietf.org" Thread-Topic: ECRIT meeting agenda time Thread-Index: Ac8pyHcE9iwq2ov1RDec2GG30VmbAw== Date: Fri, 14 Feb 2014 21:06:55 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC1004F1E2SEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/tsFZkt8aT4D0C12sV9ybtbuVksk Cc: "ecrit-chairs@tools.ietf.org" Subject: [Ecrit] ECRIT meeting agenda time X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:07:11 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1004F1E2SEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please let us know soon if you want to present your draft(s) at IETF89. Roger Marshall & Marc Linsner - ECRIT chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1004F1E2SEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please let us know soon if you want to present your draft(s) at IET= F89.

Roger Marshall & Marc Linsner – ECRIT chairs

 

 

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

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1004F1E2SEAEXMB2telecom_-- From nobody Fri Feb 14 13:14:42 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28911A02C0; Fri, 14 Feb 2014 13:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH5p7hO7q0BO; Fri, 14 Feb 2014 13:14:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0681A0411; Fri, 14 Feb 2014 13:14:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214211433.17388.17044.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 13:14:33 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/7FIepzJ1eK46ak5cwZdtSSIU7ng Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-07.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:14:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Data-Only Emergency Calls Authors : Brian Rosen Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-data-only-ea-07.txt Pages : 22 Date : 2014-02-14 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-data-only-ea-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 nobody Fri Feb 14 13:28:48 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5B71A0449 for ; Fri, 14 Feb 2014 13:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFVlPud8uSeu for ; Fri, 14 Feb 2014 13:28:42 -0800 (PST) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by ietfa.amsl.com (Postfix) with ESMTP id A64671A03BA for ; Fri, 14 Feb 2014 13:28:27 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so14488477obc.39 for ; Fri, 14 Feb 2014 13:28:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=EHzf/nuiw2eZFIMYViqgQ1/E8CLfeqFYp3bGpn70SGo=; b=R2iNxO2PhkgnvpqgkoSJW5lV4dmDB68cE6zzfw4bGY/E/aBidSoQea3KSU6bd5Mdhi 7eYoxW/hTwuyezEmiUoEOkyfQcPfdrp+ENtDAeP/T/WMFF4WymiyjiUNMZ/esz6nm9N8 lUuEoQW27tCNFsmi8hxHnZ05UFk59Xo267l1iZY59OS1+Vjqe/NaKJpSL7udGye1NuQs 9s2lMMyDCe5xyyUW2GfyCXlbgh57RP01uhMtWYpwdDl7+R14Z4SZwzmLGk7vblIbV3Cb s1vkMjwr/KQoN9LnIHzZ3re79rBoedXBn0MRyCdwZB6c1ucs2Vw+gIidFbhN0ITlMe0s Nqpg== X-Gm-Message-State: ALoCoQlD3oNGj7ubJHXPu4Qr5h4w/lxZPumCosqIo6vyEYZNC/t/nuxrJVWE5WDktfLC+fSGDUlH MIME-Version: 1.0 X-Received: by 10.182.148.106 with SMTP id tr10mr3021154obb.65.1392413305866; Fri, 14 Feb 2014 13:28:25 -0800 (PST) Received: by 10.60.69.102 with HTTP; Fri, 14 Feb 2014 13:28:25 -0800 (PST) Date: Fri, 14 Feb 2014 16:28:25 -0500 Message-ID: From: Richard Barnes To: "ecrit@ietf.org" , draft-ietf-ecrit-trustworthy-location@tools.ietf.org Content-Type: multipart/alternative; boundary=089e012940d87a774e04f2647c69 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/iwm1lEvg_N0Tf_py05zAL-w9r2w Subject: [Ecrit] AD review: draft-ietf-ecrit-trustworthy-location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:28:44 -0000 --089e012940d87a774e04f2647c69 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this draft in preparation for IETF LC. Overall, it's in good shape, and I have requested the LC. A couple of minor comments to address with any LC comments: Section 1.1: The definition of "trustworthy location" is circular. Suggest deleting "...and has been assessed as trustworthy". Section 1.1: "Time-shifting" is more traditionally known as a "replay attack". Might be helpful to note this correspondence. Thanks, --Richard --089e012940d87a774e04f2647c69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this draft in preparation for IETF LC. =A0= Overall, it's in good shape, and I have requested the LC. =A0A couple o= f minor comments to address with any LC comments:

S= ection 1.1:
The definition of "trustworthy location" is circular. =A0Sug= gest deleting "...and has been assessed as trustworthy".

Section 1.1:=A0
"Time-shifting" is mor= e traditionally known as a "replay attack". =A0Might be helpful t= o note this correspondence.

Thanks,
--Richard
--089e012940d87a774e04f2647c69-- From nobody Fri Feb 14 13:38:17 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0931A0342; Fri, 14 Feb 2014 13:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVFmpFhOXshm; Fri, 14 Feb 2014 13:38:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0931A023F; Fri, 14 Feb 2014 13:38:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140214213808.12663.70093.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 13:38:08 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/z-Zbp7hvBWpnIRKiY0Dhf4yokQg Cc: ecrit@ietf.org Subject: [Ecrit] Last Call: (Trustworthy Location) to Informational RFC X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:38:15 -0000 The IESG has received a request from the Emergency Context Resolution with Internet Technologies WG (ecrit) to consider the following document: - 'Trustworthy Location' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/2181/ From nobody Mon Feb 17 15:37:15 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E8F1A0554 for ; Mon, 17 Feb 2014 15:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jMfEBPu2I5Y for ; Mon, 17 Feb 2014 15:37:10 -0800 (PST) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1EBB1A0553 for ; Mon, 17 Feb 2014 15:37:10 -0800 (PST) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id s1HNb57e002152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 17 Feb 2014 15:37:05 -0800 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.8]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.01.0218.012; Mon, 17 Feb 2014 15:37:04 -0800 From: Roger Marshall To: "ecrit_ietf.org" Thread-Topic: draft-gellens-ecrit-car-crash: adopt as a WG item? Thread-Index: Ac8sOHJdVvnP7zviRIODXyn2MtJs6g== Date: Mon, 17 Feb 2014 23:37:03 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A94CSEAEXMB1telecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/v1hyyWL12xQSZw6igxz8cfADXpw Cc: "ecrit-chairs@tools.ietf.org" Subject: [Ecrit] draft-gellens-ecrit-car-crash: adopt as a WG item? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:37:14 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A94CSEAEXMB1telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We've had some list support for adopting the following draft as a work grou= p item. draft-gellens-ecrit-car-crash Does anyone object to making this a ECRIT wg item, and updated charter w/in= dividual milestone? Roger Marshall ECRIT co-chair 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_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A94CSEAEXMB1telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We’ve had some list support for adopting the f= ollowing draft as a work group item.

 

dr= aft-gellens-ecrit-car-crash

 

Does anyone object to making this a ECRIT wg item, a= nd updated charter w/individual milestone?

 

Roger Marshall

ECRIT co-chair

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_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A94CSEAEXMB1telecom_-- From nobody Mon Feb 17 15:37:30 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D3F1A0587 for ; Mon, 17 Feb 2014 15:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBcnjMRcQj3o for ; Mon, 17 Feb 2014 15:37:24 -0800 (PST) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 715311A0553 for ; Mon, 17 Feb 2014 15:37:24 -0800 (PST) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id s1HNbFcx029079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 17 Feb 2014 15:37:16 -0800 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.8]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Mon, 17 Feb 2014 15:37:15 -0800 From: Roger Marshall To: "ecrit_ietf.org" Thread-Topic: draft-gellens-ecrit-ecall: adopt as WG item? Thread-Index: Ac8sOFeBiHazSa11S2eBDpLBbQt5sg== Date: Mon, 17 Feb 2014 23:37:14 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A954SEAEXMB1telecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/YvVprJMjNAC1j6HZMq36UTb0nI8 Cc: "ecrit-chairs@tools.ietf.org" Subject: [Ecrit] draft-gellens-ecrit-ecall: adopt as WG item? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:37:27 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A954SEAEXMB1telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another question: We've had some list support for adopting the following draft as a work grou= p item, (though not a lot of activity since). draft-gellens-ecrit-ecall Does anyone object to making this a wg item, and updated charter w/individu= al milestone? Roger Marshall ECRIT co-chair Roger S. Marshall Senior Member of Technical Staff TeleCommunication Systems, Inc. (TCS) 2401 Elliott Ave, Flr. 2 Seattle, WA 98121 rmarshall@telecomsys.com ph. 206.792.2424 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_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A954SEAEXMB1telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another question:

We’ve had some list support for adopting the f= ollowing draft as a work group item, (though not a lot of activity since).<= o:p>

 

dr= aft-gellens-ecrit-ecall

 

Does anyone object to making this a wg item, and upd= ated charter w/individual milestone?

 

Roger Marshall

ECRIT co-chair

 

 

Roger S. Marshall

Senior Member of Technical Staff

TeleCommunication Systems, Inc. (TCS)

2401 Elliott Ave, Flr. 2

Seattle, WA  98121

rmarshal= l@telecomsys.com

ph. 206.792.2424

 

 

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_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A954SEAEXMB1telecom_-- From nobody Mon Feb 17 15:56:25 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E087F1A02A7 for ; Mon, 17 Feb 2014 15:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qQ_BKTjtMkL for ; Mon, 17 Feb 2014 15:56:20 -0800 (PST) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 561311A027C for ; Mon, 17 Feb 2014 15:56:20 -0800 (PST) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id s1HNuBfX004279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 17 Feb 2014 15:56:11 -0800 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.8]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.01.0218.012; Mon, 17 Feb 2014 15:56:11 -0800 From: Roger Marshall To: "ecrit_ietf.org" Thread-Topic: IETF89 London: ECRIT agenda posted Thread-Index: Ac8sOxxavRu9IOuxThm3rDT3H7NflA== Date: Mon, 17 Feb 2014 23:56:10 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A9A1SEAEXMB1telecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/uKIB5GPJ9Jy55a9_-DlXiK_PSNY Cc: "ecrit-chairs@tools.ietf.org" Subject: [Ecrit] IETF89 London: ECRIT agenda posted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:56:24 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A9A1SEAEXMB1telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've posted the upcoming agenda in the mat'ls mgr. at the link and inline: http://www.ietf.org/proceedings/89/agenda/agenda-89-ecrit ECRIT Agenda - 16:30-17:30 GMT, Afternoon Session III, Wednesday, March 5, = 2014 London 5 min * Agenda Bashing, Draft Status Update (Chairs) 5 min * Additional Data related to an Emergency Call (Randy) http://www.ietf.org/id/draft-ietf-ecrit-additional-data-20.txt 10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts us= ing the Session Initiation Protocol (Brian) http://www.ietf.org/id/draft-ietf-ecrit-data-only-ea-06.txt 5 min * A LoST extension to support return of complete and similar location= info (Brian) http://www.ietf.org/id/draft-marshall-ecrit-similar-location-03.txt 10 min * Internet Protocol-based In-Vehicle Emergency Calls (Randy) http://www.ietf.org/id/draft-gellens-ecrit-car-crash-02.txt 10 min * Next-Generation Pan-European eCall (Randy) http://www.ietf.org/id/draft-gellens-ecrit-ecall-03.txt 10 min * Validation of Locations Around a Planned Change http://www.ietf.org/id/draft-rosen-ecrit-lost-planned-changes-01 5 min * Discussion Roger Marshall & Marc Linsner ECRIT chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A9A1SEAEXMB1telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve posted the upcoming agenda in the matR= 17;ls mgr. at the link and inline:

 

http://www.ietf.org/proceedings/89/agenda/agenda-89-ecrit=

 

 

ECRIT Agenda - 16:30-17:30 GMT, Afternoon Sess= ion III, Wednesday, March 5, 2014 London

 

5 min * Agenda Bashing, Draft Status Update (C= hairs)

 

5 min * Additional Data related to an Emergenc= y Call (Randy)

http://www.ietf.org/id/draft-ietf-ecrit-additi= onal-data-20.txt

 

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

http://www.ietf.org/id/draft-ietf-ecrit-data-o= nly-ea-06.txt

 

5 min * A LoST extension to support return of = complete and similar location info (Brian)

http://www.ietf.org/id/draft-marshall-ecrit-si= milar-location-03.txt

 

10 min * Internet Protocol-based In-Vehicle Em= ergency Calls (Randy)

http://www.ietf.org/id/draft-gellens-ecrit-car= -crash-02.txt

 

10 min * Next-Generation Pan-European eCall (R= andy)

http://www.ietf.org/id/draft-gellens-ecrit-eca= ll-03.txt

 

10 min * Validation of Locations Around a Plan= ned Change

http://www.ietf.org/id/draft-rosen-ecrit-lost-= planned-changes-01

 

5 min * Discussion

 

 

 

Roger Marshall & Marc Linsner

ECRIT chairs

 

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

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1005A9A1SEAEXMB1telecom_-- From nobody Mon Feb 17 16:00:50 2014 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8AB1A00F6 for ; Mon, 17 Feb 2014 16:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qVL7Etdv64C for ; Mon, 17 Feb 2014 16:00:42 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 107A81A041C for ; Mon, 17 Feb 2014 16:00:42 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id md12so15891750pbc.40 for ; Mon, 17 Feb 2014 16:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1iUnGfMUS2DhhjWnvEn1as7vkJJP42sbz8m3H4AwbdE=; b=pPQux2oozvSWgbaHuWfe6psrPloldasHggBZTb4EZN/MK64CPwb6db4NrzEv0VqPfM edM7S8MnKoccfwkmI3ar8MYvW0wd+pM3GOQKY6o0Oc89X2TE5L8M2IYhmU6d+vraGXg0 5t3VCGvYVdqr7pLmTEkLaOO6sa/3qvmc+wrtSC4eodTijKjwmfL/s6ouhEwVI+SHnooI eNtumi/7fLdwfuyaoIq2Q75E+r0B0QLlg8tEvuSJEd6f9WwLUkFRudSdQ3ueL00rcdn/ u/NhHpiE22eH6wNZKwQ1TaVyxtE7o2XAki/OgOk8c1fAQ8W/x3ofFHm1gfTBJmA02fUo TMoA== X-Received: by 10.68.197.133 with SMTP id iu5mr29544494pbc.132.1392681639368; Mon, 17 Feb 2014 16:00:39 -0800 (PST) Received: from [192.168.1.10] (124-168-176-200.dyn.iinet.net.au. [124.168.176.200]) by mx.google.com with ESMTPSA id vf7sm49645661pbc.5.2014.02.17.16.00.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Feb 2014 16:00:38 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DFBC1DC9-2E3C-40AA-B4B3-EDED857E832E" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: James Winterbottom In-Reply-To: Date: Tue, 18 Feb 2014 11:00:35 +1100 Message-Id: <0BDD150C-4DE3-4351-A07F-F969C4BE5549@gmail.com> References: To: Roger Marshall X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/fgwybH_q-w3-MgLCiYcMM6GPuEI Cc: "ecrit-chairs@tools.ietf.org" , "ecrit_ietf.org" Subject: Re: [Ecrit] draft-gellens-ecrit-ecall: adopt as WG item? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 00:00:46 -0000 --Apple-Mail=_DFBC1DC9-2E3C-40AA-B4B3-EDED857E832E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Roger, I am sorry for not having jumped on this one sooner. In theory I am not against the idea. I am not against some of the = mechanisms described in the document, but I do have concerns about some = of the possible duplication of information hat may exist between the = PIDF-LO and what is being conveyed in the MSD. I think that we need to make sure the new XMLed MSD structure doesn=92t = replicate data or information already covered elsewhere. Indeed, it may = be better to extend some elements of the existing additional data = specification if required to subsume the missing elements that exist in = MSD and simply use that document at least for data representation and = then just have a light-weight eCall document saying what to fill out. Cheers James On 18 Feb 2014, at 10:37 am, Roger Marshall = wrote: > Another question: > We=92ve had some list support for adopting the following draft as a = work group item, (though not a lot of activity since). > =20 > draft-gellens-ecrit-ecall > =20 > Does anyone object to making this a wg item, and updated charter = w/individual milestone? > =20 > Roger Marshall > ECRIT co-chair > =20 > =20 > Roger S. Marshall > Senior Member of Technical Staff > TeleCommunication Systems, Inc. (TCS) > 2401 Elliott Ave, Flr. 2 > Seattle, WA 98121 > rmarshall@telecomsys.com > ph. 206.792.2424 > =20 > =20 > CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and network. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_DFBC1DC9-2E3C-40AA-B4B3-EDED857E832E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Roger,

I am sorry for not having jumped on this one = sooner.
In theory I am not against the idea. I am not against = some of the mechanisms described in the document, but I do have concerns = about some of the possible duplication of information hat may exist = between the PIDF-LO and what is being conveyed in the = MSD.

I think that we need to make sure the new = XMLed MSD structure doesn=92t replicate data or information already = covered elsewhere. Indeed, it may be better to extend some elements of = the existing additional data specification if required to subsume the = missing elements that exist in MSD and simply use that document at least = for data representation and then just have a light-weight eCall document = saying what to fill = out.

Cheers
James

<= div>
On 18 Feb 2014, at 10:37 am, Roger Marshall <RMarshall@telecomsys.com> = wrote:

Another = question:
We=92ve had some = list support for adopting the following draft as a work group item, = (though not a lot of activity since).
 
draft-gellens-ecrit-ecall
 
Does = anyone object to making this a wg item, and updated charter w/individual = milestone?
 
Roger = Marshall
ECRIT = co-chair
 
 
Roger S. = Marshall
Senior Member of = Technical Staff
TeleCommunication = Systems, Inc. (TCS)
2401 = Elliott Ave, Flr. 2
Seattle, = WA  98121
ph. 206.792.2424
 
 

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

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

= --Apple-Mail=_DFBC1DC9-2E3C-40AA-B4B3-EDED857E832E--