From hannes.tschofenig@gmx.net Thu Oct 3 04:33:23 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E2421E8056 for ; Thu, 3 Oct 2013 04:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.823 X-Spam-Level: X-Spam-Status: No, score=-101.823 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bPnxI4ssd3t for ; Thu, 3 Oct 2013 04:33:09 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id E57F421F9E26 for ; Thu, 3 Oct 2013 04:29:27 -0700 (PDT) Received: from [10.255.138.179] ([194.251.119.201]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MOkQc-1VVWZp3BbC-00637v for ; Thu, 03 Oct 2013 13:29:25 +0200 Message-ID: <524D5503.4040007@gmx.net> Date: Thu, 03 Oct 2013 14:29:07 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <524D3AE9.6070301@isode.com> In-Reply-To: <524D3AE9.6070301@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rcJ/nXJGNisO5HC1/HId27jx5uhSICUate9tE074mVDS8bzqdrc Vb3mDUqQ8uMvwsDEz07FWWYe/qX3Fe8j4OLAxxXz1BGol9JspKnKi8nm52VO5EXK+bdXH/p 0Afbf5vM8eaLo+AkbDtrQ+hDjJlNDl09bhfXcERa3apXkZ+SfHNmVmQ/IOXTFZi517L1PRi tbZgGhbSEyXWZw1CqAZyQ== Cc: gen-art@ietf.org, draft-ietf-ecrit-unauthenticated-access.all@tools.ietf.org, "ecrit@ietf.org" Subject: Re: [Ecrit] Gen-Art review of draft-ietf-ecrit-unauthenticated-access-07.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 11:33:23 -0000 Hi Alexey, thanks for the review. I have incorporated your comments in the updated version. I will have to incorporate the comments from Richard as well before I submit a new version. Ciao Hannes On 03.10.2013 12:37, Alexey Melnikov wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-ecrit-unauthenticated-access-07.txt > Reviewer: Alexey Melnikov > Review Date: 3 October 2013 > IETF LC End Date: 27 September 2013 > IESG Telechat date: N/A > > Summary: Ready with nits > > Major issues: None > > Minor issues: > > Nits/editorial comments: > > In Section 1: the acronym VSP is not defined. (It is defined in a later > section.) > > In Section 6.1: EAP has no reference. > > In Section 5.2: EAP-TLS needs an Informative reference. From RMarshall@telecomsys.com Fri Oct 4 11:18:19 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324F521F9AA8 for ; Fri, 4 Oct 2013 11:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+LYUswJV9UQ for ; Fri, 4 Oct 2013 11:18:15 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 091D621F99CD for ; Fri, 4 Oct 2013 11:18:14 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id r94II3oj012213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 4 Oct 2013 11:18:03 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.185]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0218.012; Fri, 4 Oct 2013 11:18:03 -0700 From: Roger Marshall To: "ecrit_ietf.org" Thread-Topic: Charter & Milestones update - Comments sought Thread-Index: Ac7BLfNZgOHANmOzQNGU4fpZSblfKQ== Date: Fri, 4 Oct 2013 18:18:01 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 18:18:19 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ECRIT working group agreed that the chairs would propose updated langua= ge to the wg charter, along with milestone data changes. Compare this to the original charter found at: http://tools.ietf.org/wg/ecr= it/charters. Please send your comments to the list, whether in favor, or with alternativ= e wording and/or dates. Regards, Roger Marshall/Marc Linsner ECRIT Chairs ECRIT charter (w/proposed revisions): Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems Mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group will describe where and how these mechanis= ms may be used. The group will show how the availability of location data and call routing information at different steps in the call session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this documen= t, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. Beyond human initiated emergency call request mechanisms, this group wi= ll develop new methods to request emergency assistance, such as sensor initiated emergency requests, and additional processes specified that address topics such as authentication of location, service URN definiti= on and use, augmented information that could assist emergency call takers = or responders. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requ= iring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be handled independently. This working group cares about privacy and security concerns, and will address them within its documents. Milestones w/revised status/dates, as proposed Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG f= or consideration as an Experimental RFC Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for cons= ideration as a Standards Track RFC Dec 2013 - Submit a draft 'Policy for defining new service-identifying labels' to the IESG for consideration as BCP Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The ECRIT working group agreed that the chairs would= propose updated language to the wg charter, along with milestone data chan= ges.

 

Compare this to the original charter found at: http://tools.ietf.org/wg/ecrit/charters.

 

Please send your comments to the list, whether in fa= vor, or with alternative wording and/or dates.

 

Regards,

 

Roger Marshall/Marc Linsner

ECRIT Chairs

 

ECRIT charter (w/proposed revisions):

 

Description of Working Group:

 

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

    been configured to recognize an e= xplicitly specified number (usually

    one that is short and easily memo= rized) as a request for emergency

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

    service context and depend on a b= road, regional configuration of

    service contact methods and a geo= graphically-constrained approach for

    service delivery.  These cal= ls are intended to be delivered to special

    call centers equipped to manage e= mergency response. Successful

    delivery of an emergency service = call within those systems requires

    an association of both the physic= al location of the originating device

    along with appropriate call = routing to an emergency service center.

 

    Calls placed using Internet techn= ologies do not use the same systems

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

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

    meeting these goals even mor= e challenging.  There are, however,

    Internet technologies availa= ble to manage location and to perform call

    routing.  This working = group will describe where and how these mechanisms

    may be used. The group will = show how the availability of location data

    and call routing information= at different steps in the call session

    setup would enable communica= tion between a user and a relevant emergency

    response center. Though the = term "call routing" is used in this document,

    it should be understood that= some of the mechanisms which will be

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

    and text messaging, for example, = might be used to request emergency

    services.

 

    Beyond human initiated emergency = call request mechanisms, this group will

    develop new methods to reque= st emergency assistance, such as sensor

    initiated emergency requests= , and additional processes specified that

    address topics such as authe= ntication of location, service URN definition

    and use, augmented informati= on that could assist emergency call takers or

    responders.

 

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

    pre-emption or prioritization of = emergency services traffic. This

    group is considering emergency se= rvices calls which might be made by

    any user of the Internet, as oppo= sed to government or military

    services that may impose very dif= ferent authentication and routing

    requirements.

 

    While this group anticipates a cl= ose working relationship with groups

    such as NENA and ETSI EMTEL, any = solution presented must be useful

    regardless of jurisdiction, and i= t must be possible to use without requiring a

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

    delegations within a jurisdiction= to be handled independently, as call

    routing for specific emergency ty= pes may be handled independently.

 

    This working group cares about pr= ivacy and security concerns, and will

    address them within its documents= .

 

 

Milestones w/revised status/dates, as proposed<= /o:p>

 

Done - Submit 'Public Saf= ety Answering Point (PSAP) Callbacks' to the IESG

for consideration as an I= nformational RFC

 

Nov 2013 - Submit 'Trustworthy Location Information'= to the IESG for

consideration as an Informational RFC

 

Dec 2013 - Submit 'Additional Data related to a Call= for Emergency Call

Purposes' to the IESG for consideration as a Standar= ds Track RFC

 

Nov 2013 - Submit 'Common Alerting Protocol (CAP) ba= sed Data-Only

Emergency Alerts using the Session Initiation Protoc= ol (SIP)' to the IESG for consideration as an

Experimental RFC

 

Dec 2013 - Submit 'Extensions to the Emergency Servi= ces Architecture for

dealing with Unauthenticated and Unauthorized Device= s' to the IESG for consideration

as a Standards Track RFC

 

Dec 2013 - Submit a draft 'Policy for defining new s= ervice-identifying

labels' to the IESG for consideration as BCP

 

Mar 2014 - Submit 'Using Imprecise Location for Emer= gency Call Routing'

to the IESG for consideration as an Informational RF= C

 

Dec 2013 - Submit a draft 'URN For Country Specific = Emergency Services'

to the IESG for consideration as a Standards Track R= FC

 

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_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_-- From randy@qti.qualcomm.com Mon Oct 7 13:59:44 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9718221E81C4 for ; Mon, 7 Oct 2013 13:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.141 X-Spam-Level: X-Spam-Status: No, score=-101.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rHVUAW48NTE for ; Mon, 7 Oct 2013 13:59:36 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4D08821E81BB for ; Mon, 7 Oct 2013 13:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1381179576; x=1412715576; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=7qBTLBHn1r6ePjhC17qgvsPur/rYx3yp9moij/hMg3g=; b=s/H/4O6LiowHvWjiBR6i3OiCImgAbXByh9bDS9A/byzEaHomHXF/UQFR JWTjzV/jAgbtNDx9r2JMd9RLKiptwrHZE8kVTBt3kurTirAbS24BgVhBJ Y0qOhoFS96yTtl024vSwYF9/+QTBTUtuiGTcDvjOllY+oGnUKqAg97Q5K g=; X-IronPort-AV: E=McAfee;i="5400,1158,7221"; a="53695284" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 07 Oct 2013 13:59:35 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7221"; a="527396071" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Oct 2013 13:59:34 -0700 Received: from [10.184.126.229] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Oct 2013 13:59:33 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 7 Oct 2013 13:45:47 -0700 To: Roger Marshall , ecrit_ietf.org From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 20:59:44 -0000 Re: [Ecrit] Charter & Milestones update - Comments sought
I realize some of this language is a holdover from our very early days when we weren't sure which way we could go for things which became LoST, for example.  Still, I'm not sure exactly what "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority" mean today.  In one sense, everything we do has dependency on jurisdiction, because not all jurisdictions will migrate to next-generation at the same time.  A SIP-based emergency call won't work in a legacy emergency call jurisdiction.

We want to be sure that we can work on generic ACN and pan-Europen eCall.


At 6:18 PM +0000 10/4/13, Roger Marshall wrote:

Content-Language: en-US
Content-Type: multipart/alternative;
     boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_"
The ECRIT working group agreed that the chairs would propose updated language to the wg charter, along with milestone data changes.
 
Compare this to the original charter found at: http://tools.ietf.org/wg/ecrit/charters.
 
Please send your comments to the list, whether in favor, or with alternative wording and/or dates.
 
Regards,
 
Roger Marshall/Marc Linsner
ECRIT Chairs
 
ECRIT charter (w/proposed revisions):
 
Description of Working Group:
 
    In a number of areas, the public switched telephone network (PSTN) has
    been configured to recognize an explicitly specified number (usually
    one that is short and easily memorized) as a request for emergency
    services.  These numbers (e.g., 911, 112) are related to an emergency
    service context and depend on a broad, regional configuration of
    service contact methods and a geographically-constrained approach for
    service delivery.  These calls are intended to be delivered to special
    call centers equipped to manage emergency response. Successful
    delivery of an emergency service call within those systems requires
    an association of both the physical location of the originating device
    along with appropriate call routing to an emergency service center.
 
    Calls placed using Internet technologies do not use the same systems
    Mentioned above to achieve those same goals, and the common use of
    overlay networks and tunnels (either as VPNs or for mobility) makes
    meeting these goals even more challenging.  There are, however,
    Internet technologies available to manage location and to perform call
    routing.  This working group will describe where and how these mechanisms
    may be used. The group will show how the availability of location data
    and call routing information at different steps in the call session
    setup would enable communication between a user and a relevant emergency
    response center. Though the term "call routing" is used in this document,
    it should be understood that some of the mechanisms which will be
    described might be used to enable other types of media streams. Video
    and text messaging, for example, might be used to request emergency
    services.
 
    Beyond human initiated emergency call request mechanisms, this group will
    develop new methods to request emergency assistance, such as sensor
    initiated emergency requests, and additional processes specified that
    address topics such as authentication of location, service URN definition
    and use, augmented information that could assist emergency call takers or
    responders.
 
    Explicitly outside the scope of this group is the question of
    pre-emption or prioritization of emergency services traffic. This
    group is considering emergency services calls which might be made by
    any user of the Internet, as opposed to government or military
    services that may impose very different authentication and routing
    requirements.
 
    While this group anticipates a close working relationship with groups
    such as NENA and ETSI EMTEL, any solution presented must be useful
    regardless of jurisdiction, and it must be possible to use without requiring a
    single, central authority.  Further, it must be possible for multiple
    delegations within a jurisdiction to be handled independently, as call
    routing for specific emergency types may be handled independently.
 
    This working group cares about privacy and security concerns, and will
    address them within its documents.
 
 
Milestones w/revised status/dates, as proposed
 
Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG
for consideration as an Informational RFC
 
Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for
consideration as an Informational RFC
 
Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call
Purposes' to the IESG for consideration as a Standards Track RFC
 
Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only
Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an
Experimental RFC
 
Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for
dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration
as a Standards Track RFC
 
Dec 2013 - Submit a draft 'Policy for defining new service-identifying
labels' to the IESG for consideration as BCP
 
Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'
to the IESG for consideration as an Informational RFC
 
Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'
to the IESG for consideration as a Standards Track RFC
 
CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

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


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Personal experiences affect the facts that judges choose to see.
       --Judge Sotomayor
From hannes.tschofenig@gmx.net Sun Oct 13 09:00:07 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B0A21E80E0 for ; Sun, 13 Oct 2013 09:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtyo3yncIgHv for ; Sun, 13 Oct 2013 08:59:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id ABD1821F8F78 for ; Sun, 13 Oct 2013 08:59:58 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Ltr89-1VwzZh1r4X-0117aG for ; Sun, 13 Oct 2013 17:59:56 +0200 Message-ID: <525AC37C.8090708@gmx.net> Date: Sun, 13 Oct 2013 18:59:56 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roger Marshall References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Ro8X9RsPIsX+hn+Z+YFJLPmXdnBIPaIMaGrgos80AoHYj61/0S7 Q0J3T1It5Ok8f7OKSTOEST9Wv9jWHe4Y5hpDTyeu2Zw1uDxtXSFdxIuLHDP3f3T05uaTMLP f6I9X5t2XOXgCQ/zcKsorxvXFBjZEjTwRNX1WxA6iCpH73biNzwealTh680ATYd6PGvaFVx x6odLxQz/PNPGK0j+2kAw== Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 16:00:07 -0000 Hi Roger, thanks for working on the updated charter text. The text is fine for me; I only have a few minor suggestions. On 04.10.2013 21:18, Roger Marshall wrote: > The ECRIT working group agreed that the chairs would propose updated > language to the wg charter, along with milestone data changes. > > Compare this to the original charter found at: > http://tools.ietf.org/wg/ecrit/charters. > > Please send your comments to the list, whether in favor, or with > alternative wording and/or dates. > > Regards, > > Roger Marshall/Marc Linsner > > ECRIT Chairs > > ECRIT charter (w/proposed revisions): > > Description of Working Group: > > In a number of areas, the public switched telephone network (PSTN) has > > been configured to recognize an explicitly specified number (usually > > one that is short and easily memorized) as a request for emergency > > services. These numbers (e.g., 911, 112) are related to an emergency > > service context and depend on a broad, regional configuration of > > service contact methods and a geographically-constrained approach for > > service delivery. These calls are intended to be delivered to special > > call centers equipped to manage emergency response. Successful > > delivery of an emergency service call within those systems requires > > an association of both the physical location of the originating device > > along with appropriate call routing to an emergency service center. > > Calls placed using Internet technologies do not use the same systems > > Mentioned above to achieve those same goals, and the common use of > > overlay networks and tunnels (either as VPNs or for mobility) makes > > meeting these goals even more challenging. There are, however, > > Internet technologies available to manage location and to perform call > > routing. This working group will describe where and how these mechanisms > > may be used. The group will show how the availability of location data > > and call routing information at different steps in the call session > > setup would enable communication between a user and a relevant emergency > > response center. Though the term "call routing" is used in this document, > > it should be understood that some of the mechanisms which will be > > described might be used to enable other types of media streams. Video > > and text messaging, for example, might be used to request emergency > > services. I would omit this last sentence. I also believe that the term "document" isn't appropriate here. > > Beyond human initiated emergency call request mechanisms, this group will > > develop new methods to request emergency assistance, such as sensor > > initiated emergency requests, and additional processes specified that > > address topics such as authentication of location, service URN definition > > and use, augmented information that could assist emergency call takers or > > responders. s/"authentication of location"/"trustworthy location" > > Explicitly outside the scope of this group is the question of > > pre-emption or prioritization of emergency services traffic. This > > group is considering emergency services calls which might be made by > > any user of the Internet, as opposed to government or military > > services that may impose very different authentication and routing > > requirements. > > While this group anticipates a close working relationship with groups > > such as NENA and ETSI EMTEL, any solution presented must be useful You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL with "ETSI" since we are now dealing also with other groups in ETSI in addition to EMTEL. > > regardless of jurisdiction, and it must be possible to use without > requiring a > > single, central authority. Further, it must be possible for multiple > > delegations within a jurisdiction to be handled independently, as call > > routing for specific emergency types may be handled independently. > > This working group cares about privacy and security concerns, and will > > address them within its documents. > > Milestones w/revised status/dates, as proposed > > Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG > > for consideration as an Informational RFC > > Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for > > consideration as an Informational RFC > > Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call > > Purposes' to the IESG for consideration as a Standards Track RFC > > Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only > > Emergency Alerts using the Session Initiation Protocol (SIP)' to the > IESG for consideration as an > > Experimental RFC > > Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for > > dealing with Unauthenticated and Unauthorized Devices' to the IESG for > consideration I thought that this document has been sent to the IESG already. > > as a Standards Track RFC > > Dec 2013 - Submit a draft 'Policy for defining new service-identifying > > labels' to the IESG for consideration as BCP > > Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' > > to the IESG for consideration as an Informational RFC > > Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' > > to the IESG for consideration as a Standards Track RFC I believe you should also list all other concluded documents as well (and mark them as done). Ciao Hannes > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, > or responsible for delivering this message to the intended recipient, > any review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, > and delete it and all attachments from your computer and network. > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Sun Oct 13 09:37:47 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC10111E81AC for ; Sun, 13 Oct 2013 09:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+32u1CybRqU for ; Sun, 13 Oct 2013 09:37:40 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with ESMTP id 609BA11E8163 for ; Sun, 13 Oct 2013 09:37:37 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Sun, 13 Oct 2013 18:37:34 +0200 (CEST) Received: from [192.168.0.7] (cpe-74-69-52-124.rochester.res.rr.com [74.69.52.124]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id B6F063A16D for ; Sun, 13 Oct 2013 18:37:33 +0200 (CEST) Message-ID: <525ACC4D.1020500@omnitor.se> Date: Sun, 13 Oct 2013 12:37:33 -0400 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ecrit@ietf.org References: <525AC37C.8090708@gmx.net> In-Reply-To: <525AC37C.8090708@gmx.net> Content-Type: multipart/alternative; boundary="------------080306030104060407030303" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 16:37:47 -0000 This is a multi-part message in MIME format. --------------080306030104060407030303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, Policy based routing was once said to enable routing based on for example media requirements and capabilities to specific PSAPs equipped or educated for such calls. In latest NENA spec for policy based routing, only PSAP availability is mentioned as reason to route. I do not remember that we have anything sufficiently explicit from IETF on this topic, and suggest to include it in the goals. Thanks, Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-10-13 11:59, Hannes Tschofenig wrote: > Hi Roger, > > thanks for working on the updated charter text. > > The text is fine for me; I only have a few minor suggestions. > > On 04.10.2013 21:18, Roger Marshall wrote: >> The ECRIT working group agreed that the chairs would propose updated >> language to the wg charter, along with milestone data changes. >> >> Compare this to the original charter found at: >> http://tools.ietf.org/wg/ecrit/charters. >> >> Please send your comments to the list, whether in favor, or with >> alternative wording and/or dates. >> >> Regards, >> >> Roger Marshall/Marc Linsner >> >> ECRIT Chairs >> >> ECRIT charter (w/proposed revisions): >> >> Description of Working Group: >> >> In a number of areas, the public switched telephone network (PSTN) has >> >> been configured to recognize an explicitly specified number (usually >> >> one that is short and easily memorized) as a request for emergency >> >> services. These numbers (e.g., 911, 112) are related to an emergency >> >> service context and depend on a broad, regional configuration of >> >> service contact methods and a geographically-constrained approach for >> >> service delivery. These calls are intended to be delivered to special >> >> call centers equipped to manage emergency response. Successful >> >> delivery of an emergency service call within those systems requires >> >> an association of both the physical location of the originating device >> >> along with appropriate call routing to an emergency service center. >> >> Calls placed using Internet technologies do not use the same systems >> >> Mentioned above to achieve those same goals, and the common use of >> >> overlay networks and tunnels (either as VPNs or for mobility) makes >> >> meeting these goals even more challenging. There are, however, >> >> Internet technologies available to manage location and to perform call >> >> routing. This working group will describe where and how these mechanisms >> >> may be used. The group will show how the availability of location data >> >> and call routing information at different steps in the call session >> >> setup would enable communication between a user and a relevant emergency >> >> response center. Though the term "call routing" is used in this >> document, >> >> it should be understood that some of the mechanisms which will be >> >> described might be used to enable other types of media streams. Video >> >> and text messaging, for example, might be used to request emergency >> >> services. > > I would omit this last sentence. I also believe that the term > "document" isn't appropriate here. > > >> >> Beyond human initiated emergency call request mechanisms, this group >> will >> >> develop new methods to request emergency assistance, such as sensor >> >> initiated emergency requests, and additional processes specified that >> >> address topics such as authentication of location, service URN >> definition >> >> and use, augmented information that could assist emergency call >> takers or >> >> responders. > > s/"authentication of location"/"trustworthy location" > >> >> Explicitly outside the scope of this group is the question of >> >> pre-emption or prioritization of emergency services traffic. This >> >> group is considering emergency services calls which might be made by >> >> any user of the Internet, as opposed to government or military >> >> services that may impose very different authentication and routing >> >> requirements. >> >> While this group anticipates a close working relationship with groups >> >> such as NENA and ETSI EMTEL, any solution presented must be useful > > You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL > with "ETSI" since we are now dealing also with other groups in ETSI in > addition to EMTEL. > > >> >> regardless of jurisdiction, and it must be possible to use without >> requiring a >> >> single, central authority. Further, it must be possible for multiple >> >> delegations within a jurisdiction to be handled independently, as call >> >> routing for specific emergency types may be handled independently. >> >> This working group cares about privacy and security concerns, and will >> >> address them within its documents. >> >> Milestones w/revised status/dates, as proposed >> >> Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the >> IESG >> >> for consideration as an Informational RFC >> >> Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for >> >> consideration as an Informational RFC >> >> Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call >> >> Purposes' to the IESG for consideration as a Standards Track RFC >> >> Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only >> >> Emergency Alerts using the Session Initiation Protocol (SIP)' to the >> IESG for consideration as an >> >> Experimental RFC >> >> Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for >> >> dealing with Unauthenticated and Unauthorized Devices' to the IESG for >> consideration > > I thought that this document has been sent to the IESG already. > >> >> as a Standards Track RFC >> >> Dec 2013 - Submit a draft 'Policy for defining new service-identifying >> >> labels' to the IESG for consideration as BCP >> >> Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' >> >> to the IESG for consideration as an Informational RFC >> >> Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' >> >> to the IESG for consideration as a Standards Track RFC > > I believe you should also list all other concluded documents as well > (and mark them as done). > > > Ciao > Hannes > > >> >> CONFIDENTIALITY NOTICE: The information contained in this message may be >> privileged and/or confidential. If you are not the intended recipient, >> or responsible for delivering this message to the intended recipient, >> any review, forwarding, dissemination, distribution or copying of this >> communication or any attachment(s) is strictly prohibited. If you have >> received this message in error, please notify the sender immediately, >> and delete it and all attachments from your computer and network. >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --------------080306030104060407030303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,
Policy based routing was once said to enable routing based on for example media requirements and capabilities to specific PSAPs equipped or educated for such calls.
In latest NENA spec for policy based routing, only PSAP availability is mentioned as reason to route.

I do not remember that we have anything sufficiently explicit from IETF on this topic, and suggest to include it in the goals.

Thanks,
Gunnar


Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-10-13 11:59, Hannes Tschofenig wrote:
Hi Roger,

thanks for working on the updated charter text.

The text is fine for me; I only have a few minor suggestions.

On 04.10.2013 21:18, Roger Marshall wrote:
The ECRIT working group agreed that the chairs would propose updated
language to the wg charter, along with milestone data changes.

Compare this to the original charter found at:
http://tools.ietf.org/wg/ecrit/charters.

Please send your comments to the list, whether in favor, or with
alternative wording and/or dates.

Regards,

Roger Marshall/Marc Linsner

ECRIT Chairs

ECRIT charter (w/proposed revisions):

Description of Working Group:

In a number of areas, the public switched telephone network (PSTN) has

been configured to recognize an explicitly specified number (usually

one that is short and easily memorized) as a request for emergency

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

service context and depend on a broad, regional configuration of

service contact methods and a geographically-constrained approach for

service delivery. These calls are intended to be delivered to special

call centers equipped to manage emergency response. Successful

delivery of an emergency service call within those systems requires

an association of both the physical location of the originating device

along with appropriate call routing to an emergency service center.

Calls placed using Internet technologies do not use the same systems

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

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

meeting these goals even more challenging. There are, however,

Internet technologies available to manage location and to perform call

routing. This working group will describe where and how these mechanisms

may be used. The group will show how the availability of location data

and call routing information at different steps in the call session

setup would enable communication between a user and a relevant emergency

response center. Though the term "call routing" is used in this document,

it should be understood that some of the mechanisms which will be

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

and text messaging, for example, might be used to request emergency

services.

I would omit this last sentence. I also believe that the term "document" isn't appropriate here.



Beyond human initiated emergency call request mechanisms, this group will

develop new methods to request emergency assistance, such as sensor

initiated emergency requests, and additional processes specified that

address topics such as authentication of location, service URN definition

and use, augmented information that could assist emergency call takers or

responders.

s/"authentication of location"/"trustworthy location"


Explicitly outside the scope of this group is the question of

pre-emption or prioritization of emergency services traffic. This

group is considering emergency services calls which might be made by

any user of the Internet, as opposed to government or military

services that may impose very different authentication and routing

requirements.

While this group anticipates a close working relationship with groups

such as NENA and ETSI EMTEL, any solution presented must be useful

You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL with "ETSI" since we are now dealing also with other groups in ETSI in addition to EMTEL.



regardless of jurisdiction, and it must be possible to use without
requiring a

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

delegations within a jurisdiction to be handled independently, as call

routing for specific emergency types may be handled independently.

This working group cares about privacy and security concerns, and will

address them within its documents.

Milestones w/revised status/dates, as proposed

Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG

for consideration as an Informational RFC

Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for

consideration as an Informational RFC

Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call

Purposes' to the IESG for consideration as a Standards Track RFC

Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only

Emergency Alerts using the Session Initiation Protocol (SIP)' to the
IESG for consideration as an

Experimental RFC

Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for

dealing with Unauthenticated and Unauthorized Devices' to the IESG for
consideration

I thought that this document has been sent to the IESG already.


as a Standards Track RFC

Dec 2013 - Submit a draft 'Policy for defining new service-identifying

labels' to the IESG for consideration as BCP

Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'

to the IESG for consideration as an Informational RFC

Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'

to the IESG for consideration as a Standards Track RFC

I believe you should also list all other concluded documents as well (and mark them as done).


Ciao
Hannes



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



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

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

--------------080306030104060407030303-- From hannes.tschofenig@gmx.net Sun Oct 13 09:50:52 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D53F21F9D05 for ; Sun, 13 Oct 2013 09:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDS77FpPuQ+G for ; Sun, 13 Oct 2013 09:50:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8271A21F9193 for ; Sun, 13 Oct 2013 09:50:46 -0700 (PDT) Received: from [192.168.100.22] ([91.154.110.176]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LdHLB-1WDZJd3DV3-00iVw1 for ; Sun, 13 Oct 2013 18:50:45 +0200 Message-ID: <525ACF61.7080102@gmx.net> Date: Sun, 13 Oct 2013 19:50:41 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Gunnar Hellstrom References: <525AC37C.8090708@gmx.net> <525ACC4D.1020500@omnitor.se> In-Reply-To: <525ACC4D.1020500@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:o5vvfHQv2Ad0W2YeOxfLwxk765TEhsVCqrWyiUEWIIogFKr7kLS RXxe9KX8QzHFlwiEqP4zSyEk2vnngjgQD7PBh/N7wU1u7PmTR8EIIqIdSh1NO7zBEOHrf3U pliEr5OOEgWs2mKupoVwTSUkNzUcdMklybQeucpdV/JnPxck/00Li91cGPevUe7eb+tHguR 9DpKhEgA0P8lM2AtQONWA== Cc: ecrit@ietf.org Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 16:50:57 -0000 X-List-Received-Date: Sun, 13 Oct 2013 16:50:57 -0000 Hi Gunnar, that's fine with me but where do you want to add this remark in the charter text Roger proposed? Also, do we have any specific document in progress that is impacted by policy based routing? Ciao Hannes On 13.10.2013 19:37, Gunnar Hellstrom wrote: > Hi, > Policy based routing was once said to enable routing based on for > example media requirements and capabilities to specific PSAPs equipped > or educated for such calls. > In latest NENA spec for policy based routing, only PSAP availability is > mentioned as reason to route. > > I do not remember that we have anything sufficiently explicit from IETF > on this topic, and suggest to include it in the goals. > > Thanks, > Gunnar > > > ------------------------------------------------------------------------ > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > +46708204288 > On 2013-10-13 11:59, Hannes Tschofenig wrote: >> Hi Roger, >> >> thanks for working on the updated charter text. >> >> The text is fine for me; I only have a few minor suggestions. >> >> On 04.10.2013 21:18, Roger Marshall wrote: >>> The ECRIT working group agreed that the chairs would propose updated >>> language to the wg charter, along with milestone data changes. >>> >>> Compare this to the original charter found at: >>> http://tools.ietf.org/wg/ecrit/charters. >>> >>> Please send your comments to the list, whether in favor, or with >>> alternative wording and/or dates. >>> >>> Regards, >>> >>> Roger Marshall/Marc Linsner >>> >>> ECRIT Chairs >>> >>> ECRIT charter (w/proposed revisions): >>> >>> Description of Working Group: >>> >>> In a number of areas, the public switched telephone network (PSTN) has >>> >>> been configured to recognize an explicitly specified number (usually >>> >>> one that is short and easily memorized) as a request for emergency >>> >>> services. These numbers (e.g., 911, 112) are related to an emergency >>> >>> service context and depend on a broad, regional configuration of >>> >>> service contact methods and a geographically-constrained approach for >>> >>> service delivery. These calls are intended to be delivered to special >>> >>> call centers equipped to manage emergency response. Successful >>> >>> delivery of an emergency service call within those systems requires >>> >>> an association of both the physical location of the originating device >>> >>> along with appropriate call routing to an emergency service center. >>> >>> Calls placed using Internet technologies do not use the same systems >>> >>> Mentioned above to achieve those same goals, and the common use of >>> >>> overlay networks and tunnels (either as VPNs or for mobility) makes >>> >>> meeting these goals even more challenging. There are, however, >>> >>> Internet technologies available to manage location and to perform call >>> >>> routing. This working group will describe where and how these mechanisms >>> >>> may be used. The group will show how the availability of location data >>> >>> and call routing information at different steps in the call session >>> >>> setup would enable communication between a user and a relevant emergency >>> >>> response center. Though the term "call routing" is used in this >>> document, >>> >>> it should be understood that some of the mechanisms which will be >>> >>> described might be used to enable other types of media streams. Video >>> >>> and text messaging, for example, might be used to request emergency >>> >>> services. >> >> I would omit this last sentence. I also believe that the term >> "document" isn't appropriate here. >> >> >>> >>> Beyond human initiated emergency call request mechanisms, this group >>> will >>> >>> develop new methods to request emergency assistance, such as sensor >>> >>> initiated emergency requests, and additional processes specified that >>> >>> address topics such as authentication of location, service URN >>> definition >>> >>> and use, augmented information that could assist emergency call >>> takers or >>> >>> responders. >> >> s/"authentication of location"/"trustworthy location" >> >>> >>> Explicitly outside the scope of this group is the question of >>> >>> pre-emption or prioritization of emergency services traffic. This >>> >>> group is considering emergency services calls which might be made by >>> >>> any user of the Internet, as opposed to government or military >>> >>> services that may impose very different authentication and routing >>> >>> requirements. >>> >>> While this group anticipates a close working relationship with groups >>> >>> such as NENA and ETSI EMTEL, any solution presented must be useful >> >> You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL >> with "ETSI" since we are now dealing also with other groups in ETSI in >> addition to EMTEL. >> >> >>> >>> regardless of jurisdiction, and it must be possible to use without >>> requiring a >>> >>> single, central authority. Further, it must be possible for multiple >>> >>> delegations within a jurisdiction to be handled independently, as call >>> >>> routing for specific emergency types may be handled independently. >>> >>> This working group cares about privacy and security concerns, and will >>> >>> address them within its documents. >>> >>> Milestones w/revised status/dates, as proposed >>> >>> Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the >>> IESG >>> >>> for consideration as an Informational RFC >>> >>> Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for >>> >>> consideration as an Informational RFC >>> >>> Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call >>> >>> Purposes' to the IESG for consideration as a Standards Track RFC >>> >>> Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only >>> >>> Emergency Alerts using the Session Initiation Protocol (SIP)' to the >>> IESG for consideration as an >>> >>> Experimental RFC >>> >>> Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for >>> >>> dealing with Unauthenticated and Unauthorized Devices' to the IESG for >>> consideration >> >> I thought that this document has been sent to the IESG already. >> >>> >>> as a Standards Track RFC >>> >>> Dec 2013 - Submit a draft 'Policy for defining new service-identifying >>> >>> labels' to the IESG for consideration as BCP >>> >>> Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' >>> >>> to the IESG for consideration as an Informational RFC >>> >>> Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' >>> >>> to the IESG for consideration as a Standards Track RFC >> >> I believe you should also list all other concluded documents as well >> (and mark them as done). >> >> >> Ciao >> Hannes >> >> >>> >>> CONFIDENTIALITY NOTICE: The information contained in this message may be >>> privileged and/or confidential. If you are not the intended recipient, >>> or responsible for delivering this message to the intended recipient, >>> any review, forwarding, dissemination, distribution or copying of this >>> communication or any attachment(s) is strictly prohibited. If you have >>> received this message in error, please notify the sender immediately, >>> and delete it and all attachments from your computer and network. >>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> 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 randy@qti.qualcomm.com Sun Oct 13 16:22:12 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E20721E8149 for ; Sun, 13 Oct 2013 16:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWqrAk39hCgY for ; Sun, 13 Oct 2013 16:22:08 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD0B21E8147 for ; Sun, 13 Oct 2013 16:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1381706527; x=1413242527; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6jZ3BZsAor840iKdM52GA5ktb4oxY6gAfC8LwSHTJlQ=; b=EmexTKq+MP/oVYzkbq7dlMDG/VtOQTA2UBz+ya4+w1TYfFcXx9bbl+TC B4eBD+DqwejVAyFHMQTlGSKgVeaVDE01BiuM31EiyCvu/URWw3vQiNULV 4XpuzaKcpydSKVphaxY7Dt+3TD/OMtJiemNJYdEF2bxgnR7NKbzC9nYNQ Y=; X-IronPort-AV: E=McAfee;i="5400,1158,7227"; a="54143001" Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 13 Oct 2013 16:22:06 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7227"; a="568256708" Received: from nasanexhc02.na.qualcomm.com ([172.30.48.24]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Oct 2013 16:22:06 -0700 Received: from NASANEXD01B.na.qualcomm.com ([169.254.2.160]) by NASANEXHC02.na.qualcomm.com ([172.30.48.24]) with mapi id 14.03.0158.001; Sun, 13 Oct 2013 16:22:06 -0700 From: "Gellens, Randall" To: Hannes Tschofenig , Gunnar Hellstrom Thread-Topic: [Ecrit] Charter & Milestones update - Comments sought Thread-Index: Ac7BLfNZgOHANmOzQNGU4fpZSblfKQHOfvQAAAFQUYAAAHVsgP//94XN Date: Sun, 13 Oct 2013 23:22:05 +0000 Message-ID: <527682A7144B254C856D43E2B3D9E9371EFB798F@nasanexd01b.na.qualcomm.com> References: <525AC37C.8090708@gmx.net> <525ACC4D.1020500@omnitor.se>,<525ACF61.7080102@gmx.net> In-Reply-To: <525ACF61.7080102@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 23:22:12 -0000 The current NENA document on policy-based routing only deals with legacy ca= pabilities (that is, call diversion/exception handling). The NENA group in= tends to produce a version two that covers NG9-1-1 (NENA i3) capabilities w= ith the enhancements for call processing including media and other needs.= =0A= =0A= ________________________________________=0A= From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Hannes T= schofenig [hannes.tschofenig@gmx.net]=0A= Sent: Sunday, October 13, 2013 9:50 AM=0A= To: Gunnar Hellstrom=0A= Cc: ecrit@ietf.org=0A= Subject: Re: [Ecrit] Charter & Milestones update - Comments sought=0A= =0A= Hi Gunnar,=0A= =0A= that's fine with me but where do you want to add this remark in the=0A= charter text Roger proposed?=0A= =0A= Also, do we have any specific document in progress that is impacted by=0A= policy based routing?=0A= =0A= Ciao=0A= Hannes=0A= =0A= =0A= On 13.10.2013 19:37, Gunnar Hellstrom wrote:=0A= > Hi,=0A= > Policy based routing was once said to enable routing based on for=0A= > example media requirements and capabilities to specific PSAPs equipped=0A= > or educated for such calls.=0A= > In latest NENA spec for policy based routing, only PSAP availability is= =0A= > mentioned as reason to route.=0A= >=0A= > I do not remember that we have anything sufficiently explicit from IETF= =0A= > on this topic, and suggest to include it in the goals.=0A= >=0A= > Thanks,=0A= > Gunnar=0A= >=0A= >=0A= > ------------------------------------------------------------------------= =0A= > Gunnar Hellstr=F6m=0A= > Omnitor=0A= > gunnar.hellstrom@omnitor.se=0A= > +46708204288=0A= > On 2013-10-13 11:59, Hannes Tschofenig wrote:=0A= >> Hi Roger,=0A= >>=0A= >> thanks for working on the updated charter text.=0A= >>=0A= >> The text is fine for me; I only have a few minor suggestions.=0A= >>=0A= >> On 04.10.2013 21:18, Roger Marshall wrote:=0A= >>> The ECRIT working group agreed that the chairs would propose updated=0A= >>> language to the wg charter, along with milestone data changes.=0A= >>>=0A= >>> Compare this to the original charter found at:=0A= >>> http://tools.ietf.org/wg/ecrit/charters.=0A= >>>=0A= >>> Please send your comments to the list, whether in favor, or with=0A= >>> alternative wording and/or dates.=0A= >>>=0A= >>> Regards,=0A= >>>=0A= >>> Roger Marshall/Marc Linsner=0A= >>>=0A= >>> ECRIT Chairs=0A= >>>=0A= >>> ECRIT charter (w/proposed revisions):=0A= >>>=0A= >>> Description of Working Group:=0A= >>>=0A= >>> In a number of areas, the public switched telephone network (PSTN) has= =0A= >>>=0A= >>> been configured to recognize an explicitly specified number (usually=0A= >>>=0A= >>> one that is short and easily memorized) as a request for emergency=0A= >>>=0A= >>> services. These numbers (e.g., 911, 112) are related to an emergency=0A= >>>=0A= >>> service context and depend on a broad, regional configuration of=0A= >>>=0A= >>> service contact methods and a geographically-constrained approach for= =0A= >>>=0A= >>> service delivery. These calls are intended to be delivered to special= =0A= >>>=0A= >>> call centers equipped to manage emergency response. Successful=0A= >>>=0A= >>> delivery of an emergency service call within those systems requires=0A= >>>=0A= >>> an association of both the physical location of the originating device= =0A= >>>=0A= >>> along with appropriate call routing to an emergency service center.=0A= >>>=0A= >>> Calls placed using Internet technologies do not use the same systems=0A= >>>=0A= >>> Mentioned above to achieve those same goals, and the common use of=0A= >>>=0A= >>> overlay networks and tunnels (either as VPNs or for mobility) makes=0A= >>>=0A= >>> meeting these goals even more challenging. There are, however,=0A= >>>=0A= >>> Internet technologies available to manage location and to perform call= =0A= >>>=0A= >>> routing. This working group will describe where and how these mechanism= s=0A= >>>=0A= >>> may be used. The group will show how the availability of location data= =0A= >>>=0A= >>> and call routing information at different steps in the call session=0A= >>>=0A= >>> setup would enable communication between a user and a relevant emergenc= y=0A= >>>=0A= >>> response center. Though the term "call routing" is used in this=0A= >>> document,=0A= >>>=0A= >>> it should be understood that some of the mechanisms which will be=0A= >>>=0A= >>> described might be used to enable other types of media streams. Video= =0A= >>>=0A= >>> and text messaging, for example, might be used to request emergency=0A= >>>=0A= >>> services.=0A= >>=0A= >> I would omit this last sentence. I also believe that the term=0A= >> "document" isn't appropriate here.=0A= >>=0A= >>=0A= >>>=0A= >>> Beyond human initiated emergency call request mechanisms, this group=0A= >>> will=0A= >>>=0A= >>> develop new methods to request emergency assistance, such as sensor=0A= >>>=0A= >>> initiated emergency requests, and additional processes specified that= =0A= >>>=0A= >>> address topics such as authentication of location, service URN=0A= >>> definition=0A= >>>=0A= >>> and use, augmented information that could assist emergency call=0A= >>> takers or=0A= >>>=0A= >>> responders.=0A= >>=0A= >> s/"authentication of location"/"trustworthy location"=0A= >>=0A= >>>=0A= >>> Explicitly outside the scope of this group is the question of=0A= >>>=0A= >>> pre-emption or prioritization of emergency services traffic. This=0A= >>>=0A= >>> group is considering emergency services calls which might be made by=0A= >>>=0A= >>> any user of the Internet, as opposed to government or military=0A= >>>=0A= >>> services that may impose very different authentication and routing=0A= >>>=0A= >>> requirements.=0A= >>>=0A= >>> While this group anticipates a close working relationship with groups= =0A= >>>=0A= >>> such as NENA and ETSI EMTEL, any solution presented must be useful=0A= >>=0A= >> You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL=0A= >> with "ETSI" since we are now dealing also with other groups in ETSI in= =0A= >> addition to EMTEL.=0A= >>=0A= >>=0A= >>>=0A= >>> regardless of jurisdiction, and it must be possible to use without=0A= >>> requiring a=0A= >>>=0A= >>> single, central authority. Further, it must be possible for multiple=0A= >>>=0A= >>> delegations within a jurisdiction to be handled independently, as call= =0A= >>>=0A= >>> routing for specific emergency types may be handled independently.=0A= >>>=0A= >>> This working group cares about privacy and security concerns, and will= =0A= >>>=0A= >>> address them within its documents.=0A= >>>=0A= >>> Milestones w/revised status/dates, as proposed=0A= >>>=0A= >>> Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the= =0A= >>> IESG=0A= >>>=0A= >>> for consideration as an Informational RFC=0A= >>>=0A= >>> Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for=0A= >>>=0A= >>> consideration as an Informational RFC=0A= >>>=0A= >>> Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call= =0A= >>>=0A= >>> Purposes' to the IESG for consideration as a Standards Track RFC=0A= >>>=0A= >>> Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only=0A= >>>=0A= >>> Emergency Alerts using the Session Initiation Protocol (SIP)' to the=0A= >>> IESG for consideration as an=0A= >>>=0A= >>> Experimental RFC=0A= >>>=0A= >>> Dec 2013 - Submit 'Extensions to the Emergency Services Architecture fo= r=0A= >>>=0A= >>> dealing with Unauthenticated and Unauthorized Devices' to the IESG for= =0A= >>> consideration=0A= >>=0A= >> I thought that this document has been sent to the IESG already.=0A= >>=0A= >>>=0A= >>> as a Standards Track RFC=0A= >>>=0A= >>> Dec 2013 - Submit a draft 'Policy for defining new service-identifying= =0A= >>>=0A= >>> labels' to the IESG for consideration as BCP=0A= >>>=0A= >>> Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'= =0A= >>>=0A= >>> to the IESG for consideration as an Informational RFC=0A= >>>=0A= >>> Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'= =0A= >>>=0A= >>> to the IESG for consideration as a Standards Track RFC=0A= >>=0A= >> I believe you should also list all other concluded documents as well=0A= >> (and mark them as done).=0A= >>=0A= >>=0A= >> Ciao=0A= >> Hannes=0A= >>=0A= >>=0A= >>>=0A= >>> CONFIDENTIALITY NOTICE: The information contained in this message may b= e=0A= >>> privileged and/or confidential. If you are not the intended recipient,= =0A= >>> or responsible for delivering this message to the intended recipient,= =0A= >>> any review, forwarding, dissemination, distribution or copying of this= =0A= >>> communication or any attachment(s) is strictly prohibited. If you have= =0A= >>> received this message in error, please notify the sender immediately,= =0A= >>> and delete it and all attachments from your computer and network.=0A= >>>=0A= >>>=0A= >>>=0A= >>> _______________________________________________=0A= >>> Ecrit mailing list=0A= >>> Ecrit@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/ecrit=0A= >>=0A= >> _______________________________________________=0A= >> Ecrit mailing list=0A= >> Ecrit@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/ecrit=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > Ecrit mailing list=0A= > Ecrit@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/ecrit=0A= =0A= _______________________________________________=0A= Ecrit mailing list=0A= Ecrit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/ecrit=0A= From gunnar.hellstrom@omnitor.se Sun Oct 13 16:53:47 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D3C21E814C for ; Sun, 13 Oct 2013 16:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N24S+YVwoxO6 for ; Sun, 13 Oct 2013 16:53:42 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with ESMTP id 232B621E8143 for ; Sun, 13 Oct 2013 16:53:35 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTPS; Mon, 14 Oct 2013 01:52:56 +0200 (CEST) Received: from [192.168.0.7] (cpe-74-69-52-124.rochester.res.rr.com [74.69.52.124]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id 9018A3A154; Mon, 14 Oct 2013 01:52:55 +0200 (CEST) Message-ID: <525B3258.2040402@omnitor.se> Date: Sun, 13 Oct 2013 19:52:56 -0400 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Gellens, Randall" References: <525AC37C.8090708@gmx.net> <525ACC4D.1020500@omnitor.se>, <525ACF61.7080102@gmx.net> <527682A7144B254C856D43E2B3D9E9371EFB798F@nasanexd01b.na.qualcomm.com> In-Reply-To: <527682A7144B254C856D43E2B3D9E9371EFB798F@nasanexd01b.na.qualcomm.com> Content-Type: multipart/alternative; boundary="------------050309090301050503070807" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 23:53:47 -0000 This is a multi-part message in MIME format. --------------050309090301050503070807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit An addition could be made to this sentence: "Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as callrouting for specific emergency types may be handled independently." To "Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as callrouting for specific emergency types, media types, language contents etc. may be routed differently depending on established policies and availability." And in the goals list include: xxx 2014 - Submit a draft 'Policy based routing in Emergency Services' to the IESG for consideration as a Standards Track RFC Regards Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-10-13 19:22, Gellens, Randall wrote: > The current NENA document on policy-based routing only deals with legacy capabilities (that is, call diversion/exception handling). The NENA group intends to produce a version two that covers NG9-1-1 (NENA i3) capabilities with the enhancements for call processing including media and other needs. > > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Hannes Tschofenig [hannes.tschofenig@gmx.net] > Sent: Sunday, October 13, 2013 9:50 AM > To: Gunnar Hellstrom > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Charter & Milestones update - Comments sought > > Hi Gunnar, > > that's fine with me but where do you want to add this remark in the > charter text Roger proposed? > > Also, do we have any specific document in progress that is impacted by > policy based routing? > > Ciao > Hannes > > > On 13.10.2013 19:37, Gunnar Hellstrom wrote: >> Hi, >> Policy based routing was once said to enable routing based on for >> example media requirements and capabilities to specific PSAPs equipped >> or educated for such calls. >> In latest NENA spec for policy based routing, only PSAP availability is >> mentioned as reason to route. >> >> I do not remember that we have anything sufficiently explicit from IETF >> on this topic, and suggest to include it in the goals. >> >> Thanks, >> Gunnar >> >> >> ------------------------------------------------------------------------ >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46708204288 >> On 2013-10-13 11:59, Hannes Tschofenig wrote: >>> Hi Roger, >>> >>> thanks for working on the updated charter text. >>> >>> The text is fine for me; I only have a few minor suggestions. >>> >>> On 04.10.2013 21:18, Roger Marshall wrote: >>>> The ECRIT working group agreed that the chairs would propose updated >>>> language to the wg charter, along with milestone data changes. >>>> >>>> Compare this to the original charter found at: >>>> http://tools.ietf.org/wg/ecrit/charters. >>>> >>>> Please send your comments to the list, whether in favor, or with >>>> alternative wording and/or dates. >>>> >>>> Regards, >>>> >>>> Roger Marshall/Marc Linsner >>>> >>>> ECRIT Chairs >>>> >>>> ECRIT charter (w/proposed revisions): >>>> >>>> Description of Working Group: >>>> >>>> In a number of areas, the public switched telephone network (PSTN) has >>>> >>>> been configured to recognize an explicitly specified number (usually >>>> >>>> one that is short and easily memorized) as a request for emergency >>>> >>>> services. These numbers (e.g., 911, 112) are related to an emergency >>>> >>>> service context and depend on a broad, regional configuration of >>>> >>>> service contact methods and a geographically-constrained approach for >>>> >>>> service delivery. These calls are intended to be delivered to special >>>> >>>> call centers equipped to manage emergency response. Successful >>>> >>>> delivery of an emergency service call within those systems requires >>>> >>>> an association of both the physical location of the originating device >>>> >>>> along with appropriate call routing to an emergency service center. >>>> >>>> Calls placed using Internet technologies do not use the same systems >>>> >>>> Mentioned above to achieve those same goals, and the common use of >>>> >>>> overlay networks and tunnels (either as VPNs or for mobility) makes >>>> >>>> meeting these goals even more challenging. There are, however, >>>> >>>> Internet technologies available to manage location and to perform call >>>> >>>> routing. This working group will describe where and how these mechanisms >>>> >>>> may be used. The group will show how the availability of location data >>>> >>>> and call routing information at different steps in the call session >>>> >>>> setup would enable communication between a user and a relevant emergency >>>> >>>> response center. Though the term "call routing" is used in this >>>> document, >>>> >>>> it should be understood that some of the mechanisms which will be >>>> >>>> described might be used to enable other types of media streams. Video >>>> >>>> and text messaging, for example, might be used to request emergency >>>> >>>> services. >>> I would omit this last sentence. I also believe that the term >>> "document" isn't appropriate here. >>> >>> >>>> Beyond human initiated emergency call request mechanisms, this group >>>> will >>>> >>>> develop new methods to request emergency assistance, such as sensor >>>> >>>> initiated emergency requests, and additional processes specified that >>>> >>>> address topics such as authentication of location, service URN >>>> definition >>>> >>>> and use, augmented information that could assist emergency call >>>> takers or >>>> >>>> responders. >>> s/"authentication of location"/"trustworthy location" >>> >>>> Explicitly outside the scope of this group is the question of >>>> >>>> pre-emption or prioritization of emergency services traffic. This >>>> >>>> group is considering emergency services calls which might be made by >>>> >>>> any user of the Internet, as opposed to government or military >>>> >>>> services that may impose very different authentication and routing >>>> >>>> requirements. >>>> >>>> While this group anticipates a close working relationship with groups >>>> >>>> such as NENA and ETSI EMTEL, any solution presented must be useful >>> You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL >>> with "ETSI" since we are now dealing also with other groups in ETSI in >>> addition to EMTEL. >>> >>> >>>> regardless of jurisdiction, and it must be possible to use without >>>> requiring a >>>> >>>> single, central authority. Further, it must be possible for multiple >>>> >>>> delegations within a jurisdiction to be handled independently, as call >>>> >>>> routing for specific emergency types may be handled independently. >>>> >>>> This working group cares about privacy and security concerns, and will >>>> >>>> address them within its documents. >>>> >>>> Milestones w/revised status/dates, as proposed >>>> >>>> Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the >>>> IESG >>>> >>>> for consideration as an Informational RFC >>>> >>>> Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for >>>> >>>> consideration as an Informational RFC >>>> >>>> Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call >>>> >>>> Purposes' to the IESG for consideration as a Standards Track RFC >>>> >>>> Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only >>>> >>>> Emergency Alerts using the Session Initiation Protocol (SIP)' to the >>>> IESG for consideration as an >>>> >>>> Experimental RFC >>>> >>>> Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for >>>> >>>> dealing with Unauthenticated and Unauthorized Devices' to the IESG for >>>> consideration >>> I thought that this document has been sent to the IESG already. >>> >>>> as a Standards Track RFC >>>> >>>> Dec 2013 - Submit a draft 'Policy for defining new service-identifying >>>> >>>> labels' to the IESG for consideration as BCP >>>> >>>> Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' >>>> >>>> to the IESG for consideration as an Informational RFC >>>> >>>> Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' >>>> >>>> to the IESG for consideration as a Standards Track RFC >>> I believe you should also list all other concluded documents as well >>> (and mark them as done). >>> >>> >>> Ciao >>> Hannes >>> >>> >>>> CONFIDENTIALITY NOTICE: The information contained in this message may be >>>> privileged and/or confidential. If you are not the intended recipient, >>>> or responsible for delivering this message to the intended recipient, >>>> any review, forwarding, dissemination, distribution or copying of this >>>> communication or any attachment(s) is strictly prohibited. If you have >>>> received this message in error, please notify the sender immediately, >>>> and delete it and all attachments from your computer and network. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --------------050309090301050503070807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
An addition could be made to this sentence:

"Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be handled independently."

To

"Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types, media types, language contents etc.  may be routed differently depending on established policies and availability."

And in the goals list include:

xxx 2014 - Submit a draft 'Policy based routing in Emergency Services'

to the IESG for consideration as a Standards Track RFC

Regards

Gunnar


Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-10-13 19:22, Gellens, Randall wrote:
The current NENA document on policy-based routing only deals with legacy capabilities (that is, call diversion/exception handling).  The NENA group intends to produce a version two that covers NG9-1-1 (NENA i3) capabilities with the enhancements for call processing including media and other needs.

________________________________________
From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Hannes Tschofenig [hannes.tschofenig@gmx.net]
Sent: Sunday, October 13, 2013 9:50 AM
To: Gunnar Hellstrom
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought

Hi Gunnar,

that's fine with me but where do you want to add this remark in the
charter text Roger proposed?

Also, do we have any specific document in progress that is impacted by
policy based routing?

Ciao
Hannes


On 13.10.2013 19:37, Gunnar Hellstrom wrote:

Hi,
Policy based routing was once said to enable routing based on for
example media requirements and capabilities to specific PSAPs equipped
or educated for such calls.
In latest NENA spec for policy based routing, only PSAP availability is
mentioned as reason to route.

I do not remember that we have anything sufficiently explicit from IETF
on this topic, and suggest to include it in the goals.

Thanks,
Gunnar


------------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-10-13 11:59, Hannes Tschofenig wrote:

Hi Roger,

thanks for working on the updated charter text.

The text is fine for me; I only have a few minor suggestions.

On 04.10.2013 21:18, Roger Marshall wrote:

The ECRIT working group agreed that the chairs would propose updated
language to the wg charter, along with milestone data changes.

Compare this to the original charter found at:
http://tools.ietf.org/wg/ecrit/charters.

Please send your comments to the list, whether in favor, or with
alternative wording and/or dates.

Regards,

Roger Marshall/Marc Linsner

ECRIT Chairs

ECRIT charter (w/proposed revisions):

Description of Working Group:

In a number of areas, the public switched telephone network (PSTN) has

been configured to recognize an explicitly specified number (usually

one that is short and easily memorized) as a request for emergency

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

service context and depend on a broad, regional configuration of

service contact methods and a geographically-constrained approach for

service delivery. These calls are intended to be delivered to special

call centers equipped to manage emergency response. Successful

delivery of an emergency service call within those systems requires

an association of both the physical location of the originating device

along with appropriate call routing to an emergency service center.

Calls placed using Internet technologies do not use the same systems

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

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

meeting these goals even more challenging. There are, however,

Internet technologies available to manage location and to perform call

routing. This working group will describe where and how these mechanisms

may be used. The group will show how the availability of location data

and call routing information at different steps in the call session

setup would enable communication between a user and a relevant emergency

response center. Though the term "call routing" is used in this
document,

it should be understood that some of the mechanisms which will be

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

and text messaging, for example, might be used to request emergency

services.

I would omit this last sentence. I also believe that the term
"document" isn't appropriate here.



Beyond human initiated emergency call request mechanisms, this group
will

develop new methods to request emergency assistance, such as sensor

initiated emergency requests, and additional processes specified that

address topics such as authentication of location, service URN
definition

and use, augmented information that could assist emergency call
takers or

responders.

s/"authentication of location"/"trustworthy location"


Explicitly outside the scope of this group is the question of

pre-emption or prioritization of emergency services traffic. This

group is considering emergency services calls which might be made by

any user of the Internet, as opposed to government or military

services that may impose very different authentication and routing

requirements.

While this group anticipates a close working relationship with groups

such as NENA and ETSI EMTEL, any solution presented must be useful

You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL
with "ETSI" since we are now dealing also with other groups in ETSI in
addition to EMTEL.



regardless of jurisdiction, and it must be possible to use without
requiring a

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

delegations within a jurisdiction to be handled independently, as call

routing for specific emergency types may be handled independently.

This working group cares about privacy and security concerns, and will

address them within its documents.

Milestones w/revised status/dates, as proposed

Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the
IESG

for consideration as an Informational RFC

Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for

consideration as an Informational RFC

Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call

Purposes' to the IESG for consideration as a Standards Track RFC

Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only

Emergency Alerts using the Session Initiation Protocol (SIP)' to the
IESG for consideration as an

Experimental RFC

Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for

dealing with Unauthenticated and Unauthorized Devices' to the IESG for
consideration

I thought that this document has been sent to the IESG already.


as a Standards Track RFC

Dec 2013 - Submit a draft 'Policy for defining new service-identifying

labels' to the IESG for consideration as BCP

Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'

to the IESG for consideration as an Informational RFC

Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'

to the IESG for consideration as a Standards Track RFC

I believe you should also list all other concluded documents as well
(and mark them as done).


Ciao
Hannes



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



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

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



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

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

--------------050309090301050503070807-- From hannes.tschofenig@gmx.net Mon Oct 14 00:55:09 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5B521E80E8 for ; Mon, 14 Oct 2013 00:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.623 X-Spam-Level: X-Spam-Status: No, score=-101.623 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6FxYchMl8MK for ; Mon, 14 Oct 2013 00:55:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9515B21F8EC3 for ; Mon, 14 Oct 2013 00:55:04 -0700 (PDT) Received: from [10.255.137.190] ([194.251.119.201]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MQ7sF-1VQPvJ0iMF-005Ekf for ; Mon, 14 Oct 2013 09:55:02 +0200 Message-ID: <525BA34A.2060409@gmx.net> Date: Mon, 14 Oct 2013 10:54:50 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Gellens, Randall" References: <525AC37C.8090708@gmx.net> <525ACC4D.1020500@omnitor.se>, <525ACF61.7080102@gmx.net> <527682A7144B254C856D43E2B3D9E9371EFB798F@nasanexd01b.na.qualcomm.com> In-Reply-To: <527682A7144B254C856D43E2B3D9E9371EFB798F@nasanexd01b.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:v3dYWOWq79kJVI23Z38hTzvrfpTjCSQWNAFXfNXpAUqImx5l6kB puWkGVua2SkLIZXfp90RdcrhlVGTdI9PbVOU58zroRNkE2tLakqbg/qFJr8iMiFulA64iyy /IlVII3GmaIeyWr3++oiwv/W/YlR7VXM2r9F7x5yIdiWlXh+qBeTtj5ezllARlJoJ3GkxKs 5GHFL9MfVTxqppQXwB0Nw== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 07:55:09 -0000 Hi Randy, My question is whether we need to go to that level of detail in the ECRIT charter text. Unless we have a document we want to pick up as a WG item that deals with these issues I don't think we have to talk too much about these details. If you look at other aspects there are reasons why the text mentions things like 'trustworthy location', and 'sensor initiated requests'. Ciao Hannes On 14.10.2013 02:22, Gellens, Randall wrote: > The current NENA document on policy-based routing only deals with legacy capabilities (that is, call diversion/exception handling). The NENA group intends to produce a version two that covers NG9-1-1 (NENA i3) capabilities with the enhancements for call processing including media and other needs. > > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Hannes Tschofenig [hannes.tschofenig@gmx.net] > Sent: Sunday, October 13, 2013 9:50 AM > To: Gunnar Hellstrom > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Charter& Milestones update - Comments sought > > Hi Gunnar, > > that's fine with me but where do you want to add this remark in the > charter text Roger proposed? > > Also, do we have any specific document in progress that is impacted by > policy based routing? > > Ciao > Hannes > > > On 13.10.2013 19:37, Gunnar Hellstrom wrote: >> Hi, >> Policy based routing was once said to enable routing based on for >> example media requirements and capabilities to specific PSAPs equipped >> or educated for such calls. >> In latest NENA spec for policy based routing, only PSAP availability is >> mentioned as reason to route. >> >> I do not remember that we have anything sufficiently explicit from IETF >> on this topic, and suggest to include it in the goals. >> >> Thanks, >> Gunnar >> >> >> ------------------------------------------------------------------------ >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46708204288 >> On 2013-10-13 11:59, Hannes Tschofenig wrote: >>> Hi Roger, >>> >>> thanks for working on the updated charter text. >>> >>> The text is fine for me; I only have a few minor suggestions. >>> >>> On 04.10.2013 21:18, Roger Marshall wrote: >>>> The ECRIT working group agreed that the chairs would propose updated >>>> language to the wg charter, along with milestone data changes. >>>> >>>> Compare this to the original charter found at: >>>> http://tools.ietf.org/wg/ecrit/charters. >>>> >>>> Please send your comments to the list, whether in favor, or with >>>> alternative wording and/or dates. >>>> >>>> Regards, >>>> >>>> Roger Marshall/Marc Linsner >>>> >>>> ECRIT Chairs >>>> >>>> ECRIT charter (w/proposed revisions): >>>> >>>> Description of Working Group: >>>> >>>> In a number of areas, the public switched telephone network (PSTN) has >>>> >>>> been configured to recognize an explicitly specified number (usually >>>> >>>> one that is short and easily memorized) as a request for emergency >>>> >>>> services. These numbers (e.g., 911, 112) are related to an emergency >>>> >>>> service context and depend on a broad, regional configuration of >>>> >>>> service contact methods and a geographically-constrained approach for >>>> >>>> service delivery. These calls are intended to be delivered to special >>>> >>>> call centers equipped to manage emergency response. Successful >>>> >>>> delivery of an emergency service call within those systems requires >>>> >>>> an association of both the physical location of the originating device >>>> >>>> along with appropriate call routing to an emergency service center. >>>> >>>> Calls placed using Internet technologies do not use the same systems >>>> >>>> Mentioned above to achieve those same goals, and the common use of >>>> >>>> overlay networks and tunnels (either as VPNs or for mobility) makes >>>> >>>> meeting these goals even more challenging. There are, however, >>>> >>>> Internet technologies available to manage location and to perform call >>>> >>>> routing. This working group will describe where and how these mechanisms >>>> >>>> may be used. The group will show how the availability of location data >>>> >>>> and call routing information at different steps in the call session >>>> >>>> setup would enable communication between a user and a relevant emergency >>>> >>>> response center. Though the term "call routing" is used in this >>>> document, >>>> >>>> it should be understood that some of the mechanisms which will be >>>> >>>> described might be used to enable other types of media streams. Video >>>> >>>> and text messaging, for example, might be used to request emergency >>>> >>>> services. >>> >>> I would omit this last sentence. I also believe that the term >>> "document" isn't appropriate here. >>> >>> >>>> >>>> Beyond human initiated emergency call request mechanisms, this group >>>> will >>>> >>>> develop new methods to request emergency assistance, such as sensor >>>> >>>> initiated emergency requests, and additional processes specified that >>>> >>>> address topics such as authentication of location, service URN >>>> definition >>>> >>>> and use, augmented information that could assist emergency call >>>> takers or >>>> >>>> responders. >>> >>> s/"authentication of location"/"trustworthy location" >>> >>>> >>>> Explicitly outside the scope of this group is the question of >>>> >>>> pre-emption or prioritization of emergency services traffic. This >>>> >>>> group is considering emergency services calls which might be made by >>>> >>>> any user of the Internet, as opposed to government or military >>>> >>>> services that may impose very different authentication and routing >>>> >>>> requirements. >>>> >>>> While this group anticipates a close working relationship with groups >>>> >>>> such as NENA and ETSI EMTEL, any solution presented must be useful >>> >>> You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL >>> with "ETSI" since we are now dealing also with other groups in ETSI in >>> addition to EMTEL. >>> >>> >>>> >>>> regardless of jurisdiction, and it must be possible to use without >>>> requiring a >>>> >>>> single, central authority. Further, it must be possible for multiple >>>> >>>> delegations within a jurisdiction to be handled independently, as call >>>> >>>> routing for specific emergency types may be handled independently. >>>> >>>> This working group cares about privacy and security concerns, and will >>>> >>>> address them within its documents. >>>> >>>> Milestones w/revised status/dates, as proposed >>>> >>>> Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the >>>> IESG >>>> >>>> for consideration as an Informational RFC >>>> >>>> Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for >>>> >>>> consideration as an Informational RFC >>>> >>>> Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call >>>> >>>> Purposes' to the IESG for consideration as a Standards Track RFC >>>> >>>> Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only >>>> >>>> Emergency Alerts using the Session Initiation Protocol (SIP)' to the >>>> IESG for consideration as an >>>> >>>> Experimental RFC >>>> >>>> Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for >>>> >>>> dealing with Unauthenticated and Unauthorized Devices' to the IESG for >>>> consideration >>> >>> I thought that this document has been sent to the IESG already. >>> >>>> >>>> as a Standards Track RFC >>>> >>>> Dec 2013 - Submit a draft 'Policy for defining new service-identifying >>>> >>>> labels' to the IESG for consideration as BCP >>>> >>>> Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' >>>> >>>> to the IESG for consideration as an Informational RFC >>>> >>>> Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' >>>> >>>> to the IESG for consideration as a Standards Track RFC >>> >>> I believe you should also list all other concluded documents as well >>> (and mark them as done). >>> >>> >>> Ciao >>> Hannes >>> >>> >>>> >>>> CONFIDENTIALITY NOTICE: The information contained in this message may be >>>> privileged and/or confidential. If you are not the intended recipient, >>>> or responsible for delivering this message to the intended recipient, >>>> any review, forwarding, dissemination, distribution or copying of this >>>> communication or any attachment(s) is strictly prohibited. If you have >>>> received this message in error, please notify the sender immediately, >>>> and delete it and all attachments from your computer and network. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From internet-drafts@ietf.org Mon Oct 14 05:07:55 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E1221F9E91; Mon, 14 Oct 2013 05:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1e5EJOTlgFg; Mon, 14 Oct 2013 05:07:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C6121E80B1; Mon, 14 Oct 2013 05:07:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131014120752.25645.74662.idtracker@ietfa.amsl.com> Date: Mon, 14 Oct 2013 05:07:52 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-psap-callback-13.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 12:07:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callback Author(s) : Henning Schulzrinne Hannes Tschofenig Christer Holmberg Milan Patel Filename : draft-ietf-ecrit-psap-callback-13.txt Pages : 15 Date : 2013-10-14 Abstract: After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current situation of a wounded person. A call taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than- normal call treatment behavior would be desirable. A solution based on a new header field value, called "psap-callback", for the SIP Priority header field is specified to accomplish the PSAP callback marking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-psap-callback-13 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 hannes.tschofenig@gmx.net Mon Oct 14 05:15:17 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B924E11E8132 for ; Mon, 14 Oct 2013 05:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.663 X-Spam-Level: X-Spam-Status: No, score=-101.663 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t3HENFr2lj5 for ; Mon, 14 Oct 2013 05:15:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4D121E80CA for ; Mon, 14 Oct 2013 05:15:12 -0700 (PDT) Received: from [10.255.137.190] ([194.251.119.201]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LtJAR-1Vsq2v23OV-012sl1 for ; Mon, 14 Oct 2013 14:15:10 +0200 Message-ID: <525BE043.9090802@gmx.net> Date: Mon, 14 Oct 2013 15:14:59 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "ecrit@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:mGtOBw2hEWYbqQrv2r8DKX5qVZSOzyvyE/bAuisO5BJ0rw1AWEB tVolL2Iv4YUXTSurVvzDbBUVAquPZlv2VvGKyADRSAfU2wlAiWsu+EA8LsmdqEM1VUHrN2W QfaCbPSG9h0lLSL8/B8LbWaA1iILSJBlxvukdnw9+9APTwpwtAWPgLeQtTc7XjOFd99RbFG p5faKCmQql8QQar92LLaA== Subject: [Ecrit] draft-ietf-ecrit-psap-callback-13 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 12:15:17 -0000 Hi all, I just submitted a new version of the PSAP callback document: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-13 There was a fair amount of feedback from the IESG recently and I made the following changes: * I changed the FQDNs in the scenario section to make use of the official examples. * Noted that the solutions in STIR would provide benefits for the identity mechanism. * Enhanced and modified the security consideration section to make it more actionable. It also highlights that the UA needs to maintain a timer to associate a callback to an earlier emergency call. * Added additional references to LoST and the STIR group. The diff can be found here: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-psap-callback-13 I hope that this version addresses the comments from IESG members. Ciao Hannes From randy@qti.qualcomm.com Mon Oct 14 08:26:29 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C90911E8199 for ; Mon, 14 Oct 2013 08:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAOf6seacIQH for ; Mon, 14 Oct 2013 08:26:24 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 32CC711E818A for ; Mon, 14 Oct 2013 08:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1381764384; x=1413300384; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ocymyC6srqmr8sFCpE8WLAfl/LH0vFI5KkX3qnJqmyE=; b=DCB9FZ4940bCx5sm9PQzw2/xDndBxcsFgv/ApOvT8p7KqlG+fO+736cY KD4c60Cq2w1zd7eVxGsf4SGOTWAVKe7hC4UmWFgr03tlvU4qYyoeYwPPu K5z204mutKRjs65dcX/bVMyNoXgoz7rm3+coOwy1rzhL2V0fImGkn+4ES 4=; X-IronPort-AV: E=McAfee;i="5400,1158,7227"; a="54169929" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP; 14 Oct 2013 08:26:05 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7227"; a="568647439" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Oct 2013 08:26:05 -0700 Received: from NASANEXD01B.na.qualcomm.com ([169.254.2.160]) by NASANEXHC17.na.qualcomm.com ([10.45.158.129]) with mapi id 14.03.0158.001; Mon, 14 Oct 2013 08:26:04 -0700 From: "Gellens, Randall" To: Hannes Tschofenig Thread-Topic: [Ecrit] Charter & Milestones update - Comments sought Thread-Index: Ac7BLfNZgOHANmOzQNGU4fpZSblfKQHOfvQAAAFQUYAAAHVsgP//94XNgAEFGACAAAhT7Q== Date: Mon, 14 Oct 2013 15:26:03 +0000 Message-ID: <527682A7144B254C856D43E2B3D9E9371EFB8C96@nasanexd01b.na.qualcomm.com> References: <525AC37C.8090708@gmx.net> <525ACC4D.1020500@omnitor.se>,<525ACF61.7080102@gmx.net> <527682A7144B254C856D43E2B3D9E9371EFB798F@nasanexd01b.na.qualcomm.com>, <525BA34A.2060409@gmx.net> In-Reply-To: <525BA34A.2060409@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 15:26:29 -0000 Hi Hannes,=0A= =0A= Sorry for not being more explicit. I'm not suggesting that the charter go = into the details of NENA's work on policy-based routing, far from it. I'm = pointing out that NENA is actively engaged in the topic, and hence, I don't= see a current need for the IETF to develop a document in this area.=0A= =0A= ________________________________________=0A= From: Hannes Tschofenig [hannes.tschofenig@gmx.net]=0A= Sent: Monday, October 14, 2013 12:54 AM=0A= To: Gellens, Randall=0A= Cc: Hannes Tschofenig; Gunnar Hellstrom; ecrit@ietf.org=0A= Subject: Re: [Ecrit] Charter & Milestones update - Comments sought=0A= =0A= Hi Randy,=0A= =0A= My question is whether we need to go to that level of detail in the=0A= ECRIT charter text.=0A= =0A= Unless we have a document we want to pick up as a WG item that deals=0A= with these issues I don't think we have to talk too much about these=0A= details.=0A= =0A= If you look at other aspects there are reasons why the text mentions=0A= things like 'trustworthy location', and 'sensor initiated requests'.=0A= =0A= Ciao=0A= Hannes=0A= =0A= On 14.10.2013 02:22, Gellens, Randall wrote:=0A= > The current NENA document on policy-based routing only deals with legacy = capabilities (that is, call diversion/exception handling). The NENA group = intends to produce a version two that covers NG9-1-1 (NENA i3) capabilities= with the enhancements for call processing including media and other needs.= =0A= >=0A= > ________________________________________=0A= > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Hannes= Tschofenig [hannes.tschofenig@gmx.net]=0A= > Sent: Sunday, October 13, 2013 9:50 AM=0A= > To: Gunnar Hellstrom=0A= > Cc: ecrit@ietf.org=0A= > Subject: Re: [Ecrit] Charter& Milestones update - Comments sought=0A= >=0A= > Hi Gunnar,=0A= >=0A= > that's fine with me but where do you want to add this remark in the=0A= > charter text Roger proposed?=0A= >=0A= > Also, do we have any specific document in progress that is impacted by=0A= > policy based routing?=0A= >=0A= > Ciao=0A= > Hannes=0A= >=0A= >=0A= > On 13.10.2013 19:37, Gunnar Hellstrom wrote:=0A= >> Hi,=0A= >> Policy based routing was once said to enable routing based on for=0A= >> example media requirements and capabilities to specific PSAPs equipped= =0A= >> or educated for such calls.=0A= >> In latest NENA spec for policy based routing, only PSAP availability is= =0A= >> mentioned as reason to route.=0A= >>=0A= >> I do not remember that we have anything sufficiently explicit from IETF= =0A= >> on this topic, and suggest to include it in the goals.=0A= >>=0A= >> Thanks,=0A= >> Gunnar=0A= >>=0A= >>=0A= >> ------------------------------------------------------------------------= =0A= >> Gunnar Hellstr=F6m=0A= >> Omnitor=0A= >> gunnar.hellstrom@omnitor.se=0A= >> +46708204288=0A= >> On 2013-10-13 11:59, Hannes Tschofenig wrote:=0A= >>> Hi Roger,=0A= >>>=0A= >>> thanks for working on the updated charter text.=0A= >>>=0A= >>> The text is fine for me; I only have a few minor suggestions.=0A= >>>=0A= >>> On 04.10.2013 21:18, Roger Marshall wrote:=0A= >>>> The ECRIT working group agreed that the chairs would propose updated= =0A= >>>> language to the wg charter, along with milestone data changes.=0A= >>>>=0A= >>>> Compare this to the original charter found at:=0A= >>>> http://tools.ietf.org/wg/ecrit/charters.=0A= >>>>=0A= >>>> Please send your comments to the list, whether in favor, or with=0A= >>>> alternative wording and/or dates.=0A= >>>>=0A= >>>> Regards,=0A= >>>>=0A= >>>> Roger Marshall/Marc Linsner=0A= >>>>=0A= >>>> ECRIT Chairs=0A= >>>>=0A= >>>> ECRIT charter (w/proposed revisions):=0A= >>>>=0A= >>>> Description of Working Group:=0A= >>>>=0A= >>>> In a number of areas, the public switched telephone network (PSTN) has= =0A= >>>>=0A= >>>> been configured to recognize an explicitly specified number (usually= =0A= >>>>=0A= >>>> one that is short and easily memorized) as a request for emergency=0A= >>>>=0A= >>>> services. These numbers (e.g., 911, 112) are related to an emergency= =0A= >>>>=0A= >>>> service context and depend on a broad, regional configuration of=0A= >>>>=0A= >>>> service contact methods and a geographically-constrained approach for= =0A= >>>>=0A= >>>> service delivery. These calls are intended to be delivered to special= =0A= >>>>=0A= >>>> call centers equipped to manage emergency response. Successful=0A= >>>>=0A= >>>> delivery of an emergency service call within those systems requires=0A= >>>>=0A= >>>> an association of both the physical location of the originating device= =0A= >>>>=0A= >>>> along with appropriate call routing to an emergency service center.=0A= >>>>=0A= >>>> Calls placed using Internet technologies do not use the same systems= =0A= >>>>=0A= >>>> Mentioned above to achieve those same goals, and the common use of=0A= >>>>=0A= >>>> overlay networks and tunnels (either as VPNs or for mobility) makes=0A= >>>>=0A= >>>> meeting these goals even more challenging. There are, however,=0A= >>>>=0A= >>>> Internet technologies available to manage location and to perform call= =0A= >>>>=0A= >>>> routing. This working group will describe where and how these mechanis= ms=0A= >>>>=0A= >>>> may be used. The group will show how the availability of location data= =0A= >>>>=0A= >>>> and call routing information at different steps in the call session=0A= >>>>=0A= >>>> setup would enable communication between a user and a relevant emergen= cy=0A= >>>>=0A= >>>> response center. Though the term "call routing" is used in this=0A= >>>> document,=0A= >>>>=0A= >>>> it should be understood that some of the mechanisms which will be=0A= >>>>=0A= >>>> described might be used to enable other types of media streams. Video= =0A= >>>>=0A= >>>> and text messaging, for example, might be used to request emergency=0A= >>>>=0A= >>>> services.=0A= >>>=0A= >>> I would omit this last sentence. I also believe that the term=0A= >>> "document" isn't appropriate here.=0A= >>>=0A= >>>=0A= >>>>=0A= >>>> Beyond human initiated emergency call request mechanisms, this group= =0A= >>>> will=0A= >>>>=0A= >>>> develop new methods to request emergency assistance, such as sensor=0A= >>>>=0A= >>>> initiated emergency requests, and additional processes specified that= =0A= >>>>=0A= >>>> address topics such as authentication of location, service URN=0A= >>>> definition=0A= >>>>=0A= >>>> and use, augmented information that could assist emergency call=0A= >>>> takers or=0A= >>>>=0A= >>>> responders.=0A= >>>=0A= >>> s/"authentication of location"/"trustworthy location"=0A= >>>=0A= >>>>=0A= >>>> Explicitly outside the scope of this group is the question of=0A= >>>>=0A= >>>> pre-emption or prioritization of emergency services traffic. This=0A= >>>>=0A= >>>> group is considering emergency services calls which might be made by= =0A= >>>>=0A= >>>> any user of the Internet, as opposed to government or military=0A= >>>>=0A= >>>> services that may impose very different authentication and routing=0A= >>>>=0A= >>>> requirements.=0A= >>>>=0A= >>>> While this group anticipates a close working relationship with groups= =0A= >>>>=0A= >>>> such as NENA and ETSI EMTEL, any solution presented must be useful=0A= >>>=0A= >>> You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL=0A= >>> with "ETSI" since we are now dealing also with other groups in ETSI in= =0A= >>> addition to EMTEL.=0A= >>>=0A= >>>=0A= >>>>=0A= >>>> regardless of jurisdiction, and it must be possible to use without=0A= >>>> requiring a=0A= >>>>=0A= >>>> single, central authority. Further, it must be possible for multiple= =0A= >>>>=0A= >>>> delegations within a jurisdiction to be handled independently, as call= =0A= >>>>=0A= >>>> routing for specific emergency types may be handled independently.=0A= >>>>=0A= >>>> This working group cares about privacy and security concerns, and will= =0A= >>>>=0A= >>>> address them within its documents.=0A= >>>>=0A= >>>> Milestones w/revised status/dates, as proposed=0A= >>>>=0A= >>>> Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the= =0A= >>>> IESG=0A= >>>>=0A= >>>> for consideration as an Informational RFC=0A= >>>>=0A= >>>> Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for= =0A= >>>>=0A= >>>> consideration as an Informational RFC=0A= >>>>=0A= >>>> Dec 2013 - Submit 'Additional Data related to a Call for Emergency Cal= l=0A= >>>>=0A= >>>> Purposes' to the IESG for consideration as a Standards Track RFC=0A= >>>>=0A= >>>> Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only=0A= >>>>=0A= >>>> Emergency Alerts using the Session Initiation Protocol (SIP)' to the= =0A= >>>> IESG for consideration as an=0A= >>>>=0A= >>>> Experimental RFC=0A= >>>>=0A= >>>> Dec 2013 - Submit 'Extensions to the Emergency Services Architecture f= or=0A= >>>>=0A= >>>> dealing with Unauthenticated and Unauthorized Devices' to the IESG for= =0A= >>>> consideration=0A= >>>=0A= >>> I thought that this document has been sent to the IESG already.=0A= >>>=0A= >>>>=0A= >>>> as a Standards Track RFC=0A= >>>>=0A= >>>> Dec 2013 - Submit a draft 'Policy for defining new service-identifying= =0A= >>>>=0A= >>>> labels' to the IESG for consideration as BCP=0A= >>>>=0A= >>>> Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing= '=0A= >>>>=0A= >>>> to the IESG for consideration as an Informational RFC=0A= >>>>=0A= >>>> Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services= '=0A= >>>>=0A= >>>> to the IESG for consideration as a Standards Track RFC=0A= >>>=0A= >>> I believe you should also list all other concluded documents as well=0A= >>> (and mark them as done).=0A= >>>=0A= >>>=0A= >>> Ciao=0A= >>> Hannes=0A= >>>=0A= >>>=0A= >>>>=0A= >>>> CONFIDENTIALITY NOTICE: The information contained in this message may = be=0A= >>>> privileged and/or confidential. If you are not the intended recipient,= =0A= >>>> or responsible for delivering this message to the intended recipient,= =0A= >>>> any review, forwarding, dissemination, distribution or copying of this= =0A= >>>> communication or any attachment(s) is strictly prohibited. If you have= =0A= >>>> received this message in error, please notify the sender immediately,= =0A= >>>> and delete it and all attachments from your computer and network.=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> _______________________________________________=0A= >>>> Ecrit mailing list=0A= >>>> Ecrit@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/ecrit=0A= >>>=0A= >>> _______________________________________________=0A= >>> Ecrit mailing list=0A= >>> Ecrit@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/ecrit=0A= >>=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> Ecrit mailing list=0A= >> Ecrit@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/ecrit=0A= >=0A= > _______________________________________________=0A= > Ecrit mailing list=0A= > Ecrit@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/ecrit=0A= =0A= From internet-drafts@ietf.org Wed Oct 16 01:25:52 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F89321F9C88; Wed, 16 Oct 2013 01:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg0qaky8MGt5; Wed, 16 Oct 2013 01:25:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B64821F9C90; Wed, 16 Oct 2013 01:25:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131016082550.32157.97920.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2013 01:25:50 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-12.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 08:25:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens James Winterbottom Filename : draft-ietf-ecrit-additional-data-12.txt Pages : 85 Date : 2013-10-16 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-12 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 Oct 16 02:14:19 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C22F11E82C2; Wed, 16 Oct 2013 02:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8viqRxshTUfI; Wed, 16 Oct 2013 02:14:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D59811E826D; Wed, 16 Oct 2013 02:14:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131016091416.32193.78065.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2013 02:14:16 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-13.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:14:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens James Winterbottom Filename : draft-ietf-ecrit-additional-data-13.txt Pages : 86 Date : 2013-10-16 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-13 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 hannes.tschofenig@gmx.net Wed Oct 16 02:25:44 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8178321F9E14 for ; Wed, 16 Oct 2013 02:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s31voB+ukjCZ for ; Wed, 16 Oct 2013 02:25:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 36F5621F9D87 for ; Wed, 16 Oct 2013 02:25:19 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MhQxO-1V9jrK1CwU-00MaVc for ; Wed, 16 Oct 2013 11:25:08 +0200 Message-ID: <525E5B92.7040106@gmx.net> Date: Wed, 16 Oct 2013 11:25:38 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "STARK, BARBARA H" , "ecrit@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130317C8F@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130317C8F@GAALPA1MSGUSR9L.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:P209voj9egJJyIMj/9pI7cPcCrnpNRs/MTIMFcadgDeOrCfQbeu 0ai8+Ft8VHLeMlB9f1bHeLsPH5hRWlFyg1MibReF37CpggMWIM29hUJCcx2Y8zLWBKKq4Ow rTpEfvW8OJE9lK+o6RpJH7AEMfy1zzU26burNY++grCIIblaVlSQgTsRB7+mjA3lmiRGw3I MGXtxx0wJ9frhE8IPSH+g== Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10: comments on data provider elements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:25:44 -0000 Hi Barbara, based on your review James and I had updated the text. Here is the new version: ------ 3.1. Data Provider Information This block is intended to be provided by any service provider in the path of the call or the access network provider. It includes identification and contact information. This block SHOULD be provided by every service provider in the call path, and by the access network provider. Devices MAY use this block to provide identifying information. The MIME subtype is "application/ emergencyCall.ProviderInfo+xml". An access network provider SHOULD provide this block either by value or by reference in the Provided-By section of a PIDF-LO 3.1.1. Data Provider String Data Element: Data Provider String Use: Required XML Element: Description: This is a plain language string suitable for displaying the name of the service provider that created the additional data structure. If the device created the structure the value is identical to the contact header in the SIP INVITE. Reason for Need: Inform the call taker of the identity of the entity providing the additional call data structure. How Used by Call Taker: Allows the call taker to interpret the data in this structure. The source of the information often influences how the information is used, believed or verified. 3.1.2. Data Provider ID Data Element: Data Provider ID Use: Conditional. This data SHOULD be provided if the service provider or access provider is located in a jurisdiction that maintains such ids. For example, in North America, this would be a "NENA Company ID". XML Element: Description: A jurisdiction specific code for the access provider or service provider shown in the element that created the structure of the call. NOTE: In the US, the NENA Company ID must appear here. Additional information can be found at http://www.nena.org/nena-company-id. The NENA Company ID MUST be in the form of a URI in the following format: urn:nena:companyid: Reason for Need: Inform the call taker of the identity of the entity providing the additional call data structure. How Used by Call Taker: Where jurisdictions have lists of providers the Data Provider ID provides useful information about the data source. 3.1.3. Data Provider ID Series Data Element: Data Provider ID Series Use: Conditional. If Data Provider ID is provided, Data Provider ID Series is required. XML Element: Description: Identifies the issuer of the ProviderId. A registry will reflect the following valid entries: * NENA * EENA Reason for Need: Identifies how to interpret the Data Provider ID. How Used by Call Taker: Determines which provider ID registry to consult for more information 3.1.4. Type of Data Provider Data Element: Type of Data Provider ID Use: Conditional. If Data Provider ID is provided, Type of Data Provider ID is required. XML Element: Description: Identifies the type of data provider id being supplied in the ProviderId data element. A registry with an initial set of values is shown in Figure 1. +------------------------------+------------------------------------+ | Token | Description | +------------------------------+------------------------------------+ |Access Network Provider | Access network service provider | |Service Provider | Calling or Origination telecom SP | |Service Provider Subcontractor| A contractor to another kind of SP | |Telematics Provider | A sensor based SP, especially | | | vehicle based | |Language Translation Provider | A spoken language translation SP | |Emergency Service Provider | An emergency service provider | | | conveying information to another | | | emergency service provider. | |Emergency Modality Translation| An emergency call specific | | | modality translation service | | | e.g., for sign language | |Relay Provider | A interpretation SP, for example, | | | video relay for sign language | | | interpreting | |Other | Any other type of service provider | +------------------------------+------------------------------------+ Figure 1: Type of Data Provider ID Registry. Reason for Need: Identifies what kind of data provider this is. How Used by Call Taker: To decide who to contact when further information is needed 3.1.5. Data Provider Contact URI Data Element: Data Provider Contact URI Use: Required XML Element: Description: When provided by a service provider or an access provider, this information MUST be a URI to a 24/7 support organization tasked to provide PSAP support for this emergency call. If the call is from a device, this would reflect the contact information of the owner of the device. If a telephone number is the contact address then it MUST be tel URI. If it is provided as a SIP URI then it MUST be in the form of sip:telephonenumber@serviceprovider:user=phone. Reason for Need: Additional data providers may need to be contacted for error or other unusual circumstances. How Used by Call Taker: To contact the supplier of the additional data for assistance in handling the call. 3.1.6. Data Provider Languages(s) Supported Data Element: Data Provider Language(s) supported Use: Conditional XML Element: Description: The language used by the entity at the Data Provider Contact URI as an alpha 2-character code as defined in ISO 639-1:2002 Codes for the representation of names of languages -- Part 1: Alpha-2 code Multiple instances of this element may occur. Order is significant; preferred language should appear first. This data is required if a Data Provider Contact URI is provided. The content must reflect the languages supported at the contact URI. Reason for Need: Information needed to determine if emergency service authority can communicate with the service provider or if an interpreter will be needed. How Used by Call Taker: If call taker cannot speak language(s) supported by the service provider, a translation service will need to be added to the conversation. ------ We made clarifications to Sections 3.1, Section 3.1.2, Section 3.1.5 and Section 3.1.6. Do you think we got closer clarifying the text to meet the concerns you raised? A few remarks below: On 07/31/2013 07:06 PM, STARK, BARBARA H wrote: > I finished my review of draft-ietf-ecrit-additional-data-10. I'm > sending my comments divided among 5 emails. These are miscellaneous > comments on data provider elements. Barbara ------------------- 3.1. > Data Provider Information > > This block is intended to be provided by any service provider in the > path of the call or the access network provider. It includes > identification and contact information. This block SHOULD be > provided by every service provider in the call path, and by the > access network provider . Devices MAY use this block to provide > identifying information. The MIME subtype is "application/ > emergencyCall.ProviderInfo+xml". > > Comment 1: How are you expecting an access provider to know to > include this block? What is the trigger? This could be a problematic > recommendation as some access providers are explicitly forbidden from > altering anything in the IP payloads of the packets they > transport/route. If IP payload is encrypted, then it can't be done. > But if the expectation is that this would happen when providing > location (so it's in the Reference/Value Provided-By of supplied > location), then that's ok but it might be useful to mention this. The access provider includes this information via the PIDF-LO and the service provider includes it via the SIP mechanism. The same data structures are used for both mechanisms. For this reason there is no need to do a "DPI-alike" functionality. I was hoping that the text in Section 4 ("Transport") clarifies this aspects but maybe we should move the transport section to an earlier part of the document. > ------------------- 3.1.2. Data Provider ID > > Data Element: Data Provider ID > > Use : Conditional. Must be provided if the service provider is > located in a jurisdiction that maintains such ids . Devices are not > required to provide it. > > Description: A jurisdiction specific code for the provider shown > in the element that created the structure of the > call. This data SHOULD be provided if the local jurisdiction > maintains such an ID list. For example, in North America, this would > be a "NENA Company ID". Devices SHOULD NOT use this element. > > Comment 2: Needs to say something about access provider use. Comment > 3: I don't think this sort of condition (dependency on whether some > undefined organization in undefined jurisdictions do or don't do > something) belongs in a RFC. Compliance is difficult to ascertain. My > opinion is that this information would be better as guidance rather > than normative. Comment 4: The first use of "provider" in Description > may need to be more specific. "Provider" as a stand-alone term is > undefined, but it may be that only service providers will have > jurisdiction specific codes, and not necessarily an access network > provider. We changed the text to avoid this concern. -------------------- 3.1.5. Data Provider Contact URI Use: > Required Description: For a service provider the contact SHOULD be > a contact URI. This MUST be a SIP URI. If a telephone number is > the contact address it should be provided in the form of > sip:telephonenumber@serviceprovider:user=phone. If the call is from > a device, this would reflect the contact information of the owner of > the device. When provided by a service provider, this would be a URI > to a 24/7 support organization tasked to provide PSAP support for > this emergency call. > > Comment 5: This is confusing. A ContactURI *should* be a ContactURI? > What else could it be? Comment 6: What is the antecedent of "This" > (This MUST be a SIP URI)? Is "This" the optional contact URI from the > previous sentence (if contact is ContactURI then it MUST be a SIP > URI)? Comment 7: Is the 2nd should a normative SHOULD? Or is this > more of "will" or non-normative "may"? We also changed this text to avoid confusion. -------------------- 3.1.6. > Data Provider Languages(s) Supported How Used by Call Taker: If call > taker cannot speak language(s) supported by the service provider, a > translation service will need to be added to the conversation. > > Comment 8: Is this really the call taker or maybe also someone else > at PSAP? Typically, the call takers do the work but you are right that in certain situations someone else might be involved as well. So, we should soften that language. Cia Hannes > > _______________________________________________ Ecrit mailing list > Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@gmx.net Wed Oct 16 02:28:20 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2625B21F9D04 for ; Wed, 16 Oct 2013 02:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRqfgwhz4uIk for ; Wed, 16 Oct 2013 02:28:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 282EC11E815B for ; Wed, 16 Oct 2013 02:27:41 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MYfX0-1VIZuT3lz8-00VM9N for ; Wed, 16 Oct 2013 11:27:40 +0200 Message-ID: <525E5C2A.4040009@gmx.net> Date: Wed, 16 Oct 2013 11:28:10 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "STARK, BARBARA H" , "ecrit@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130317CBE@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130317CBE@GAALPA1MSGUSR9L.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:kRfZj74G9OYLSyW6JD2qpjwAn42w5T6KvEh8Lfb3mMpo8vY5M+w ap/oesTKKMOz4TRw4kjC8Ae6bmy88BqB9Mzfeh9p1LMT7Cwyl+eqcEyq37yj84zTBL1oPXu k/Np4LGUljmvylpsNpHHVPunvwbMQXgyEmMFyuhY9SlMYsoLVEJGGZYpLCM64BAt3q80ShP ioXU3m8KUlQXitaPbwgYw== Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10: soft client as device X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:28:20 -0000 Hi Barbara, On 07/31/2013 07:08 PM, STARK, BARBARA H wrote: > There are a couple of places where it seems like a soft client can't properly describe itself > > Figure 5 : Device Classification Registry > Comment 18: It seems to me that a soft client might know that it is a soft client and what its underlying OS is, but it may not know what type of computing device it is on. Should there be any less specific choices for such cases, like "Soft client, computing device unknown"? We added the softphone to the "Device Classification Registry": +--------+----------------------------------------+ | Token | Description | +--------+----------------------------------------+ |Cordless| Cordless handset | | Fixed | Fixed phone | | Mobile | Mobile handset | | ATA | analog terminal adapter | |Satphone| Satellite phone | | FSense | Stationary computing device (alarm | | | system, data sensor) | | Guard | Guardian devices | | Desktop| Desktop PC | | Laptop | Laptop computing device | | Tablet | Tablet computing device | | Alarm | Alarm system | | MSense | Mobile Data sensor | | Beacon | Personal beacons (spot) | | Auto | Auto telematics | | Truck | Truck telematics | | Farm | Farm equipment telematics | | Marine | Marine telematics | | PDA | Personal digital assistant | | PND | Personal navigation device) | | SmrtPhn| Smart phone | | Itab | Internet tablet | | Game | Gaming console | | Video | Video phone | | Text | Other text device | |SoftPhn | Soft phone or soft client software | | NA | Not Available | +--------+----------------------------------------+ Figure 5: Device Classification Registry. > ------------ > 3.3.5. Type of Device Identifier > Comment 19: If the call is from a soft client, is it expected that the soft client know this info about the underlying computing device? If the software is unable to retrieve device identifiers then there is no need for it to include those. The ability to access these low-level identifiers might depend on the specific software / language used. The data structure does not require the field to be present. Ciao Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@gmx.net Wed Oct 16 02:52:09 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C413211E8255 for ; Wed, 16 Oct 2013 02:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh7H8j2-ELTF for ; Wed, 16 Oct 2013 02:52:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3D16F11E81B1 for ; Wed, 16 Oct 2013 02:52:03 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MJByE-1VTdwx3V6o-002sCD for ; Wed, 16 Oct 2013 11:52:02 +0200 Message-ID: <525E61E0.8050408@gmx.net> Date: Wed, 16 Oct 2013 11:52:32 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "STARK, BARBARA H" , "ecrit@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130317CDF@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130317CDF@GAALPA1MSGUSR9L.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:KVtoL/mG7xsf1TH4QAe6iJkrNOemy3HPbWLrUWeWnQbl6cKewJJ hzgUZEh7xztlALH8+MwvraIH2kwq2Dyj98tElztHfcl+aVeDTCz1XHH5zzuOoJybwvSVszI 9UkYQfShPHmVXwH6pGENImcgg7OvDKk1WYYu3k0muTaF4iImDBMRZjjFHBXnbxWF8zzmA6w zJtX+t0gLAcLpwy4529oQ== Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10: mandatory elements in blocks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:52:09 -0000 Hi Barbara, On 07/31/2013 07:09 PM, STARK, BARBARA H wrote: > Comments related to blocks with no mandatory elements. The Use > statements for an element should not be considered a statement as to > whether the block itself is mandatory or optional. Bock > usage/inclusion Use statements need to be elsewhere. So Use of an > element is restricted to use of that element within a block that > exists. ------------- 3.3. Device Information > > Comment 20: It's sort of weird that there's not a single required > element for this block. But, ok. We found it hard to declare some of the data elements mandatory given the wide range of scenarios where additional data is used. > Does this mean it's possible to have > the block present with nothing in it? Theoretically, this is possible. Of course, it wouldn't be useful as such. -------------- 3.4.1. xCard > for Subscriber's Data Use: Conditional : Some services (e.g., > prepaid phones, initialized phones, etc.) may not have this > information. > > Comment 21: What's the condition? Or is it really just Optional? As > with DeviceInfo block, there are no required elements. We changed the wording: ----- 3.4.2. xCard for Subscriber's Data Data Element: xCARD for Subscriber's Data Use: Conditional. Subscriber data is provided unless it is not available. Some services, for example prepaid phones, non- initialized phones, etc., do not have information about the subscriber. XML Element: Description: Information known by the service provider or device about the subscriber; e.g., Name, Address, Individual Telephone Number, Main Telephone Number and any other data. N, ORG (if appropriate), ADR, TEL, EMAIL are suggested at a minimum. If more than one TEL property is provided, a parameter from the vCard Property Value registry MUST be specified on each TEL. Reason for Need: When the caller is unable to provide information, this data may be used to obtain it How Used by Call Taker: Obtaining critical information about the caller and possibly the location when it is not able to be obtained otherwise. ----- But in this > case, this is the only possible element. So it seems that if a > Subscriber block exists, then this SubscriberData element is > Required. Otherwise it makes no sense for the Subscriber block to > exist. At the moment this is the only possible element but the structure is extensible and so there could be something else in the future. -------------- 3.5.1. Comment > > Data Element: EmergencyCall.Comment > > Use: Optional > > Comment 22: Again, it makes no sense for the one possible element of > a block to be optional when that block is present. This is a > statement about the existence of this element in the block and not > about the block itself. All blocks are effectively optional. It is true that it is not useful to send an empty block and we could say that but of course that does not prvent anyone from still sending it. So, there is no harm in sending an empty block since it will just be parsed and nothing happens. Ciao Hannes > _______________________________________________ Ecrit mailing list > Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@gmx.net Wed Oct 16 02:58:43 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9C511E8177 for ; Wed, 16 Oct 2013 02:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ovCYGUssqUa for ; Wed, 16 Oct 2013 02:58:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 91A1411E8174 for ; Wed, 16 Oct 2013 02:58:38 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lvkwm-1Vp9Dk3BG8-017Sam for ; Wed, 16 Oct 2013 11:58:37 +0200 Message-ID: <525E636B.5040209@gmx.net> Date: Wed, 16 Oct 2013 11:59:07 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "STARK, BARBARA H" , "ecrit@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130317D01@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130317D01@GAALPA1MSGUSR9L.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:+0mk1HFP3nRuF/mPRsr01Yfj/aOI8AN/PFypvJ4TpipbP915+f8 Gh2OCuXSm/cwtFo7Ce03w78smNlmQQJBJ4+eLVV9lkG1WiFdiDPodvMqgnN6TdqnAaOzD4G uJ2RtNIikIBogLe0A+KNVT3gHFuT3gle/AMkQi7L+9+5nekcMwP2Ah+0hu4cjS40g6QkTko 2SgEo8Ma85z6O8N0kg3Ig== Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10: Comments that shouldn't be controversial X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:58:43 -0000 Hi Barbara, On 07/31/2013 07:10 PM, STARK, BARBARA H wrote: > I've grouped all of my comments that I don't expect to be controversial (or to require much discussion) in this email. > I also provided the authors with a set of spelling errors that I'm not going to send to the list. > > ---------- > 2. Terminology > 'Conditional': means they must be present unless the specified > condition is met, in which case the they may be present. > > Comment 23: "unless the specified condition is met" is not right. One possibility would be "if the specific condition is met". James changed the writeup of the terminology section to: ----- In the data block definitions, see Section 3, the values for the "Use:" label are specified as one of: 'Required': means they MUST be present in the data structure. 'Conditional': means they MUST be present if the specified condition(s) is met. They MAY be present if the condition(s) is not met. 'Optional': means they MAY be present. ----- > ----------- > 3.1.2. Data Provider ID > > Use : Conditional. Must be provided if the service provider is > located in a jurisdiction that maintains such ids . Devices are > not required to provide it. > > Description: A jurisdiction specific code for the provider shown in > the element that created the structure of the > call. This data SHOULD be provided if the local jurisdiction > maintains such an ID list. For example, in North America, this > would be a "NENA Company ID". Devices SHOULD NOT use this > element. > > Comment 24: Normative language from Description belongs in Use Text changed to: ----- 3.1.2. Data Provider ID Data Element: Data Provider ID Use: Conditional. This data SHOULD be provided if the service provider or access provider is located in a jurisdiction that maintains such ids. For example, in North America, this would be a "NENA Company ID". XML Element: Description: A jurisdiction specific code for the access provider or service provider shown in the element that created the structure of the call. NOTE: In the US, the NENA Company ID must appear here. Additional information can be found at http://www.nena.org/nena-company-id. The NENA Company ID MUST be in the form of a URI in the following format: urn:nena:companyid: Reason for Need: Inform the call taker of the identity of the entity providing the additional call data structure. How Used by Call Taker: Where jurisdictions have lists of providers the Data Provider ID provides useful information about the data source. ----- > ------------ > 3.1.6. Data Provider Languages(s) Supported > > Use: Conditional > > Description: The language used by the entity at the Data Provider > Contact URI as an alpha 2-character code as defined in ISO > 639-1:2002 Codes for the representation of names of languages -- > Part 1: Alpha-2 code Multiple instances of this element may occur. > Order is significant; preferred language should appear first. > This data is required if a Data Provider Contact URI is provided. > The content must reflect the languages supported at the contact > URI. > > Comment 25: Conditional on what? Should the conditional sentence in Description (penultimate sentence) be moved to Use to be consistent with other Use fields? > Comment 26: Since Contact URI is required, and this field is conditional upon a required field, doesn't that make this required? Fixed. Turned into 'required'. > ------------ > 3.3.6. Device/Service Specific Additional Data Structure > VEDs / VEDS > Comment 26: I don't know this acronym. Can you spell it out? And use it consistently (VEDs or VEDS)? Done. > ------------ > 7. Security Considerations > PKI > Comment 27: Spell this out. Done. Ciao Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From christer.holmberg@ericsson.com Wed Oct 16 03:10:03 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA5F21F9E68 for ; Wed, 16 Oct 2013 03:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MS282IGT5gjs for ; Wed, 16 Oct 2013 03:09:57 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1C911E81B1 for ; Wed, 16 Oct 2013 03:09:56 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-76-525e65f320fb Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EA.95.16099.3F56E525; Wed, 16 Oct 2013 12:09:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 12:09:55 +0200 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-13.txt Thread-Index: AQHOylAcv577HfCsFEiK2ArN2m4aq5n3Fchg Date: Wed, 16 Oct 2013 10:09:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BFFBE@ESESSMB209.ericsson.se> References: <20131016091416.32193.78065.idtracker@ietfa.amsl.com> In-Reply-To: <20131016091416.32193.78065.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+Jvre7n1Lggg42XFS0aFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsnb25kKHstX3L37jL2BsVeyi5GDQ0LAROLxL98uRk4gU0zi wr31bF2MXBxCAocZJXr6LjNDOEsYJX5eXMwG0sAmYCHR/U8bpEFEQFViw5mVjCBhYQEPiX8L NUFMEQFPiZkbxCAqjCQWds1jA7FZgKo/n5/DBGLzCvhKLNq6ihnEFhJwlHj+9jZYnFPASeLV nxZGEJsR6Jzvp9aAxZkFxCVuPZnPBHGmgMSSPeeZIWxRiZeP/7FCfKIosbxfDqJcR2LB7k9s ELa2xLKFr5kh1gpKnJz5hGUCo+gsJFNnIWmZhaRlFpKWBYwsqxjZcxMzc9LLDTcxAsP94Jbf ujsYT50TOcQozcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGuDftSqERV03t Zy3P2fyb+wb7kbKPH8LUi1lypufuqU9Qa4jrmH5jk2f5rpTtDKryYRMS3r7467ZC/1gXb43e afbL/bXOXFwnQ1v3Gf9KClzAvz9Gi7c56vX9PVZblS+qPmdd1bvZqqihtDrl7mmfS+r/vnfd XWuivqrpj1ftlanmHxQX3DmgxFKckWioxVxUnAgA6OEB5UUCAAA= Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-13.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 10:10:03 -0000 Hi, I had some comments on v-11 of the draft, but I don't think they have been = addressed in the new version. ---------------------- Q1: Question on scope of the Contact URI, defined in section 3.1.5 E-mail: http://www.ietf.org/mail-archive/web/ecrit/current/msg08641.html My issue was about the semantics/usage of the Contact URI, and whether it e= .g. should be used for callbacks. Brian explained that that is not the purpose of the Contact URI, and indica= ted that some clarification text will be added. However, I see no such text= . ---------------------- Q2: Question on possible conflict between language feature tag and data pro= vider language, defined in section 3.1.6 E-mail: http://www.ietf.org/mail-archive/web/ecrit/current/msg08642.html My issue was why we couldn't use media feature tags, indicating the support= ed languages. ---------------------- Q3: Question on multiple entities adding data E-mail: http://www.ietf.org/mail-archive/web/ecrit/current/msg08646.html My issue was whether multiple entities could add information, and whether m= ultiple MIMEs would be used in such case, etc. I also requested some example pictures, showing a call where multiple types= of entities add information. Related to this, James W asked whether a single entity should be allowed to= enter multiple types of information. ---------------------- Regards, Christer -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: 16. lokakuuta 2013 12:14 To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-13.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens James Winterbottom Filename : draft-ietf-ecrit-additional-data-13.txt Pages : 86 Date : 2013-10-16 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-13 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Wed Oct 16 04:43:36 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B4411E81CB for ; Wed, 16 Oct 2013 04:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hegOXdcA3r4 for ; Wed, 16 Oct 2013 04:43:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0B36211E81CE for ; Wed, 16 Oct 2013 04:43:28 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lw2Sj-1VpOZG2Z25-017iZJ for ; Wed, 16 Oct 2013 13:43:28 +0200 Message-ID: <525E7BFD.20703@gmx.net> Date: Wed, 16 Oct 2013 13:43:57 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Christer Holmberg , "ecrit@ietf.org" References: <20131016091416.32193.78065.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1C4BFFBE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4BFFBE@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:WMXkfUHTlYepaQJ1Wsr0oKS6pDyeuF2B9Bx2IEkVKVYN+oYUMn5 tmoPIKvKyCz0wxHUHev5thiloQNkPIQbh7nj1n+TRL1tol+GzFU3UhW/CvGvFwNOkMAEZPs qHXr071wgkxWbHke4luYYkHtblPAIJUGu8I8ET6jaVnJyTRbEoEQ0TqsfWEUBw5evEP1KNy qxnoyxpv2hTrvopENcdkQ== Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-13.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 11:43:36 -0000 Hi Christer, with today's draft updates we have tried to address the feedback from Barbara. We will try to address your remarks within the next few days. Sorry for the delay; we certainly haven't forgotten your review remarks. Ciao Hannes On 10/16/2013 12:09 PM, Christer Holmberg wrote: > Hi, > > I had some comments on v-11 of the draft, but I don't think they have been addressed in the new version. > > ---------------------- > > Q1: Question on scope of the Contact URI, defined in section 3.1.5 > E-mail: http://www.ietf.org/mail-archive/web/ecrit/current/msg08641.html > > My issue was about the semantics/usage of the Contact URI, and whether it e.g. should be used for callbacks. > > Brian explained that that is not the purpose of the Contact URI, and indicated that some clarification text will be added. However, I see no such text. > > ---------------------- > > Q2: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 > E-mail: http://www.ietf.org/mail-archive/web/ecrit/current/msg08642.html > > My issue was why we couldn't use media feature tags, indicating the supported languages. > > ---------------------- > > Q3: Question on multiple entities adding data > E-mail: http://www.ietf.org/mail-archive/web/ecrit/current/msg08646.html > > My issue was whether multiple entities could add information, and whether multiple MIMEs would be used in such case, etc. > > I also requested some example pictures, showing a call where multiple types of entities add information. > > Related to this, James W asked whether a single entity should be allowed to enter multiple types of information. > > ---------------------- > > Regards, > > Christer > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 16. lokakuuta 2013 12:14 > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-13.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. > > Title : Additional Data related to an Emergency Call > Author(s) : Brian Rosen > Hannes Tschofenig > Roger Marshall > Randall Gellens > James Winterbottom > Filename : draft-ietf-ecrit-additional-data-13.txt > Pages : 86 > Date : 2013-10-16 > > 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-13 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-13 > > > 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/ > > _______________________________________________ > 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 internet-drafts@ietf.org Wed Oct 16 04:43:51 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155AA21F9D94; Wed, 16 Oct 2013 04:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paxMP0cjH8hG; Wed, 16 Oct 2013 04:43:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A9D11E81C3; Wed, 16 Oct 2013 04:43:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131016114343.32211.83973.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2013 04:43:43 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-14.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 11:43:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens James Winterbottom Filename : draft-ietf-ecrit-additional-data-14.txt Pages : 86 Date : 2013-10-16 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Wed Oct 16 04:44:33 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C7411E81C3 for ; Wed, 16 Oct 2013 04:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTIur6H2nzmi for ; Wed, 16 Oct 2013 04:44:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 84B0821F9D94 for ; Wed, 16 Oct 2013 04:44:26 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MTjqS-1VNVaj1lqK-00QQLz for ; Wed, 16 Oct 2013 13:44:25 +0200 Message-ID: <525E7C38.7040505@gmx.net> Date: Wed, 16 Oct 2013 13:44:56 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "STARK, BARBARA H" , "ecrit@ietf.org" References: <2D09D61DDFA73D4C884805CC7865E61130317CA8@GAALPA1MSGUSR9L.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61130317CA8@GAALPA1MSGUSR9L.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/8GJd6nIPN2FSWx/Ew3D4L6GynnYFlI60Mq0vQqahsdJxnGGp2L tXBIJd6YzP2Q5BzxafnDa4hGEn4AywZjsB92XyDCooBfBkwd/GqT4EBSHJVSoU0uP3NYhgR KHxzAgdBt6XtOFHbPXY+tiMnMZYIag3g7tKDtISzoM08P+fwAzP1WlbWwGwz+72j8yvDcLl KCVvC6IFgXSRgKLxSzWtA== Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-10: service provider subscontractor X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 11:44:34 -0000 Hi Barbara, On 07/31/2013 07:08 PM, STARK, BARBARA H wrote: > I have several comments around items related to service provider > subcontractor. -------------------- 3.1.4. Type of Data Provider > Token: Service Provider Subcontractor Comment 9: This is a fuzzy > concept to me. I really don't understand what this is. Which to me > suggests it's ambiguous as to how or when to use it. Comment 10: Can > a Service Provider Subcontractor only be a "Service Provider (Calling > or Origination telecom SP), or can it also be one of the other > types?, If it can be one of the other types, which value is to be > used? Meaning of this Type element seems a bit overloaded to me. I will have to reach out to the NENA additional data group to answer that question authoratively. But it is certainly a good question to raise. > > Token: Expert Advice Provider Comment 11: Who does this provide > advice to? As Gunnar pointed out we had discussed this issue earlier on the list and I should have removed it already. I now removed the token. ----------------------- 3.1.8. Subcontractor Principal > > Data Element: Subcontractor Principal > > XML Element: > > Description: If the data provider is a subcontractor to another > provider such as an access infrastructure provider or telematics > provider, this element contains the DataProviderString of the service > provider to indicate which provider the subcontractor is working for. > This data is required if the Data Provider type is subcontractor . > > Comment 12: This element is not in xml in Section 6.1 Comment 13: > There's no Use provided for this element. Comment 14: As commented > above, I think the info that the type field is trying to convey is > overloaded, by trying to also convey subcontracting. But also, I'm > not really understanding this subcontractor concept. Is this anything > like a wholesale relationship (ISP provides access by wholesaling the > service of an access network provider)? Comment 15: Does the last > sentence of Description belong in a Use statement? I added the element to the XML schema and changed the wording of Section 3.1.8: ---- 3.1.8. Subcontractor Principal Data Element: Subcontractor Principal Use: Conditional. This data is required if the Data Provider type is subcontractor. XML Element: Description: If the data provider is a subcontractor to another provider, such as an access infrastructure provider or telematics provider, this element contains the DataProviderString of the service provider to indicate which provider the subcontractor is working for. Reason for Need: Identify the entity the subcontractor works for. How Used by Call Taker: Allows the call taker to understand what the relationship between data providers and the service providers in the path of the call are. ---- > -------------------------- 3.1.9. Subcontractor Priority > > Data Element: Subcontractor Priority > > Use: Required > > Comment 16: This element is not in xml in Section 6.1 Comment 17: Is > this really Required, or is it Conditional (on SubcontractorPrincipal > being provided, or some other condition)? I added the element to the XML schema and changed the wording of Section 3.1.9: ---- 3.1.9. Subcontractor Priority Data Element: Subcontractor Priority Use: Conditional. This data is required if the Data Provider type is "subcontractor". XML Element: Description: If the subcontractor has to be contacted first then this element MUST have the value "sub". If the access or service provider has to be contacted first then this element MUST have the value "main". Reason for Need: Inform the call taker whom to contact first, if support is needed. How Used by Call Taker: To decide which entity to contact first if assistance is needed. ---- Ciao Hannes > _______________________________________________ Ecrit mailing list > Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@gmx.net Wed Oct 16 07:14:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5440E11E813B for ; Wed, 16 Oct 2013 07:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqWM2cYQVymc for ; Wed, 16 Oct 2013 07:14:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 92BC611E81D3 for ; Wed, 16 Oct 2013 07:14:29 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MVui8-1VH7v9289w-00X5tt for ; Wed, 16 Oct 2013 16:14:28 +0200 Message-ID: <525E9F62.7010004@gmx.net> Date: Wed, 16 Oct 2013 16:14:58 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "ecrit@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:eD+SdrYfC1U03s6lwE38x8lTL8rLsPd+U9nBgeoYROnJHjUrLtR 1788TpYIB4+llwSlKuirD78hpC4zpJRAlQqgQumV0//sUj7kFzmGVHaWdd7I/1Gu+VGWNuV Xuw3aawqlvv5GInQfbbRz5hzXqNugcMUIErtwuTiogkKYeXvIKz6Oyp8oQtI8Eq89iDtrYW 1hS86Y0vyNIWdSa4pQaSQ== Subject: [Ecrit] draft-ietf-ecrit-additional-data-14 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 14:14:38 -0000 Hi all, as you have seen we have been working on the additional data document. I would like to particularly thank James for his editing work on the document. The updates we shipped today tried to specifically address comments sent to the list by Barbara Stark around the Berlin IETF meeting. When we met Barbara in Berlin we had the chance to talk a bit about her extensive review. This helped to better address her feedback. I hope we managed to capture the main points with these document updates. The best way to see the changes is to compare version -11 with version -14. Here is the link: http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-ecrit-additional-data-11.txt&url2=http://tools.ietf.org/id/draft-ietf-ecrit-additional-data-14.txt Here are the points to the review comments provided by Barbara: http://www.ietf.org/mail-archive/web/ecrit/current/msg08628.html http://www.ietf.org/mail-archive/web/ecrit/current/msg08629.html http://www.ietf.org/mail-archive/web/ecrit/current/msg08630.html http://www.ietf.org/mail-archive/web/ecrit/current/msg08631.html http://www.ietf.org/mail-archive/web/ecrit/current/msg08632.html Many of the changes are editorial clarifications that aim to improve the quality of the document. There are, however, a few changes that are non-editorial, such as: * Removed the 'Expert Advice Provider' from the Data Provider ID Registry. * Added the 'Emergency Service Provider' to the Data Provider ID Registry (related to discussion with Gunnar, see http://www.ietf.org/mail-archive/web/ecrit/current/msg08633.html) * Reworded the description of the Data Provider Contact URI (which lead to normative changes) * Reworded the text for the Data Provider ID (includes normative changes) * Turned the 'Language' element into a mandatory element. * Added 'Subcontractor Principal' and 'Subcontractor Priority' to the XML schema. * Added 'SoftPhn' (soft phone or soft client software) to the Device Classification Registry * Added a new XML attribute called 'Subscriber Data Privacy Indicator' (which is similiar to the 'Telephone Number Privacy Indicator' found in earlier versions of the document). Thanks for the detailed review, Barbara! Ciao Hannes & James From hannes.tschofenig@gmx.net Wed Oct 16 09:58:07 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B7911E8138 for ; Wed, 16 Oct 2013 09:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+Kq77qhEJat for ; Wed, 16 Oct 2013 09:58:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id D62BB21F99ED for ; Wed, 16 Oct 2013 09:58:01 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M86Cn-1Vjm0U3Y5h-00vee3 for ; Wed, 16 Oct 2013 18:58:00 +0200 Message-ID: <525EC5B6.40500@gmx.net> Date: Wed, 16 Oct 2013 18:58:30 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Barbara Stark References: <93198856-9F95-4FE1-A3A0-D628C9717FBE@neustar.biz> In-Reply-To: <93198856-9F95-4FE1-A3A0-D628C9717FBE@neustar.biz> X-Forwarded-Message-Id: <93198856-9F95-4FE1-A3A0-D628C9717FBE@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DLjljU3dMfmbI7k+0yS5bR+L9iyQFq0bFb24ymq7wLrB7XREho0 GsnvZ+TKrHw0EghGf9nlqtlLA7fmjMK+xRW4woFYPmKqcftJANUTq4Lv/Iw54p8D/KRVvuL MBaw7PbBpJBpx1aBUuc1tW8tywGR+NKj4Jx90ZfUOWRzup1Z49o49wP7C0CzxylXVcZEy+5 6wtsTL9XSEfW/dKbHulcg== Cc: "ecrit@ietf.org" Subject: [Ecrit] Fwd: Re: [csds-addldata] draft-ietf-ecrit-additional-data & Subcontractor Concept X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 16:58:07 -0000 Barbara, does this description for the Subcontractor concept make you happy? I could add some additional text to the section based on Brian's description. Here is proposed text: ----- 3.1.8. Subcontractor Principal Data Element: Subcontractor Principal Use: Conditional. This data is required if the Data Provider type is subcontractor. XML Element: Description: Some providers outsource their obligations to handle aspects of emergency services to specialized providers. If the data provider is a subcontractor to another provider this element contains the DataProviderString of the service provider to indicate which provider the subcontractor is working for. Reason for Need: Identify the entity the subcontractor works for. How Used by Call Taker: Allows the call taker to understand what the relationship between data providers and the service providers in the path of the call are. 3.1.9. Subcontractor Priority Data Element: Subcontractor Priority Use: Conditional. This element is required if the Data Provider type is set to "Subcontractor". XML Element: Description: If the subcontractor has to be contacted first then this element MUST have the value "sub". If the provider the subcontractor is working for has to be contacted first then this element MUST have the value "main". Reason for Need: Inform the call taker whom to contact first, if support is needed. How Used by Call Taker: To decide which entity to contact first if assistance is needed. ----- Here are two examples: Example #1: SubcontractorPriority = sub Example Subcontrator urn:nena:companyid:ID12345 NENA Subcontractor sip:subcontractor@example.com EN .... Example VoIP Provider sub Example #1: SubcontractorPriority = main Example Subcontrator 2 urn:nena:companyid:ID123456 NENA Subcontractor sip:subcontractor@example.com EN .... Example VoIP Provider main With the second example there is the intresting situation that the call taker will not have enough information to actually contact the VoIP provider since it does not have any contact information. The contact information that is provided in additional data in those two examples is pointing to the subcontractor. Ciao hannes -------- Original Message -------- Subject: Re: [csds-addldata] draft-ietf-ecrit-additional-data & Subcontractor Concept Date: Wed, 16 Oct 2013 14:21:03 +0000 From: Rosen, Brian To: Hannes Tschofenig CC: csds-addldata@dev.nena.org This reflects the reality that some service providers will outsource their obligations to handle aspects of emergency services to specialized providers exactly as they do now. As with current arrangements, some aspects of this outsourcing vary between providers, and specifically, some wish the outsourcing provider to be the first point of contact, while others prefer to handle contact themselves. The "principal" is the actual service provider (access or originating) The "Principal" arrises to label whom the contractor is working for. The priority indicates whether the contractor or the principal is to be contacted. Brian On Oct 16, 2013, at 9:56 AM, Hannes Tschofenig wrote: > Hi all, > > the additional data specification (see http://tools.ietf.org/html/draft-ietf-ecrit-additional-data) contains the 'Subcontractor Principal' and the 'Subcontractor Priority' elements as part of the Data Provider Information data block. > > The description of the subcontractor does not provide a lot of details why this outsourcing concept would be important to capture. > > What was the initial motivation for introducing this data element? > > Ciao > Hannes From internet-drafts@ietf.org Sat Oct 19 08:35:39 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F84311E81F4; Sat, 19 Oct 2013 08:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNBu0pmk-BDA; Sat, 19 Oct 2013 08:35:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB7D11E81ED; Sat, 19 Oct 2013 08:35:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131019153538.9578.72611.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 08:35:38 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-unauthenticated-access-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 15:35:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Extensions to the Emergency Services Architecture for de= aling with Unauthenticated and Unauthorized Devices Author(s) : Henning Schulzrinne Stephen McCann Gabor Bajko Hannes Tschofenig Dirk Kroeselberg Filename : draft-ietf-ecrit-unauthenticated-access-08.txt Pages : 23 Date : 2013-10-19 Abstract: The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. With features provided by the Public Switched Telephone Network (PSTN) there is precedence for some of these use cases and the transition to IP-based emergency calling creates the desire to replicate functionality the PSTN already offers today. For example, in many countries persons seeking help are empowered to initiate emergency calls without having a Subscriber Identity Module (SIM) in their mobile phone. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-unauthenticated-access-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-unauthenticated-access-= 08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Sat Oct 19 08:41:12 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F6711E81EC for ; Sat, 19 Oct 2013 08:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bcooqw0AC9Ek for ; Sat, 19 Oct 2013 08:41:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id E2FA311E81EB for ; Sat, 19 Oct 2013 08:41:04 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MT74k-1V7kbZ3xhe-00S5D1 for ; Sat, 19 Oct 2013 17:41:04 +0200 Message-ID: <5262A82D.5060508@gmx.net> Date: Sat, 19 Oct 2013 17:41:33 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "ecrit@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:aXao9JZQip/tcU5uHcqEMACZQZz2+xU88axQ52g2RhGVnjMmqLV p9eIvNEPlYtTul2RstcIFBCeu7DSxAMFdkk1xXgAezEhbpEHUH1GSTyQeuej+diVheY7PeI 5WoDMWzsbcwJIQy2rO4pdn6GdPGggRSLidZH5YHmupoPaBHz+uq3fiNkYkZBSPP+6tKJDFC nElfHLY4GX7lNu0WmbGLQ== Subject: [Ecrit] draft-ietf-ecrit-unauthenticated-access-08 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 15:41:13 -0000 Hi all, I have just submitted version -08 of draft-ietf-ecrit-unauthenticated-access. I have incorporated review comments from Alexey (Gen-Art reviewer) and Richard's review comments. Their comments can be found here: http://www.ietf.org/mail-archive/web/ecrit/current/msg08676.html http://www.ietf.org/mail-archive/web/ecrit/current/msg08661.html Here is the updated version: http://tools.ietf.org/html/draft-ietf-ecrit-unauthenticated-access-08 Ciao Hannes From RMarshall@telecomsys.com Mon Oct 21 10:11:03 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409CF11E8209 for ; Mon, 21 Oct 2013 10:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-i5ADRiMAFs for ; Mon, 21 Oct 2013 10:10:59 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id A629D11E8204 for ; Mon, 21 Oct 2013 10:10:49 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id r9LHAfGg002501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 21 Oct 2013 10:10:42 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.31]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0218.012; Mon, 21 Oct 2013 10:10:41 -0700 From: Roger Marshall To: Randall Gellens , "ecrit_ietf.org" Thread-Topic: [Ecrit] Charter & Milestones update - Comments sought Thread-Index: Ac7BLfNZgOHANmOzQNGU4fpZSblfKQCquwiAAqm4DQA= Date: Mon, 21 Oct 2013 17:10:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC484ED7SEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:11:03 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC484ED7SEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Randy: I'm not sure what you're proposing as a change to the text. I agree that the present text has some history in pre-LoST, but I don't thi= nk its inclusion limits what you are suggesting, (ACN or pan-EU emergency c= alling). -roger. From: Randall Gellens [mailto:randy@qti.qualcomm.com] Sent: Monday, October 07, 2013 1:46 PM To: Roger Marshall; ecrit_ietf.org Subject: Re: [Ecrit] Charter & Milestones update - Comments sought I realize some of this language is a holdover from our very early days when= we weren't sure which way we could go for things which became LoST, for ex= ample. Still, I'm not sure exactly what "any solution presented must be us= eful regardless of jurisdiction, and it must be possible to use without req= uiring a single, central authority" mean today. In one sense, everything w= e do has dependency on jurisdiction, because not all jurisdictions will mig= rate to next-generation at the same time. A SIP-based emergency call won't= work in a legacy emergency call jurisdiction. We want to be sure that we can work on generic ACN and pan-Europen eCall. At 6:18 PM +0000 10/4/13, Roger Marshall wrote: Content-Language: en-US Content-Type: multipart/alternative; boundary=3D"_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecom= sy_" The ECRIT working group agreed that the chairs would propose updated langua= ge to the wg charter, along with milestone data changes. Compare this to the original charter found at: http://tools.ietf.org/wg/ecr= it/charters. Please send your comments to the list, whether in favor, or with alternativ= e wording and/or dates. Regards, Roger Marshall/Marc Linsner ECRIT Chairs ECRIT charter (w/proposed revisions): Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems Mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group will describe where and how these mechanis= ms may be used. The group will show how the availability of location data and call routing information at different steps in the call session setup would enable communication between a user and a relevant emergenc= y response center. Though the term "call routing" is used in this documen= t, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. Beyond human initiated emergency call request mechanisms, this group wi= ll develop new methods to request emergency assistance, such as sensor initiated emergency requests, and additional processes specified that address topics such as authentication of location, service URN definiti= on and use, augmented information that could assist emergency call takers = or responders. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requ= iring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be handled independently. This working group cares about privacy and security concerns, and will address them within its documents. Milestones w/revised status/dates, as proposed Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG f= or consideration as an Experimental RFC Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for cons= ideration as a Standards Track RFC Dec 2013 - Submit a draft 'Policy for defining new service-identifying labels' to the IESG for consideration as BCP Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Personal experiences affect the facts that judges choose to see. --Judge Sotomayor --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC484ED7SEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Charter & Milestones update - Comments sought</title= > <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Consolas","serif";} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Randy:<o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I’m not sure what y= ou’re proposing as a change to the text.  <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I agree that the present = text has some history in pre-LoST, but I don’t think its inclusion li= mits what you are suggesting, (ACN or pan-EU emergency calling).<o:p></o:p>= </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">-roger.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Randall = Gellens [mailto:randy@qti.qualcomm.com] <br> <b>Sent:</b> Monday, October 07, 2013 1:46 PM<br> <b>To:</b> Roger Marshall; ecrit_ietf.org<br> <b>Subject:</b> Re: [Ecrit] Charter & Milestones update - Comments soug= ht<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal">I realize some of this language is a holdover from o= ur very early days when we weren't sure which way we could go for things wh= ich became LoST, for example.  Still, I'm not sure exactly what "= any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single= , central authority" mean today.  In one sense, everything we do = has dependency on jurisdiction, because not all jurisdictions will migrate = to next-generation at the same time.  A SIP-based emergency call won't work in a legacy emergency call jurisdiction.<o:p></o= :p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">We want to be sure that we can work on generic ACN a= nd pan-Europen eCall. <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">At 6:18 PM +0000 10/4/13, Roger Marshall wrote:<= o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Content-Language: en-US<br> Content-Type: multipart/alternative;<br>      boundary=3D"_000_FBD5AAFFD0978846BF6D3FAB4C89= 2ACC45811BSEAEXMB1telecomsy_"<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">The ECRIT working group agreed that the chairs would= propose updated language to the wg charter, along with milestone data chan= ges.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Compare this to the original charter found at: <a hr= ef=3D"http://tools.ietf.org/wg/ecrit/charters"> http://tools.ietf.org/wg/ecrit/charters</a>.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Please send your comments to the list, whether in fa= vor, or with alternative wording and/or dates.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Regards,<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Roger Marshall/Marc Linsner<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">ECRIT Chairs<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">ECRIT charter (w/proposed revisions):<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Description of Working Group:<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    In a number of areas, the public = switched telephone network (PSTN) has<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    been configured to recognize an e= xplicitly specified number (usually<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    one that is short and easily memo= rized) as a request for emergency<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    services.  These numbers (e.= g., 911, 112) are related to an emergency<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    service context and depend on a b= road, regional configuration of<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    service contact methods and a geo= graphically-constrained approach for<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    service delivery.  These cal= ls are intended to be delivered to special<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    call centers equipped to manage e= mergency response. Successful<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    delivery of an emergency service = call within those systems requires<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    an association of both the physic= al location of the originating device<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    along with appropriate call = routing to an emergency service center.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    Calls placed using Internet techn= ologies do not use the same systems<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    Mentioned above to achieve those = same goals, and the common use of<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    overlay networks and tunnels= (either as VPNs or for mobility) makes<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    meeting these goals even mor= e challenging.  There are, however,<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    Internet technologies availa= ble to manage location and to perform call<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    routing.  This working = group will describe where and how these mechanisms<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    may be used. The group will = show how the availability of location data<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    and call routing information= at different steps in the call session<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    setup would enable communica= tion between a user and a relevant emergency<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    response center. Though the = term "call routing" is used in this document,<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    it should be understood that= some of the mechanisms which will be<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    described might be used to enable= other types of media streams. Video<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    and text messaging, for example, = might be used to request emergency<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    services.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    Beyond human initiated emergency = call request mechanisms, this group will<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    develop new methods to reque= st emergency assistance, such as sensor<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    initiated emergency requests= , and additional processes specified that<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    address topics such as authe= ntication of location, service URN definition<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    and use, augmented informati= on that could assist emergency call takers or<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    responders.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    Explicitly outside the scope= of this group is the question of<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    pre-emption or prioritization of = emergency services traffic. This<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    group is considering emergency se= rvices calls which might be made by<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    any user of the Internet, as oppo= sed to government or military<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    services that may impose very dif= ferent authentication and routing<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    requirements.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    While this group anticipates a cl= ose working relationship with groups<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    such as NENA and ETSI EMTEL, any = solution presented must be useful<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    regardless of jurisdiction, and i= t must be possible to use without requiring a<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    single, central authority.  = Further, it must be possible for multiple<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    delegations within a jurisdiction= to be handled independently, as call<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    routing for specific emergency ty= pes may be handled independently.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    This working group cares about pr= ivacy and security concerns, and will<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    address them within its documents= .<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Milestones w/revised status/dates, as proposed<o:p><= /o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Done - Submit 'Public Safety Answering Point (PSAP) = Callbacks' to the IESG<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">for consideration as an Informational RFC<o:p></o:p>= </p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Nov 2013 - Submit 'Trustworthy Location Information'= to the IESG for<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">consideration as an Informational RFC<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Dec 2013 - Submit 'Additional Data related to a Call= for Emergency Call<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Purposes' to the IESG for consideration as a Standar= ds Track RFC<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Nov 2013 - Submit 'Common Alerting Protocol (CAP) ba= sed Data-Only<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Emergency Alerts using the Session Initiation Protoc= ol (SIP)' to the IESG for consideration as an<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Experimental RFC<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Dec 2013 - Submit 'Extensions to the Emergency Servi= ces Architecture for<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">dealing with Unauthenticated and Unauthorized Device= s' to the IESG for consideration<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">as a Standards Track RFC<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Dec 2013 - Submit a draft 'Policy for defining new s= ervice-identifying<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">labels' to the IESG for consideration as BCP<o:p></o= :p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Mar 2014 - Submit 'Using Imprecise Location for Emer= gency Call Routing'<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">to the IESG for consideration as an Informational RF= C<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Dec 2013 - Submit a draft 'URN For Country Specific = Emergency Services'<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">to the IESG for consideration as a Standards Track R= FC<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">CONFIDENTIALITY NOTICE: The information contained in= this message may be privileged and/or confidential. If you are not the int= ended recipient, or responsible for delivering this message to the intended= recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attach= ment(s) is strictly prohibited. If you have received this message in error,= please notify the sender immediately, and delete it and all attachments fr= om your computer and network.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><br> _______________________________________________<br> Ecrit mailing list<br> <a href=3D"mailto:Ecrit@ietf.org">Ecrit@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/ecrit">https://www.ietf.or= g/mailman/listinfo/ecrit</a><o:p></o:p></p> </blockquote> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <pre>-- <o:p></o:p></pre> <div> <p class=3D"MsoNormal"><span style=3D"color:black">Randall Gellens<br> Opinions are personal;    facts are suspect;  &nbs= p; I speak for myself only<br> -------------- Randomly selected tag: ---------------<br> Personal experiences affect the facts that judges choose to see.<br>        --Judge Sotomayor</span><o:p></o:= p></p> </div> </div> </body> </html> --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC484ED7SEAEXMB1telecomsy_-- From randy@qti.qualcomm.com Mon Oct 21 10:25:06 2013 Return-Path: <randy@qti.qualcomm.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D3B11E81ED for <ecrit@ietfa.amsl.com>; Mon, 21 Oct 2013 10:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.87 X-Spam-Level: X-Spam-Status: No, score=-103.87 tagged_above=-999 required=5 tests=[AWL=1.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwohv4umhXgp for <ecrit@ietfa.amsl.com>; Mon, 21 Oct 2013 10:25:00 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id B0EAB11E8204 for <ecrit@ietf.org>; Mon, 21 Oct 2013 10:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1382376296; x=1413912296; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=A4w1QZjO5rS/OM5pegg6/H0oC4MOSz5posX+SteOiXk=; b=XNH6CK1SK3FHC8wN1OAWWfnZZr/98yKfdsSkxkOZdD37x4pzk2yjR1Od yai12bP2IxELUMGyCI23yWttwuobZYE6NdlF2qoAJ2ImNSit7Ec/Va4T7 vsquDPfqTPxRFMgkod6KFOX3QWypyGicNFKigHP+oA+Z6FCNSP+/9pSW0 o=; X-IronPort-AV: E=McAfee;i="5400,1158,7235"; a="82009692" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine01.qualcomm.com with ESMTP; 21 Oct 2013 10:24:56 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7235"; a="21622143" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Oct 2013 10:24:55 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Oct 2013 10:24:55 -0700 Message-ID: <p06240601ce8b1354f008@[99.111.97.136]> In-Reply-To: <FBD5AAFFD0978846BF6D3FAB4C892ACC484ED7@SEA-EXMB-1.telecomsys.com> References: <FBD5AAFFD0978846BF6D3FAB4C892ACC45811B@SEA-EXMB-1.telecomsys.com> <p06240602ce78cc3a5e0a@[10.184.126.229]> <FBD5AAFFD0978846BF6D3FAB4C892ACC484ED7@SEA-EXMB-1.telecomsys.com> X-Mailer: Eudora for Mac OS X Date: Mon, 21 Oct 2013 10:24:50 -0700 To: Roger Marshall <RMarshall@telecomsys.com>, ecrit_ietf.org <ecrit@ietf.org> From: Randall Gellens <randy@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Oct 2013 17:25:06 -0000 <!doctype html public "-//W3C//DTD W3 HTML//EN"> <html><head><style type="text/css"><!-- blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } --></style><title>RE: [Ecrit] Charter & Milestones update - Comments sought
Hi Roger,

I suggest deleting:

        "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority"

The text seems to me to be more applicable to the solution that became LoST.  As such, I don't think it serves any purpose now.

       


At 5:10 PM +0000 10/21/13, Roger Marshall wrote:

Randy:
I'm not sure what you're proposing as a change to the text.
 
I agree that the present text has some history in pre-LoST, but I don't think its inclusion limits what you are suggesting, (ACN or pan-EU emergency calling).
 
-roger.
 
From: Randall Gellens [mailto:randy@qti.qualcomm.com]
Sent: Monday, October 07, 2013 1:46 PM
To: Roger Marshall; ecrit_ietf.org
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought
 
I realize some of this language is a holdover from our very early days when we weren't sure which way we could go for things which became LoST, for example.  Still, I'm not sure exactly what "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority" mean today.  In one sense, everything we do has dependency on jurisdiction, because not all jurisdictions will migrate to next-generation at the same time.  A SIP-based emergency call won't work in a legacy emergency call jurisdiction.
 
We want to be sure that we can work on generic ACN and pan-Europen eCall.
 
 
At 6:18 PM +0000 10/4/13, Roger Marshall wrote:
 
Content-Language: en-US
Content-Type: multipart/alternative;
     boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_"
The ECRIT working group agreed that the chairs would propose updated language to the wg charter, along with milestone data changes.
 
Compare this to the original charter found at: http://tools.ietf.org/wg/ecrit/charters.
 
Please send your comments to the list, whether in favor, or with alternative wording and/or dates.
 
Regards,
 
Roger Marshall/Marc Linsner
ECRIT Chairs
 
ECRIT charter (w/proposed revisions):
 
Description of Working Group:
 
    In a number of areas, the public switched telephone network (PSTN) has
    been configured to recognize an explicitly specified number (usually
    one that is short and easily memorized) as a request for emergency
    services.  These numbers (e.g., 911, 112) are related to an emergency
    service context and depend on a broad, regional configuration of
    service contact methods and a geographically-constrained approach for
    service delivery.  These calls are intended to be delivered to special
    call centers equipped to manage emergency response. Successful
    delivery of an emergency service call within those systems requires
    an association of both the physical location of the originating device
    along with appropriate call routing to an emergency service center.
 
    Calls placed using Internet technologies do not use the same systems
    Mentioned above to achieve those same goals, and the common use of
    overlay networks and tunnels (either as VPNs or for mobility) makes
    meeting these goals even more challenging.  There are, however,
    Internet technologies available to manage location and to perform call
    routing.  This working group will describe where and how these mechanisms
    may be used. The group will show how the availability of location data
    and call routing information at different steps in the call session
    setup would enable communication between a user and a relevant emergency
    response center. Though the term "call routing" is used in this document,
    it should be understood that some of the mechanisms which will be
    described might be used to enable other types of media streams. Video
    and text messaging, for example, might be used to request emergency

    services.
 
    Beyond human initiated emergency call request mechanisms, this group will
    develop new methods to request emergency assistance, such as sensor
    initiated emergency requests, and additional processes specified that
    address topics such as authentication of location, service URN definition
    and use, augmented information that could assist emergency call takers or
    responders.
 
    Explicitly outside the scope of this group is the question of
    pre-emption or prioritization of emergency services traffic. This
    group is considering emergency services calls which might be made by
    any user of the Internet, as opposed to government or military
    services that may impose very different authentication and routing
    requirements.
 
    While this group anticipates a close working relationship with groups
    such as NENA and ETSI EMTEL, any solution presented must be useful
    regardless of jurisdiction, and it must be possible to use without requiring a
    single, central authority.  Further, it must be possible for multiple
    delegations within a jurisdiction to be handled independently, as call
    routing for specific emergency types may be handled independently.
 
    This working group cares about privacy and security concerns, and will
    address them within its documents.
 
 
Milestones w/revised status/dates, as proposed
 
Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG
for consideration as an Informational RFC
 
Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for
consideration as an Informational RFC
 
Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call
Purposes' to the IESG for consideration as a Standards Track RFC
 
Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only
Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an
Experimental RFC
 
Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for
dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration
as a Standards Track RFC
 
Dec 2013 - Submit a draft 'Policy for defining new service-identifying
labels' to the IESG for consideration as BCP
 
Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'
to the IESG for consideration as an Informational RFC
 
Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'
to the IESG for consideration as a Standards Track RFC
 
CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
 
 
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Personal experiences affect the facts that judges choose to see.
       --Judge Sotomayor


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The budget should be balanced.  The treasury should be refilled.
Public debt should be reduced.  The arrogance of public officials
should be controlled.        --Marcus Tullius Cicero (106-43 B.C.)
From rlb@ipv.sx Mon Oct 21 10:30:23 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E081911E8219 for ; Mon, 21 Oct 2013 10:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgj0-8whodAb for ; Mon, 21 Oct 2013 10:30:19 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD2411E86B4 for ; Mon, 21 Oct 2013 10:29:56 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id va2so6276191obc.12 for ; Mon, 21 Oct 2013 10:29:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aV/SCuQ5AL0Iux3uo92zVw5NE3NwmFnF4F17Gjy3D5M=; b=QRnyJ2nwjnYv73UVn9cMh5WpHMjv5l0Q13VUPaZpCsltLGtvUEJESdht+bz8DbXgoJ rsSwvG/I4hVoeFxY9SSXNCWNibhfdBSahY1oISy3px3ypWSjfpb6CiizhDl69Tjcio3Y c7yQOUDeF2xEKM4qFqgRWTeLO2lVOvElZDiMCu38hsONalU5sUkbw/xM5a5+zEu0WPXx F4suCwyNYdybcW/yLcsoNEwBmJyEF1lWyyMs3Qiwuwu+NYIS/QlZeik5708F2BEVoXns siELRBAduLpWul0Rfwt99eOBX6vR2kc2N6OnfO3KSP+GIpJw5wIub4V4apyJvPot5Kc3 ImdQ== X-Gm-Message-State: ALoCoQk+S4OFsVR2U1+mZeC8uCnfgwofMHPjyM8PXr9NhJaLnzoZrUk44LCaxHfqUnlvEvtkE3Gv MIME-Version: 1.0 X-Received: by 10.182.134.229 with SMTP id pn5mr23544obb.88.1382376595596; Mon, 21 Oct 2013 10:29:55 -0700 (PDT) Received: by 10.76.101.10 with HTTP; Mon, 21 Oct 2013 10:29:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Oct 2013 20:29:55 +0300 Message-ID: From: Richard Barnes To: Randall Gellens Content-Type: multipart/alternative; boundary=001a11c2570eed367004e943a114 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:30:24 -0000 --001a11c2570eed367004e943a114 Content-Type: text/plain; charset=ISO-8859-1 Could you explain more why that sentence is problematic? After all, our job here is to design things for the whole Internet; work that is only useful to a given jurisdiction should be done there. That's not to say that the general work can't be based on locality-specific work, and done at the same time -- RFC 6881 is arguably a generalization of a part of the NENA system. But what's done in the IETF needs to remain general. --Richard On Mon, Oct 21, 2013 at 8:24 PM, Randall Gellens wrote: > ** > Hi Roger, > > I suggest deleting: > > ** **"any solution presented must be useful regardless of > jurisdiction, and it must be possible to use without requiring a single, > central authority" > > The text seems to me to be more applicable to the solution that became > LoST. As such, I don't think it serves any purpose now. > > ** ** > > > At 5:10 PM +0000 10/21/13, Roger Marshall wrote: > > Randy: > > I'm not sure what you're proposing as a change to the text. > > > > I agree that the present text has some history in pre-LoST, but I don't > think its inclusion limits what you are suggesting, (ACN or pan-EU > emergency calling). > > > > -roger. > > > > *From:* Randall Gellens [mailto:randy@qti.qualcomm.com] > *Sent:* Monday, October 07, 2013 1:46 PM > *To:* Roger Marshall; ecrit_ietf.org > *Subject:* Re: [Ecrit] Charter & Milestones update - Comments sought > > > > I realize some of this language is a holdover from our very early days > when we weren't sure which way we could go for things which became LoST, > for example. Still, I'm not sure exactly what "any solution presented must > be useful regardless of jurisdiction, and it must be possible to use > without requiring a single, central authority" mean today. In one sense, > everything we do has dependency on jurisdiction, because not all > jurisdictions will migrate to next-generation at the same time. A > SIP-based emergency call won't work in a legacy emergency call jurisdiction. > > > > We want to be sure that we can work on generic ACN and pan-Europen eCall. > > > > > > At 6:18 PM +0000 10/4/13, Roger Marshall wrote: > > > > Content-Language: en-US > Content-Type: multipart/alternative; > boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1tel > ecomsy_" > > The ECRIT working group agreed that the chairs would propose updated > language to the wg charter, along with milestone data changes. > > > > Compare this to the original charter found at: > http://tools.ietf.org/wg/ecrit/charters. > > > > Please send your comments to the list, whether in favor, or with > alternative wording and/or dates. > > > > Regards, > > > > Roger Marshall/Marc Linsner > > ECRIT Chairs > > > > ECRIT charter (w/proposed revisions): > > > > Description of Working Group: > > > > In a number of areas, the public switched telephone network (PSTN) has > > been configured to recognize an explicitly specified number (usually > > one that is short and easily memorized) as a request for emergency > > services. These numbers (e.g., 911, 112) are related to an emergency > > service context and depend on a broad, regional configuration of > > service contact methods and a geographically-constrained approach for > > service delivery. These calls are intended to be delivered to special > > call centers equipped to manage emergency response. Successful > > delivery of an emergency service call within those systems requires > > an association of both the physical location of the originating device > > along with appropriate call routing to an emergency service center. > > > > Calls placed using Internet technologies do not use the same systems > > Mentioned above to achieve those same goals, and the common use of > > overlay networks and tunnels (either as VPNs or for mobility) makes > > meeting these goals even more challenging. There are, however, > > Internet technologies available to manage location and to perform call > > routing. This working group will describe where and how these > mechanisms > > may be used. The group will show how the availability of location data > > and call routing information at different steps in the call session > > setup would enable communication between a user and a relevant > emergency > > response center. Though the term "call routing" is used in this > document, > > it should be understood that some of the mechanisms which will be > > described might be used to enable other types of media streams. Video > > and text messaging, for example, might be used to request emergency > > > services. > > > > Beyond human initiated emergency call request mechanisms, this group > will > > develop new methods to request emergency assistance, such as sensor > > initiated emergency requests, and additional processes specified that > > address topics such as authentication of location, service URN > definition > > and use, augmented information that could assist emergency call takers > or > > responders. > > > > Explicitly outside the scope of this group is the question of > > pre-emption or prioritization of emergency services traffic. This > > group is considering emergency services calls which might be made by > > any user of the Internet, as opposed to government or military > > services that may impose very different authentication and routing > > requirements. > > > > While this group anticipates a close working relationship with groups > > such as NENA and ETSI EMTEL, any solution presented must be useful > > regardless of jurisdiction, and it must be possible to use without > requiring a > > single, central authority. Further, it must be possible for multiple > > delegations within a jurisdiction to be handled independently, as call > > routing for specific emergency types may be handled independently. > > > > This working group cares about privacy and security concerns, and will > > address them within its documents. > > > > > > Milestones w/revised status/dates, as proposed > > > > Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG > > for consideration as an Informational RFC > > > > Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for > > consideration as an Informational RFC > > > > Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call > > Purposes' to the IESG for consideration as a Standards Track RFC > > > > Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only > > Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG > for consideration as an > > Experimental RFC > > > > Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for > > dealing with Unauthenticated and Unauthorized Devices' to the IESG for > consideration > > as a Standards Track RFC > > > > Dec 2013 - Submit a draft 'Policy for defining new service-identifying > > labels' to the IESG for consideration as BCP > > > > Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' > > to the IESG for consideration as an Informational RFC > > > > Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' > > to the IESG for consideration as a Standards Track RFC > > > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, or > responsible for delivering this message to the intended recipient, any > review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, and > delete it and all attachments from your computer and network. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > -- > > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Personal experiences affect the facts that judges choose to see. > --Judge Sotomayor > > > > ** > > -- > > ** > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > The budget should be balanced. The treasury should be refilled. > Public debt should be reduced. The arrogance of public officials > should be controlled. --Marcus Tullius Cicero (106-43 B.C.) > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > --001a11c2570eed367004e943a114 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Could you explain more why that sentence is problematic? = =A0After all, our job here is to design things for the whole Internet; work= that is only useful to a given jurisdiction should be done there. =A0
=
That's not to say that the general work can't be based o= n locality-specific work, and done at the same time -- RFC 6881 is arguably= a generalization of a part of the NENA system. =A0But what's done in t= he IETF needs to remain general.

--Richard

On Mon, Oct 21, 2013 at 8:24 PM, Randall Gellen= s <randy@qti.qualcomm.com> wrote:
Hi Roger,

I suggest deleting:

=A0=A0=A0=A0=A0=A0=A0 "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority"

The text seems to me to be more applicable to the solution that became LoST.=A0 As such, I don't think it serves any purpose now.

=A0=A0=A0=A0=A0=A0=A0


At 5:10 PM +0000 10/21/13, Roger Marshall wrote:

Randy:
I'm not sure what you're proposing as a change to the text.
=A0
I agree that the present text has some history in pre-LoST, but I don't think its inclusion limits what you are suggesting, (ACN or pan-EU emergency calling).
=A0
-roger.
=A0
From: Randall Gellens [mailto:randy@q= ti.qualcomm.com]
Sent: Monday, October 07, 2013 1:46 PM
To: Roger Marshall; ecrit_ietf.org
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought
=A0
I realize some of this language is a holdover from our very early days when we weren't sure which way we could go for things which became LoST, for example.=A0 Still, I'm not sure exactly what "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority" mean today.=A0 In one sense, everything we do has dependency on jurisdiction, because not all jurisdictions will migrate to next-generation at the same time.=A0 A SIP-based emergency call won't work in a legacy emergency call jurisdiction.
=A0
We want to be sure that we can work on generic ACN and pan-Europen eCall.
=A0
=A0
At 6:18 PM +0000 10/4/13, Roger Marshall wrote:
=A0
Content-Language: en-US
Content-Type: multipart/alternative;
=A0=A0=A0=A0 boundary=3D"_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_"
The ECRIT working group agreed that the chairs would propose updated language to the wg charter, along with milestone data changes.
=A0
Compare this to the original charter found at: http://tools.ietf.org/wg/ecrit/charters.
=A0
Please send your comments to the list, whether in favor, or with alternative wording and/or dates.
=A0
Regards,
=A0
Roger Marshall/Marc Linsner
ECRIT Chairs
=A0
ECRIT charter (w/proposed revisions):
=A0
Description of Working Group:
=A0
=A0=A0=A0 In a number of areas, the public switched telephone network (PSTN) has
=A0=A0=A0 been configured to recognize an explicitly specified number (usually
=A0=A0=A0 one that is short and easily memorized) as a request for emergency
=A0=A0=A0 services.=A0 These numbers (e.g., 911, 112) are related to an emergency
=A0=A0=A0 service context and depend on a broad, regional configuration of
=A0=A0=A0 service contact methods and a geographically-constrained approach for
=A0=A0=A0 service delivery.=A0 These calls are intended to be delivered to special
=A0=A0=A0 call centers equipped to manage emergency response. Successful
=A0=A0=A0 delivery of an emergency service call within those systems requires
=A0=A0=A0 an association of both the physical location of the originating device
=A0=A0=A0=A0along with appropriate call routing to an emergency service center.
=A0
=A0=A0=A0 Calls placed using Internet technologies do not use the same systems
=A0=A0=A0 Mentioned above to achieve those same goals, and the common use of
=A0=A0=A0=A0overlay networks and tunnels (either as VPNs or for mobility) makes
=A0=A0=A0=A0meeting these goals even more challenging.=A0 There are, however,
=A0=A0=A0=A0Internet technologies available to manage location and to perform call
=A0=A0=A0=A0routing.=A0 This working group will describe where and how these mechanisms
=A0=A0=A0=A0may be used. The group will show how the availability of location data
=A0=A0=A0=A0and call routing information at different steps in the call session
=A0=A0=A0=A0setup would enable communication between a user and a relevant emergency
=A0=A0=A0=A0response center. Though the term "call routing" is used in this document,
=A0=A0=A0=A0it should be understood that some of the mechanisms which will be
=A0=A0=A0 described might be used to enable other types of media streams. Video
=A0=A0=A0 and text messaging, for example, might be used to request emergency

=A0=A0=A0 services.
=A0
=A0=A0=A0 Beyond human initiated emergency call request mechanisms, this group will
=A0=A0=A0=A0develop new methods to request emergency assistance, such as sensor
=A0=A0=A0=A0initiated emergency requests, and additional processes specified that
=A0=A0=A0=A0address topics such as authentication of location, service URN definition
=A0=A0=A0=A0and use, augmented information that could assist emergency call takers or
=A0=A0=A0=A0responders.
=A0
=A0=A0=A0=A0Explicitly outside the scope of this group is the question of
=A0=A0=A0 pre-emption or prioritization of emergency services traffic. This
=A0=A0=A0 group is considering emergency services calls which might be made by
=A0=A0=A0 any user of the Internet, as opposed to government or military
=A0=A0=A0 services that may impose very different authentication and routing
=A0=A0=A0 requirements.
=A0
=A0=A0=A0 While this group anticipates a close working relationship with groups
=A0=A0=A0 such as NENA and ETSI EMTEL, any solution presented must be useful
=A0=A0=A0 regardless of jurisdiction, and it must be possible to use without requiring a
=A0=A0=A0 single, central authority.=A0 Further, it must be possible for multiple
=A0 =A0=A0delegations within a jurisdiction to be handled independently, as call
=A0=A0=A0 routing for specific emergency types may be handled independently.
=A0
=A0 =A0=A0This working group cares about privacy and security concerns, and will
=A0=A0=A0 address them within its documents.
=A0
=A0
Milestones w/revised status/dates, as proposed
=A0
Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG
for consideration as an Informational RFC
=A0
Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for
consideration as an Informational RFC
=A0
Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call
Purposes' to the IESG for consideration as a Standards Track RFC
=A0
Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only
Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an
Experimental RFC
=A0
Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for
dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration
as a Standards Track RFC
=A0
Dec 2013 - Submit a draft 'Policy for defining new service-identifying
labels' to the IESG for consideration as BCP
=A0
Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'
to the IESG for consideration as an Informational RFC
=A0
Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'
to the IESG for consideration as a Standards Track RFC
=A0
CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ecrit
=A0
=A0
--
Randall Gellens
Opinions are personal;=A0=A0=A0 facts are suspect;=A0=A0=A0 I speak for myself only
-------------- Randomly selected tag: ---------------
Personal experiences affect the facts that judges choose to see.
=A0=A0=A0=A0=A0=A0=A0--Judge Sotomayor


--=20
Randall Gel= lens
Opinions are personal;=A0=A0=A0 facts are suspect;=A0=A0=A0 I speak for myself only
-------------- Randomly selected tag: ---------------
The budget should be balanced. =A0The treasury should be refilled.
Public debt should be reduced. =A0The arrogance of public officials
should be controlled. =A0=A0=A0=A0=A0=A0=A0--Marcus Tullius Cicero (106-43 = B.C.)

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


--001a11c2570eed367004e943a114-- From RMarshall@telecomsys.com Mon Oct 21 10:40:54 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A357711E819C for ; Mon, 21 Oct 2013 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzGCQlKOGQPp for ; Mon, 21 Oct 2013 10:40:44 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB5F11E8108 for ; Mon, 21 Oct 2013 10:40:33 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id r9LHeT88026719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 21 Oct 2013 10:40:30 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.31]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Mon, 21 Oct 2013 10:40:29 -0700 From: Roger Marshall To: Gunnar Hellstrom , "Gellens, Randall" Thread-Topic: [Ecrit] Charter & Milestones update - Comments sought Thread-Index: Ac7BLfNZgOHANmOzQNGU4fpZSblfKQHOfvQAAAFQUYAAAHVsgP//94XNgAB+dAD/9EtxcA== Date: Mon, 21 Oct 2013 17:40:28 +0000 Message-ID: References: <525AC37C.8090708@gmx.net> <525ACC4D.1020500@omnitor.se>, <525ACF61.7080102@gmx.net> <527682A7144B254C856D43E2B3D9E9371EFB798F@nasanexd01b.na.qualcomm.com> <525B3258.2040402@omnitor.se> In-Reply-To: <525B3258.2040402@omnitor.se> 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_FBD5AAFFD0978846BF6D3FAB4C892ACC484FE6SEAEXMB1telecomsy_" MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:40:54 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC484FE6SEAEXMB1telecomsy_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think these suggested changes in the text are reasonable, since they reac= h beyond NENA's span (North America only). I'll plan to make this change to the Charter & add to the Milestones. -roger. From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of G= unnar Hellstrom Sent: Sunday, October 13, 2013 4:53 PM To: Gellens, Randall Cc: ecrit@ietf.org Subject: Re: [Ecrit] Charter & Milestones update - Comments sought An addition could be made to this sentence: "Further, it must be possible for multiple delegations within a jurisdictio= n to be handled independently, as call routing for specific emergency types= may be handled independently." To "Further, it must be possible for multiple delegations within a jurisdictio= n to be handled independently, as call routing for specific emergency types= , media types, language contents etc. may be routed differently depending = on established policies and availability." And in the goals list include: xxx 2014 - Submit a draft 'Policy based routing in Emergency Services' to the IESG for consideration as a Standards Track RFC Regards Gunnar ________________________________ Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-10-13 19:22, Gellens, Randall wrote: The current NENA document on policy-based routing only deals with legacy ca= pabilities (that is, call diversion/exception handling). The NENA group in= tends to produce a version two that covers NG9-1-1 (NENA i3) capabilities w= ith the enhancements for call processing including media and other needs. ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@= ietf.org] on behalf of Hannes Tschofenig [ha= nnes.tschofenig@gmx.net] Sent: Sunday, October 13, 2013 9:50 AM To: Gunnar Hellstrom Cc: ecrit@ietf.org Subject: Re: [Ecrit] Charter & Milestones update - Comments sought Hi Gunnar, that's fine with me but where do you want to add this remark in the charter text Roger proposed? Also, do we have any specific document in progress that is impacted by policy based routing? Ciao Hannes On 13.10.2013 19:37, Gunnar Hellstrom wrote: Hi, Policy based routing was once said to enable routing based on for example media requirements and capabilities to specific PSAPs equipped or educated for such calls. In latest NENA spec for policy based routing, only PSAP availability is mentioned as reason to route. I do not remember that we have anything sufficiently explicit from IETF on this topic, and suggest to include it in the goals. Thanks, Gunnar ------------------------------------------------------------------------ Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-10-13 11:59, Hannes Tschofenig wrote: Hi Roger, thanks for working on the updated charter text. The text is fine for me; I only have a few minor suggestions. On 04.10.2013 21:18, Roger Marshall wrote: The ECRIT working group agreed that the chairs would propose updated language to the wg charter, along with milestone data changes. Compare this to the original charter found at: http://tools.ietf.org/wg/ecrit/charters. Please send your comments to the list, whether in favor, or with alternative wording and/or dates. Regards, Roger Marshall/Marc Linsner ECRIT Chairs ECRIT charter (w/proposed revisions): Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems Mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group will describe where and how these mechanisms may be used. The group will show how the availability of location data and call routing information at different steps in the call session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. I would omit this last sentence. I also believe that the term "document" isn't appropriate here. Beyond human initiated emergency call request mechanisms, this group will develop new methods to request emergency assistance, such as sensor initiated emergency requests, and additional processes specified that address topics such as authentication of location, service URN definition and use, augmented information that could assist emergency call takers or responders. s/"authentication of location"/"trustworthy location" Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL with "ETSI" since we are now dealing also with other groups in ETSI in addition to EMTEL. regardless of jurisdiction, and it must be possible to use without requiring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be handled independently. This working group cares about privacy and security concerns, and will address them within its documents. Milestones w/revised status/dates, as proposed Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration I thought that this document has been sent to the IESG already. as a Standards Track RFC Dec 2013 - Submit a draft 'Policy for defining new service-identifying labels' to the IESG for consideration as BCP Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC I believe you should also list all other concluded documents as well (and mark them as done). Ciao Hannes CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC484FE6SEAEXMB1telecomsy_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I think these suggested c= hanges in the text are reasonable, since they reach beyond NENA’s spa= n (North America only).

 <= /p>

I’ll plan to make t= his change to the Charter & add to the Milestones.

 <= /p>

-roger.=

 <= /p>

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf= .org] On Behalf Of Gunnar Hellstrom
Sent: Sunday, October 13, 2013 4:53 PM
To: Gellens, Randall
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Charter & Milestones update - Comments soug= ht

 

An addition could be made to this sentence:

"Further, it must be possible for multiple delegations within a jurisd= iction to be handled independently, as call routing for specific emergency = types may be handled independently."

To

"Further, it must be possible for multiple delegations within a jurisd= iction to be handled independently, as call routing for specific emergency = types, media types, language contents etc.  may be routed differently = depending on established policies and availability."

And in the goals list include:


xxx 2014 - Submit a draft 'Policy based routing in Emergency Services'=

 
to the IESG for consideration as a Standards Track RFC



Regards



Gunnar







On 2013-10-13 19:22, Gellens, Randall wrote:


The current NENA document on policy-based routing only deals with lega=
cy capabilities (that is, call diversion/exception handling).  The NEN=
A group intends to produce a version two that covers NG9-1-1 (NENA i3) capa=
bilities with the enhancements for call processing including media and othe=
r needs.
 
________________________________________
From: ecrit-bounces@ietf.org=
 [ecrit-bounces@ietf.org]=
 on behalf of Hannes Tschofenig [hannes.tschofenig@gmx.net]
Sent: Sunday, October 13, 2013 9:50 AM
To: Gunnar Hellstrom
Cc: ecrit@ietf.org

Subject: Re: [Ecrit] Charter & Milestones update - Comments sought=



 


Hi Gunnar,


 


that's fine with me but where do you want to add this remark in the


charter text Roger proposed?


 


Also, do we have any specific document in progress that is impacted by=



policy based routing?


 


Ciao


Hannes


 


 


On 13.10.2013 19:37, Gunnar Hellstrom wrote:




Hi,


Policy based routing was once said to enable routing based on for=



example media requirements and capabilities to specific PSAPs equipped=



or educated for such calls.


In latest NENA spec for policy based routing, only PSAP availability i=
s


mentioned as reason to route.


 


I do not remember that we have anything sufficiently explicit from IET=
F


on this topic, and suggest to include it in the goals.

 


Thanks,


Gunnar


 


 


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


Gunnar Hellstr=F6m


Omnitor


gunnar.hellstrom@omnito=
r.se


+46708204288


On 2013-10-13 11:59, Hannes Tschofenig wrote:




Hi Roger,


 


thanks for working on the updated charter text.


 


The text is fine for me; I only have a few minor suggestions.


 


On 04.10.2013 21:18, Roger Marshall wrote:




The ECRIT working group agreed that the chairs would propose updated


language to the wg charter, along with milestone data changes.


 


Compare this to the original charter found at:


http://tools.ietf.=
org/wg/ecrit/charters.


 


Please send your comments to the list, whether in favor, or with<=
/o:p>


alternative wording and/or dates.


 


Regards,


 


Roger Marshall/Marc Linsner


 


ECRIT Chairs


 


ECRIT charter (w/proposed revisions):


 


Description of Working Group:


 


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



 


been configured to recognize an explicitly specified number (usually


 


one that is short and easily memorized) as a request for emergency


 


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


 


service context and depend on a broad, regional configuration of<=
/o:p>


 


service contact methods and a geographically-constrained approach for<=
o:p>


 


service delivery. These calls are intended to be delivered to special<=
o:p>


 


call centers equipped to manage emergency response. Successful


 


delivery of an emergency service call within those systems requires


 


an association of both the physical location of the originating device=



 


along with appropriate call routing to an emergency service center.


 


Calls placed using Internet technologies do not use the same systems


 


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


 


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


 


meeting these goals even more challenging. There are, however,


 


Internet technologies available to manage location and to perform call=



 


routing. This working group will describe where and how these mechanis=
ms


 


may be used. The group will show how the availability of location data=



 


and call routing information at different steps in the call session


 


setup would enable communication between a user and a relevant emergen=
cy


 


response center. Though the term "call routing" is used in t=
his


document,


 


it should be understood that some of the mechanisms which will be=



 


described might be used to enable other types of media streams. Video<=
o:p>


 


and text messaging, for example, might be used to request emergency


 


services.




 


I would omit this last sentence. I also believe that the term


"document" isn't appropriate here.


 


 




 


Beyond human initiated emergency call request mechanisms, this group


will


 


develop new methods to request emergency assistance, such as sensor


 


initiated emergency requests, and additional processes specified that<=
o:p>


 


address topics such as authentication of location, service URN


definition


 


and use, augmented information that could assist emergency call


takers or


 


responders.




 


s/"authentication of location"/"trustworthy location&qu=
ot;


 




 


Explicitly outside the scope of this group is the question of


 


pre-emption or prioritization of emergency services traffic. This=



 


group is considering emergency services calls which might be made by


 


any user of the Internet, as opposed to government or military


 


services that may impose very different authentication and routing


 


requirements.


 


While this group anticipates a close working relationship with groups<=
o:p>


 


such as NENA and ETSI EMTEL, any solution presented must be useful




 


You should add "EENA" and "3GPP" here as well and =
replace ETSI EMTEL


with "ETSI" since we are now dealing also with other groups =
in ETSI in


addition to EMTEL.


 


 




 


regardless of jurisdiction, and it must be possible to use without


requiring a


 


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


 


delegations within a jurisdiction to be handled independently, as call=



 


routing for specific emergency types may be handled independently.


 


This working group cares about privacy and security concerns, and will=



 


address them within its documents.


 


Milestones w/revised status/dates, as proposed


 


Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the<=
o:p>


IESG


 


for consideration as an Informational RFC


 


Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for


 


consideration as an Informational RFC


 


Dec 2013 - Submit 'Additional Data related to a Call for Emergency Cal=
l


 


Purposes' to the IESG for consideration as a Standards Track RFC<=
/o:p>


 


Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only=



 


Emergency Alerts using the Session Initiation Protocol (SIP)' to the


IESG for consideration as an


 


Experimental RFC


 


Dec 2013 - Submit 'Extensions to the Emergency Services Architecture f=
or


 


dealing with Unauthenticated and Unauthorized Devices' to the IESG for=



consideration




 


I thought that this document has been sent to the IESG already.


 




 


as a Standards Track RFC


 


Dec 2013 - Submit a draft 'Policy for defining new service-identifying=



 


labels' to the IESG for consideration as BCP


 


Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing=
'


 


to the IESG for consideration as an Informational RFC


 


Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services=
'


 


to the IESG for consideration as a Standards Track RFC



 


I believe you should also list all other concluded documents as well


(and mark them as done).


 


 


Ciao


Hannes


 


 




 


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,<=
o:p>


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,<=
o:p>


and delete it and all attachments from your computer and network.=



 


 


 


_______________________________________________


Ecrit mailing list


Ecrit@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ecrit




 


_______________________________________________


Ecrit mailing list


Ecrit@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ecrit




 


 


 


_______________________________________________


Ecrit mailing list


Ecrit@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ecrit




 


_______________________________________________


Ecrit mailing list


Ecrit@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ecrit

 

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC484FE6SEAEXMB1telecomsy_-- From RMarshall@telecomsys.com Mon Oct 21 10:43:27 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE16011E8108 for ; Mon, 21 Oct 2013 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94dSgbygG3HR for ; Mon, 21 Oct 2013 10:43:23 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6CE11E818F for ; Mon, 21 Oct 2013 10:43:13 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id r9LHgvoh009989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 21 Oct 2013 10:42:58 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.31]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Mon, 21 Oct 2013 10:42:57 -0700 From: Roger Marshall To: Hannes Tschofenig Thread-Topic: [Ecrit] Charter & Milestones update - Comments sought Thread-Index: Ac7BLfNZgOHANmOzQNGU4fpZSblfKQHOfvQAAYct0JA= Date: Mon, 21 Oct 2013 17:42:56 +0000 Message-ID: References: <525AC37C.8090708@gmx.net> In-Reply-To: <525AC37C.8090708@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:43:27 -0000 Hannes: Thanks for your review and suggestions. See inline. -roger. -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Sunday, October 13, 2013 9:00 AM To: Roger Marshall Cc: ecrit_ietf.org; hannes.tschofenig@gmx.net Subject: Re: [Ecrit] Charter & Milestones update - Comments sought Hi Roger, thanks for working on the updated charter text. The text is fine for me; I only have a few minor suggestions. On 04.10.2013 21:18, Roger Marshall wrote: > The ECRIT working group agreed that the chairs would propose updated=20 > language to the wg charter, along with milestone data changes. > > Compare this to the original charter found at: > http://tools.ietf.org/wg/ecrit/charters. > > Please send your comments to the list, whether in favor, or with=20 > alternative wording and/or dates. > > Regards, > > Roger Marshall/Marc Linsner > > ECRIT Chairs > > ECRIT charter (w/proposed revisions): > > Description of Working Group: > > In a number of areas, the public switched telephone network (PSTN) has > > been configured to recognize an explicitly specified number (usually > > one that is short and easily memorized) as a request for emergency > > services. These numbers (e.g., 911, 112) are related to an emergency > > service context and depend on a broad, regional configuration of > > service contact methods and a geographically-constrained approach for > > service delivery. These calls are intended to be delivered to special > > call centers equipped to manage emergency response. Successful > > delivery of an emergency service call within those systems requires > > an association of both the physical location of the originating device > > along with appropriate call routing to an emergency service center. > > Calls placed using Internet technologies do not use the same systems > > Mentioned above to achieve those same goals, and the common use of > > overlay networks and tunnels (either as VPNs or for mobility) makes > > meeting these goals even more challenging. There are, however, > > Internet technologies available to manage location and to perform call > > routing. This working group will describe where and how these=20 > mechanisms > > may be used. The group will show how the availability of location data > > and call routing information at different steps in the call session > > setup would enable communication between a user and a relevant=20 > emergency > > response center. Though the term "call routing" is used in this=20 > document, > > it should be understood that some of the mechanisms which will be > > described might be used to enable other types of media streams. Video > > and text messaging, for example, might be used to request emergency > > services. I would omit this last sentence. I also believe that the term "document"=20 isn't appropriate here. [rsm] suggested changes accepted. > > Beyond human initiated emergency call request mechanisms, this group=20 > will > > develop new methods to request emergency assistance, such as sensor > > initiated emergency requests, and additional processes specified that > > address topics such as authentication of location, service URN=20 > definition > > and use, augmented information that could assist emergency call takers=20 > or > > responders. s/"authentication of location"/"trustworthy location" [rsm] okay. > > Explicitly outside the scope of this group is the question of > > pre-emption or prioritization of emergency services traffic. This > > group is considering emergency services calls which might be made by > > any user of the Internet, as opposed to government or military > > services that may impose very different authentication and routing > > requirements. > > While this group anticipates a close working relationship with groups > > such as NENA and ETSI EMTEL, any solution presented must be useful You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL with "= ETSI" since we are now dealing also with other groups in ETSI in addition t= o EMTEL. [rsm] changes will be made. > > regardless of jurisdiction, and it must be possible to use without=20 > requiring a > > single, central authority. Further, it must be possible for multiple > > delegations within a jurisdiction to be handled independently, as call > > routing for specific emergency types may be handled independently. > > This working group cares about privacy and security concerns, and will > > address them within its documents. > > Milestones w/revised status/dates, as proposed > > Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the=20 > IESG > > for consideration as an Informational RFC > > Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for > > consideration as an Informational RFC > > Dec 2013 - Submit 'Additional Data related to a Call for Emergency=20 > Call > > Purposes' to the IESG for consideration as a Standards Track RFC > > Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only > > Emergency Alerts using the Session Initiation Protocol (SIP)' to the=20 > IESG for consideration as an > > Experimental RFC > > Dec 2013 - Submit 'Extensions to the Emergency Services Architecture=20 > for > > dealing with Unauthenticated and Unauthorized Devices' to the IESG for=20 > consideration I thought that this document has been sent to the IESG already. [rsm] true. Status will be changed to Done. > > as a Standards Track RFC > > Dec 2013 - Submit a draft 'Policy for defining new service-identifying > > labels' to the IESG for consideration as BCP > > Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' > > to the IESG for consideration as an Informational RFC > > Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' > > to the IESG for consideration as a Standards Track RFC I believe you should also list all other concluded documents as well (and m= ark them as done). [rsm] Yes, okay. Ciao Hannes > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, > or responsible for delivering this message to the intended recipient, > any review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, > and delete it and all attachments from your computer and network. > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From randy@qti.qualcomm.com Mon Oct 21 10:49:04 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BD611E8437 for ; Mon, 21 Oct 2013 10:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.294 X-Spam-Level: X-Spam-Status: No, score=-104.294 tagged_above=-999 required=5 tests=[AWL=0.847, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9eILcT6lTeO for ; Mon, 21 Oct 2013 10:48:58 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id F2FFC11E83AA for ; Mon, 21 Oct 2013 10:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1382377690; x=1413913690; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=x0z8PlRiYy/vpAg6cW+1A1MiVQWuFChdGSQnMrzSOAI=; b=e9VDCTa8J8arn3wNJVh1x3TO2J05PbOR86mNO5T2pm9qJhBcXcvhD7I9 VdJAqx0C6Yi/5phUscK2o2Wadm7w35FxA0HyHRQ6E1r6JZcCThZklgfAj 2vY9RIrwACJ/DzKMRAZ1lRo9zbN7RygTKBPPJ6dvB3TkYnm5CWOJ/vj97 Y=; X-IronPort-AV: E=McAfee;i="5400,1158,7235"; a="82318694" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine02.qualcomm.com with ESMTP; 21 Oct 2013 10:47:51 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7235"; a="21623997" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Oct 2013 10:47:50 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Oct 2013 10:47:50 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 21 Oct 2013 10:47:47 -0700 To: Richard Barnes From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:49:05 -0000 Re: [Ecrit] Charter & Milestones update - Comments sought
Hi Richard,

I don't what what the phrase "useful regardless of jurisdiction" is supposed to mean in this context, and I'm concerned that it might be interpreted to mean that work needed for, e.g., eCall that is intended for use within the E.U. is out of scope.  Likewise for work intended for NENA's needs.  I agree that we don't want to do work that *can't* be used broadly on the Internet, but that's different than prohibiting work *intended* (at least initially) for use within a particular continent.  I suppose we could say "potentially useful" instead of just "useful" to make it clear that the prohibition is only on what the work *could* be used for, and not what it is initially intended for use for.  I still think we could just delete the sentence, since I don't see the group in danger of doing work that can't be broadly used.

To me, the phrase "it must be possible to use without requiring a single, central authority" seems intended to limit the work that became LosT, to try and avoid creating an LDAP-type situation that required a global root.

At 8:29 PM +0300 10/21/13, Richard Barnes wrote:

Could you explain more why that sentence is problematic?  After all, our job here is to design things for the whole Internet; work that is only useful to a given jurisdiction should be done there.

That's not to say that the general work can't be based on locality-specific work, and done at the same time -- RFC 6881 is arguably a generalization of a part of the NENA system.  But what's done in the IETF needs to remain general.

--Richard


On Mon, Oct 21, 2013 at 8:24 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:
Hi Roger,

I suggest deleting:

        "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority"

The text seems to me to be more applicable to the solution that became LoST.  As such, I don't think it serves any purpose now.

     


At 5:10 PM +0000 10/21/13, Roger Marshall wrote:

Randy:
I'm not sure what you're proposing as a change to the text.
 
I agree that the present text has some history in pre-LoST, but I don't think its inclusion limits what you are suggesting, (ACN or pan-EU emergency calling).
 
-roger.
 
From: Randall Gellens [mailto:randy@qti.qualcomm.com]
Sent: Monday, October 07, 2013 1:46 PM
To: Roger Marshall; ecrit_ietf.org
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought
 
I realize some of this language is a holdover from our very early days when we weren't sure which way we could go for things which became LoST, for example.  Still, I'm not sure exactly what "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority" mean today.  In one sense, everything we do has dependency on jurisdiction, because not all jurisdictions will migrate to next-generation at the same time.  A SIP-based emergency call won't work in a legacy emergency call jurisdiction.
 
We want to be sure that we can work on generic ACN and pan-Europen eCall.
 
 
At 6:18 PM +0000 10/4/13, Roger Marshall wrote:
 
Content-Language: en-US
Content-Type: multipart/alternative;
     boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_"
The ECRIT working group agreed that the chairs would propose updated language to the wg charter, along with milestone data changes.
 
Compare this to the original charter found at: http://tools.ietf.org/wg/ecrit/charters.
 
Please send your comments to the list, whether in favor, or with alternative wording and/or dates.
 
Regards,
 
Roger Marshall/Marc Linsner
ECRIT Chairs
 
ECRIT charter (w/proposed revisions):

 
Description of Working Group:
 
    In a number of areas, the public switched telephone network (PSTN) has
    been configured to recognize an explicitly specified number (usually
    one that is short and easily memorized) as a request for emergency
    services.  These numbers (e.g., 911, 112) are related to an emergency
    service context and depend on a broad, regional configuration of
    service contact methods and a geographically-constrained approach for
    service delivery.  These calls are intended to be delivered to special
    call centers equipped to manage emergency response. Successful
    delivery of an emergency service call within those systems requires
    an association of both the physical location of the originating device
    along with appropriate call routing to an emergency service center.
 
    Calls placed using Internet technologies do not use the same systems
    Mentioned above to achieve those same goals, and the common use of
    overlay networks and tunnels (either as VPNs or for mobility) makes
    meeting these goals even more challenging.  There are, however,
    Internet technologies available to manage location and to perform call
    routing.  This working group will describe where and how these mechanisms
    may be used. The group will show how the availability of location data
    and call routing information at different steps in the call session
    setup would enable communication between a user and a relevant emergency
    response center. Though the term "call routing" is used in this document,
    it should be understood that some of the mechanisms which will be
    described might be used to enable other types of media streams. Video
    and text messaging, for example, might be used to request emergency

    services.
 
    Beyond human initiated emergency call request mechanisms, this group will
    develop new methods to request emergency assistance, such as sensor
    initiated emergency requests, and additional processes specified that
    address topics such as authentication of location, service URN definition
    and use, augmented information that could assist emergency call takers or
    responders.
 
    Explicitly outside the scope of this group is the question of
    pre-emption or prioritization of emergency services traffic. This
    group is considering emergency services calls which might be made by
    any user of the Internet, as opposed to government or military
    services that may impose very different authentication and routing
    requirements.
 
    While this group anticipates a close working relationship with groups
    such as NENA and ETSI EMTEL, any solution presented must be useful
    regardless of jurisdiction, and it must be possible to use without requiring a
    single, central authority.  Further, it must be possible for multiple
    delegations within a jurisdiction to be handled independently, as call
    routing for specific emergency types may be handled independently.
 
    This working group cares about privacy and security concerns, and will
    address them within its documents.
 
 
Milestones w/revised status/dates, as proposed
 
Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG
for consideration as an Informational RFC
 
Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for
consideration as an Informational RFC
 
Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call
Purposes' to the IESG for consideration as a Standards Track RFC
 
Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only
Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an
Experimental RFC
 
Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for
dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration
as a Standards Track RFC
 
Dec 2013 - Submit a draft 'Policy for defining new service-identifying
labels' to the IESG for consideration as BCP

 
Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'
to the IESG for consideration as an Informational RFC
 
Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'
to the IESG for consideration as a Standards Track RFC
 
CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
 
 
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Personal experiences affect the facts that judges choose to see.
       --Judge Sotomayor


--
 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The budget should be balanced.  The treasury should be refilled.
Public debt should be reduced.  The arrogance of public officials
should be controlled.        --Marcus Tullius Cicero (106-43 B.C.)

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


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I have learned
To spell hors d'oeuvres
Which still grates on
Some people's n'oeuvres.
       -- Warren Knox
From rlb@ipv.sx Mon Oct 21 11:07:21 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8765E11E842A for ; Mon, 21 Oct 2013 11:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IotY2DkOSSg6 for ; Mon, 21 Oct 2013 11:07:17 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0303A11E81CA for ; Mon, 21 Oct 2013 11:05:56 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id i4so5426181oah.32 for ; Mon, 21 Oct 2013 11:05:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8VYHCG/h6NaheNmQRngsFE+gxKK/jJyY4gyzvbcHkyU=; b=jSyGYg2rss+92DODeGbhmi6gic67dZc3gnQusmFel0v85Il73J3v8kzM9U9/4tZyYy lMB0nYrmhbjF0u6deZQV4GCCeNwDLiEru+gbRc04GjhhmjKND14NxtRBtaAx0FOyowWp 0c9y60MOaCP12AJmOypijylVSnmA97bMz3tS1GGDz2+fLV1dIoLmlW/U/RNBLbpPKQSM +mavAE+bM3mA7+Gxv2ifNnMHv9gucQoK7gqS9gqsnB7UekJ7nOWEKJZ1x7pvdRCwNt6T AscFPFpv6HSfm+viCq8s5d3p2KqliEuc2gdm4nk9oj4FfoGai/6qu48k34eGk7OtEtng Of3g== X-Gm-Message-State: ALoCoQnbd4DTzB1eWdOBJts3t97Q8KRApDtSV2FlewYXVFHPnM67X6XFJOPwSvINESZAn1nJL4ta MIME-Version: 1.0 X-Received: by 10.182.165.67 with SMTP id yw3mr214994obb.84.1382378755859; Mon, 21 Oct 2013 11:05:55 -0700 (PDT) Received: by 10.76.101.10 with HTTP; Mon, 21 Oct 2013 11:05:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Oct 2013 21:05:55 +0300 Message-ID: From: Richard Barnes To: Randall Gellens Content-Type: multipart/alternative; boundary=001a11c2e964b0376604e94422fb Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:07:21 -0000 --001a11c2e964b0376604e94422fb Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 21, 2013 at 8:47 PM, Randall Gellens wrote: > ** > Hi Richard, > > I don't what what the phrase "useful regardless of jurisdiction" is > supposed to mean in this context, and I'm concerned that it might be > interpreted to mean that work needed for, e.g., eCall that is intended for > use within the E.U. is out of scope. Likewise for work intended for NENA's > needs. I agree that we don't want to do work that *can't* be used broadly > on the Internet, but that's different than prohibiting work *intended* (at > least initially) for use within a particular continent. I suppose we could > say "potentially useful" instead of just "useful" to make it clear that the > prohibition is only on what the work *could* be used for, and not what it > is initially intended for use for. I still think we could just delete the > sentence, since I don't see the group in danger of doing work that can't be > broadly used. > Ok, I think we're more or less on the same page w.r.t. the intent of the "jurisdiction" text. How about this? OLD: "any solution presented must be useful regardless of jurisdiction" NEW: "any solution presented must not rely on assumptions specific to a given jurisdiction or region" > To me, the phrase "it must be possible to use without requiring a single, > central authority" seems intended to limit the work that became LosT, to > try and avoid creating an LDAP-type situation that required a global root. > However, it seems like that's still a desirable goal for other systems, right? Just to make something up, suppose an ACN system depended on a single, standardized clearing house for ACN notifications. That would be bad, right? But it could also be tempting in a particular jurisdiction to assume that such a clearing-house is set in the standard. So ISTM this text is valuable for reminding people that things like that need to be discoverable. --Richard > > At 8:29 PM +0300 10/21/13, Richard Barnes wrote: > > Could you explain more why that sentence is problematic? After all, our > job here is to design things for the whole Internet; work that is only > useful to a given jurisdiction should be done there. > > > That's not to say that the general work can't be based on > locality-specific work, and done at the same time -- RFC 6881 is arguably a > generalization of a part of the NENA system. But what's done in the IETF > needs to remain general. > > > --Richard > > > > On Mon, Oct 21, 2013 at 8:24 PM, Randall Gellens > wrote: > > Hi Roger, > > > I suggest deleting: > > > "any solution presented must be useful regardless of jurisdiction, > and it must be possible to use without requiring a single, central > authority" > > > The text seems to me to be more applicable to the solution that became > LoST. As such, I don't think it serves any purpose now. > > > > > > > At 5:10 PM +0000 10/21/13, Roger Marshall wrote: > > > Randy: > > I'm not sure what you're proposing as a change to the text. > > > > I agree that the present text has some history in pre-LoST, but I don't > think its inclusion limits what you are suggesting, (ACN or pan-EU > emergency calling). > > > > -roger. > > > > *From:* Randall Gellens [mailto:randy@qti.qualcomm.com] > *Sent:* Monday, October 07, 2013 1:46 PM > *To:* Roger Marshall; ecrit_ietf.org > *Subject:* Re: [Ecrit] Charter & Milestones update - Comments sought > > > > I realize some of this language is a holdover from our very early days > when we weren't sure which way we could go for things which became LoST, > for example. Still, I'm not sure exactly what "any solution presented must > be useful regardless of jurisdiction, and it must be possible to use > without requiring a single, central authority" mean today. In one sense, > everything we do has dependency on jurisdiction, because not all > jurisdictions will migrate to next-generation at the same time. A > SIP-based emergency call won't work in a legacy emergency call jurisdiction. > > > > We want to be sure that we can work on generic ACN and pan-Europen eCall. > > > > > > At 6:18 PM +0000 10/4/13, Roger Marshall wrote: > > > > Content-Language: en-US > Content-Type: multipart/alternative; > boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1tel > ecomsy_" > > The ECRIT working group agreed that the chairs would propose updated > language to the wg charter, along with milestone data changes. > > > > Compare this to the original charter found at: > http://tools.ietf.org/wg/ecrit/charters. > > > > Please send your comments to the list, whether in favor, or with > alternative wording and/or dates. > > > > Regards, > > > > Roger Marshall/Marc Linsner > > ECRIT Chairs > > > > ECRIT charter (w/proposed revisions): > > > > > Description of Working Group: > > > > In a number of areas, the public switched telephone network (PSTN) has > > been configured to recognize an explicitly specified number (usually > > one that is short and easily memorized) as a request for emergency > > services. These numbers (e.g., 911, 112) are related to an emergency > > service context and depend on a broad, regional configuration of > > service contact methods and a geographically-constrained approach for > > service delivery. These calls are intended to be delivered to special > > call centers equipped to manage emergency response. Successful > > delivery of an emergency service call within those systems requires > > an association of both the physical location of the originating device > > along with appropriate call routing to an emergency service center. > > > > Calls placed using Internet technologies do not use the same systems > > Mentioned above to achieve those same goals, and the common use of > > overlay networks and tunnels (either as VPNs or for mobility) makes > > meeting these goals even more challenging. There are, however, > > Internet technologies available to manage location and to perform call > > routing. This working group will describe where and how these > mechanisms > > may be used. The group will show how the availability of location data > > and call routing information at different steps in the call session > > setup would enable communication between a user and a relevant > emergency > > response center. Though the term "call routing" is used in this > document, > > it should be understood that some of the mechanisms which will be > > described might be used to enable other types of media streams. Video > > and text messaging, for example, might be used to request emergency > > > services. > > > > Beyond human initiated emergency call request mechanisms, this group > will > > develop new methods to request emergency assistance, such as sensor > > initiated emergency requests, and additional processes specified that > > address topics such as authentication of location, service URN > definition > > and use, augmented information that could assist emergency call takers > or > > responders. > > > > Explicitly outside the scope of this group is the question of > > pre-emption or prioritization of emergency services traffic. This > > group is considering emergency services calls which might be made by > > any user of the Internet, as opposed to government or military > > services that may impose very different authentication and routing > > requirements. > > > > While this group anticipates a close working relationship with groups > > such as NENA and ETSI EMTEL, any solution presented must be useful > > regardless of jurisdiction, and it must be possible to use without > requiring a > > single, central authority. Further, it must be possible for multiple > > delegations within a jurisdiction to be handled independently, as call > > routing for specific emergency types may be handled independently. > > > > This working group cares about privacy and security concerns, and will > > address them within its documents. > > > > > > Milestones w/revised status/dates, as proposed > > > > Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG > > for consideration as an Informational RFC > > > > Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for > > consideration as an Informational RFC > > > > Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call > > Purposes' to the IESG for consideration as a Standards Track RFC > > > > Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only > > Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG > for consideration as an > > Experimental RFC > > > > Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for > > dealing with Unauthenticated and Unauthorized Devices' to the IESG for > consideration > > as a Standards Track RFC > > > > Dec 2013 - Submit a draft 'Policy for defining new service-identifying > > labels' to the IESG for consideration as BCP > > > > > Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' > > to the IESG for consideration as an Informational RFC > > > > Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' > > to the IESG for consideration as a Standards Track RFC > > > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, or > responsible for delivering this message to the intended recipient, any > review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, and > delete it and all attachments from your computer and network. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > -- > > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Personal experiences affect the facts that judges choose to see. > --Judge Sotomayor > > > > -- > > > > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > > The budget should be balanced. The treasury should be refilled. > Public debt should be reduced. The arrogance of public officials > should be controlled. --Marcus Tullius Cicero (106-43 B.C.) > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > > ** > > -- > > ** > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > I have learned > To spell hors d'oeuvres > Which still grates on > Some people's n'oeuvres. > -- Warren Knox > --001a11c2e964b0376604e94422fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Oct 21, 2013 at 8:47 PM, Randall Gellens <randy@qti.qualcomm.com= > wrote:
Hi Richard,

I don't what what the phrase "useful regardless of jurisdiction" is supposed to mean in this context, and I'm concerned that it might be interpreted to mean that work needed for, e.g., eCall that is intended for use within the E.U. is out of scope.=A0 Likewise for work intended for NENA's needs.=A0 I agree that we don't want to do work that *can't* be used broadly on the Internet, but that's different than prohibiting work *intended* (at least initially) for use within a particular continent.=A0 I suppose we could say "potentially useful" instead of just "useful" to make it clear that the prohibition is only on what the work *could* be used for, and not what it is initially intended for use for.=A0 I still think we could just delete the sentence, since I don't see the group in danger of doing work that can't be broadly used.

Ok, I think we're more or less on the sa= me page w.r.t. the intent of the "jurisdiction" text. =A0How abou= t this?

OLD: "any solution presented must be useful = regardless of jurisdiction"
NEW: "any solution presente= d must not rely on assumptions specific to a given jurisdiction or region&q= uot;

=A0
To me, the phrase "it must be possible to use without requiring a single, central authority" seems intended to limit the work that became LosT, to try and avoid creating an LDAP-type situation that required a global root.

However, it seems like that's still a desirable goal for other = systems, right? =A0Just to make something up, suppose an ACN system depende= d on a single, standardized clearing house for ACN notifications. =A0That w= ould be bad, right? =A0But it could also be tempting in a particular jurisd= iction to assume that such a clearing-house is set in the standard. =A0So I= STM this text is valuable for reminding people that things like that need t= o be discoverable.

--Richard


=A0

At 8:29 PM +0300 10/21/13, Richard Barnes wrote:

Could you explain more why that sentence is problematic? =A0After all, our job here is to design things for the whole Internet; work that is only useful to a given jurisdiction should be done there.

That's not to say that the general work can't be based on locality-specific work, and done at the same time -- RFC 6881 is arguably a generalization of a part of the NENA system. =A0But what's done in the IETF needs to remain general.

--Richard


On Mon, Oct 21, 2013 at 8:24 PM, Randall Gellens <ran= dy@qti.qualcomm.com> wrote:
Hi Roger,

I suggest deleting:

=A0=A0=A0=A0=A0=A0=A0 "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority"

The text seems to me to be more applicable to the solution that became LoST.=A0 As such, I don't think it serves any purpose now.

=A0=A0=A0=A0=A0


At 5:10 PM +0000 10/21/13, Roger Marshall wrote:

Randy:
I'm not sure what you're proposing as a change to the text.
=A0
I agree that the present text has some history in pre-LoST, but I don't think its inclusion limits what you are suggesting, (ACN or pan-EU emergency calling).
=A0
-roger.
=A0
From: Randall Gellens [mailto:randy@qti.qualcomm.com]
Sent: Monday, October 07, 2013 1:46 PM
To: Roger Marshall; ecrit_ietf.org
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought
=A0
I realize some of this language is a holdover from our very early days when we weren't sure which way we could go for things which became LoST, for example.=A0 Still, I'm not sure exactly what "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority" mean today.=A0 In one sense, everything we do has dependency on jurisdiction, because not all jurisdictions will migrate to next-generation at the same time.=A0 A SIP-based emergency call won't work in a legacy emergency call jurisdiction.
=A0
We want to be sure that we can work on generic ACN and pan-Europen eCall.
=A0
=A0
At 6:18 PM +0000 10/4/13, Roger Marshall wrote:
=A0
Content-Language: en-US
Content-Type: multipart/alternative;
=A0=A0=A0=A0 boundary=3D"_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_"
The ECRIT working group agreed that the chairs would propose updated language to the wg charter, along with milestone data changes.
=A0
Compare this to the original charter found at: http://tools.ietf.org/wg/ecrit/charters.
=A0
Please send your comments to the list, whether in favor, or with alternative wording and/or dates.
=A0
Regards,
=A0
Roger Marshall/Marc Linsner
ECRIT Chairs
=A0
ECRIT charter (w/proposed revisions):

=A0
Description of Working Group:
=A0
=A0=A0=A0 In a number of areas, the public switched telephone network (PSTN) has
=A0=A0=A0 been configured to recognize an explicitly specified number (usually
=A0=A0=A0 one that is short and easily memorized) as a request for emergency
=A0=A0=A0 services.=A0 These numbers (e.g., 911, 112) are related to an emergency
=A0=A0=A0 service context and depend on a broad, regional configuration of
=A0=A0=A0 service contact methods and a geographically-constrained approach for
=A0=A0=A0 service delivery.=A0 These calls are intended to be delivered to special
=A0=A0=A0 call centers equipped to manage emergency response. Successful
=A0=A0=A0 delivery of an emergency service call within those systems requires
=A0=A0=A0 an association of both the physical location of the originating device
=A0=A0=A0 along with appropriate call routing to an emergency service center.
=A0
=A0=A0=A0 Calls placed using Internet technologies do not use the same systems
=A0=A0=A0 Mentioned above to achieve those same goals, and the common use of
=A0=A0=A0 overlay networks and tunnels (either as VPNs or for mobility) makes
=A0=A0=A0 meeting these goals even more challenging.=A0 There are, however,
=A0=A0=A0 Internet technologies available to manage location and to perform call
=A0=A0=A0 routing.=A0 This working group will describe where and how these mechanisms
=A0=A0=A0 may be used. The group will show how the availability of location data
=A0=A0=A0 and call routing information at different steps in the call session
=A0=A0=A0 setup would enable communication between a user and a relevant emergency
=A0=A0=A0 response center. Though the term "call routing" is used in this document,
=A0=A0=A0 it should be understood that some of the mechanisms which will be
=A0=A0=A0 described might be used to enable other types of media streams. Video
=A0=A0=A0 and text messaging, for example, might be used to request emergency

=A0=A0=A0 services.
=A0
=A0=A0=A0 Beyond human initiated emergency call request mechanisms, this group will
=A0=A0=A0 develop new methods to request emergency assistance, such as sensor
=A0=A0=A0 initiated emergency requests, and additional processes specified that
=A0=A0=A0 address topics such as authentication of location, service URN definition
=A0=A0=A0 and use, augmented information that could assist emergency call takers or
=A0=A0=A0 responders.
=A0
=A0=A0=A0 Explicitly outside the scope of this group is the question of
=A0=A0=A0 pre-emption or prioritization of emergency services traffic. This
=A0=A0=A0 group is considering emergency services calls which might be made by
=A0=A0=A0 any user of the Internet, as opposed to government or military
=A0=A0=A0 services that may impose very different authentication and routing
=A0=A0=A0 requirements.
=A0
=A0=A0=A0 While this group anticipates a close working relationship with groups
=A0=A0=A0 such as NENA and ETSI EMTEL, any solution presented must be useful
=A0=A0=A0 regardless of jurisdiction, and it must be possible to use without requiring a
=A0=A0=A0 single, central authority.=A0 Further, it must be possible for multiple
=A0 =A0=A0delegations within a jurisdiction to be handled independently, as call
=A0=A0=A0 routing for specific emergency types may be handled independently.
=A0
=A0 =A0=A0This working group cares about privacy and security concerns, and will
=A0=A0=A0 address them within its documents.
=A0
=A0
Milestones w/revised status/dates, as proposed
=A0
Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG
for consideration as an Informational RFC
=A0
Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for
consideration as an Informational RFC
=A0
Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call
Purposes' to the IESG for consideration as a Standards Track RFC
=A0
Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only
Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an
Experimental RFC
=A0
Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for
dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration
as a Standards Track RFC
=A0
Dec 2013 - Submit a draft 'Policy for defining new service-identifying
labels' to the IESG for consideration as BCP

=A0
Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'
to the IESG for consideration as an Informational RFC
=A0
Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'
to the IESG for consideration as a Standards Track RFC
=A0
CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ecrit
=A0
=A0
--
Randall Gellens
Opinions are personal;=A0=A0=A0 facts are suspect;=A0=A0=A0 I speak for myself only
-------------- Randomly selected tag: ---------------
Personal experiences affect the facts that judges choose to see.
=A0=A0=A0=A0=A0=A0 --Judge Sotomayor


--
=A0
Randall Gellens
Opinions are personal;=A0=A0=A0 facts are suspect;=A0=A0=A0 I speak for myself only
-------------- Randomly selected tag: ---------------
The budget should be balanced. =A0The treasury should be refilled.
Public debt should be reduced. =A0The arrogance of public officials
should be controlled. =A0=A0=A0=A0=A0=A0=A0--Marcus Tullius Cicero (106-43 B.C.)

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


--=20
Randall Gel= lens
Opinions are personal;=A0=A0=A0 facts are suspect;=A0=A0=A0 I speak for myself only
-------------- Randomly selected tag: ---------------
I have learned
To spell hors d'oeuvres
Which still grates on
Some people's n'oeuvres.
=A0=A0=A0=A0=A0=A0=A0-- Warren Knox

--001a11c2e964b0376604e94422fb-- From randy@qti.qualcomm.com Mon Oct 21 11:29:39 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB1311E843A for ; Mon, 21 Oct 2013 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.141 X-Spam-Level: X-Spam-Status: No, score=-101.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWFH8k9Egs8H for ; Mon, 21 Oct 2013 11:29:35 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id DE42811E8493 for ; Mon, 21 Oct 2013 11:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1382380168; x=1413916168; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=XrzVeZLqg6Yv0TAk9JuwH6Kux3vle4Qocsb8NRmWILo=; b=xtwxADyOT2CEppWBvTFINFLyNTuKc1dcBDVxKaNrpBsdEYQ4K65GCaOE GIJfPW1sj5pr5+vlf9+id5O68v7fx3uNJ0DzKImKXY4YdrwF7YANamwOu 1F6Dvsy/cZdgmvO+CuWDNbJDyzGEO7YcwS1ShDLatLzQLBYgKXg2trfTF g=; X-IronPort-AV: E=McAfee;i="5400,1158,7235"; a="54385544" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 21 Oct 2013 11:29:28 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7235"; a="561144091" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Oct 2013 11:29:28 -0700 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Oct 2013 11:29:27 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 21 Oct 2013 11:29:24 -0700 To: Richard Barnes From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:29:39 -0000 Re: [Ecrit] Charter & Milestones update - Comments sought
Hi Richard,

At 9:05 PM +0300 10/21/13, Richard Barnes wrote:

On Mon, Oct 21, 2013 at 8:47 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:
Hi Richard,

I don't what what the phrase "useful regardless of jurisdiction" is supposed to mean in this context, and I'm concerned that it might be interpreted to mean that work needed for, e.g., eCall that is intended for use within the E.U. is out of scope.  Likewise for work intended for NENA's needs.  I agree that we don't want to do work that *can't* be used broadly on the Internet, but that's different than prohibiting work *intended* (at least initially) for use within a particular continent.  I suppose we could say "potentially useful" instead of just "useful" to make it clear that the prohibition is only on what the work *could* be used for, and not what it is initially intended for use for.  I still think we could just delete the sentence, since I don't see the group in danger of doing work that can't be broadly used.

Ok, I think we're more or less on the same page w.r.t. the intent of the "jurisdiction" text.  How about this?

OLD: "any solution presented must be useful regardless of jurisdiction"
NEW: "any solution presented must not rely on assumptions specific to a given jurisdiction or region"

I'm not sure what this will mean in practice, and I'm concerned that it could limit work that NENA or eCall needs (someone could say that all of NENA i3 is based on assumptions specific to North America).  Let's take a step back and see first if we feel that the group is likely to venture into something that we want to prohibit.  If so, let's agree precisely what it is that the group is likely to do and then agree on text to stop it.  On the other hand, if we think the group and its chairs are sufficiently mature at this stage, maybe we don't need this text in the charter.  Groups certainly do need more restrictive charter text early on.



To me, the phrase "it must be possible to use without requiring a single, central authority" seems intended to limit the work that became LosT, to try and avoid creating an LDAP-type situation that required a global root.

However, it seems like that's still a desirable goal for other systems, right?  Just to make something up, suppose an ACN system depended on a single, standardized clearing house for ACN notifications.  That would be bad, right?  But it could also be tempting in a particular jurisdiction to assume that such a clearing-house is set in the standard.  So ISTM this text is valuable for reminding people that things like that need to be discoverable.

I'd rather not have charter language based on such made up examples, especially for a group that is fairly mature and that doesn't seem to be in danger of heading off into dangerous areas.  If someone proposed an ACN or even an authority-to-citizen alert protocol that required a single authority to clear all transactions, would the group be in danger of accepting the proposal?  If not, then we don't need the charter to prohibit it.




At 8:29 PM +0300 10/21/13, Richard Barnes wrote:

Could you explain more why that sentence is problematic?  After all, our job here is to design things for the whole Internet; work that is only useful to a given jurisdiction should be done there.

That's not to say that the general work can't be based on locality-specific work, and done at the same time -- RFC 6881 is arguably a generalization of a part of the NENA system.  But what's done in the IETF needs to remain general.

--Richard


On Mon, Oct 21, 2013 at 8:24 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:
Hi Roger,

I suggest deleting:

        "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority"


The text seems to me to be more applicable to the solution that became LoST.  As such, I don't think it serves any purpose now.

    


At 5:10 PM +0000 10/21/13, Roger Marshall wrote:

Randy:
I'm not sure what you're proposing as a change to the text.
 
I agree that the present text has some history in pre-LoST, but I don't think its inclusion limits what you are suggesting, (ACN or pan-EU emergency calling).
 
-roger.
 
From: Randall Gellens [mailto:randy@qti.qualcomm.com]
Sent: Monday, October 07, 2013 1:46 PM
To: Roger Marshall; ecrit_ietf.org
Subject: Re: [Ecrit] Charter & Milestones update - Comments sought
 
I realize some of this language is a holdover from our very early days when we weren't sure which way we could go for things which became LoST, for example.  Still, I'm not sure exactly what "any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single, central authority" mean today.  In one sense, everything we do has dependency on jurisdiction, because not all jurisdictions will migrate to next-generation at the same time.  A SIP-based emergency call won't work in a legacy emergency call jurisdiction.
 
We want to be sure that we can work on generic ACN and pan-Europen eCall.
 
 
At 6:18 PM +0000 10/4/13, Roger Marshall wrote:
 
Content-Language: en-US
Content-Type: multipart/alternative;
     boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecomsy_"
The ECRIT working group agreed that the chairs would propose updated language to the wg charter, along with milestone data changes.
 
Compare this to the original charter found at: http://tools.ietf.org/wg/ecrit/charters.
 
Please send your comments to the list, whether in favor, or with alternative wording and/or dates.
 
Regards,
 
Roger Marshall/Marc Linsner
ECRIT Chairs
 
ECRIT charter (w/proposed revisions):

 
Description of Working Group:
 
    In a number of areas, the public switched telephone network (PSTN) has
    been configured to recognize an explicitly specified number (usually
    one that is short and easily memorized) as a request for emergency
    services.  These numbers (e.g., 911, 112) are related to an emergency
    service context and depend on a broad, regional configuration of
    service contact methods and a geographically-constrained approach for
    service delivery.  These calls are intended to be delivered to special
    call centers equipped to manage emergency response. Successful
    delivery of an emergency service call within those systems requires
    an association of both the physical location of the originating device
    along with appropriate call routing to an emergency service center.
 
    Calls placed using Internet technologies do not use the same systems
    Mentioned above to achieve those same goals, and the common use of
    overlay networks and tunnels (either as VPNs or for mobility) makes
    meeting these goals even more challenging.  There are, however,
    Internet technologies available to manage location and to perform call
    routing.  This working group will describe where and how these mechanisms
    may be used. The group will show how the availability of location data
    and call routing information at different steps in the call session
    setup would enable communication between a user and a relevant emergency
    response center. Though the term "call routing" is used in this document,
    it should be understood that some of the mechanisms which will be
    described might be used to enable other types of media streams. Video
    and text messaging, for example, might be used to request emergency

    services.
 
    Beyond human initiated emergency call request mechanisms, this group will
    develop new methods to request emergency assistance, such as sensor
    initiated emergency requests, and additional processes specified that
    address topics such as authentication of location, service URN definition

    and use, augmented information that could assist emergency call takers or
    responders.
 
    Explicitly outside the scope of this group is the question of
    pre-emption or prioritization of emergency services traffic. This
    group is considering emergency services calls which might be made by
    any user of the Internet, as opposed to government or military
    services that may impose very different authentication and routing
    requirements.
 
    While this group anticipates a close working relationship with groups
    such as NENA and ETSI EMTEL, any solution presented must be useful
    regardless of jurisdiction, and it must be possible to use without requiring a
    single, central authority.  Further, it must be possible for multiple
    delegations within a jurisdiction to be handled independently, as call
    routing for specific emergency types may be handled independently.
 
    This working group cares about privacy and security concerns, and will
    address them within its documents.
 
 
Milestones w/revised status/dates, as proposed
 
Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG
for consideration as an Informational RFC
 
Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for
consideration as an Informational RFC
 
Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call
Purposes' to the IESG for consideration as a Standards Track RFC
 
Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only
Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an
Experimental RFC
 
Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for
dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration
as a Standards Track RFC
 
Dec 2013 - Submit a draft 'Policy for defining new service-identifying
labels' to the IESG for consideration as BCP

 
Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing'
to the IESG for consideration as an Informational RFC
 
Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services'
to the IESG for consideration as a Standards Track RFC
 
CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
 
 
--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Personal experiences affect the facts that judges choose to see.
       --Judge Sotomayor


--
 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The budget should be balanced.  The treasury should be refilled.
Public debt should be reduced.  The arrogance of public officials
should be controlled.        --Marcus Tullius Cicero (106-43 B.C.)

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


--
 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I have learned
To spell hors d'oeuvres
Which still grates on
Some people's n'oeuvres.
       -- Warren Knox


--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
"SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of
San Francisco Police Jacket, as reported by Herb Caen in SF Chronicle
From RMarshall@telecomsys.com Mon Oct 21 13:01:08 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDB511E86D8 for ; Mon, 21 Oct 2013 13:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvlBwGdOwPPt for ; Mon, 21 Oct 2013 13:00:59 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1C911E8282 for ; Mon, 21 Oct 2013 12:59:43 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.5/8.14.5) with ESMTP id r9LJxaf1005768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 21 Oct 2013 12:59:36 -0700 Received: from SEA-EXCAS-3.telecomsys.com (10.32.12.6) by SEA-EXCAS-2.telecomsys.com (10.32.12.187) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 21 Oct 2013 12:59:36 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.31]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.01.0218.012; Mon, 21 Oct 2013 12:59:35 -0700 From: Roger Marshall To: Randall Gellens , Richard Barnes Thread-Topic: [Ecrit] Charter & Milestones update - Comments sought Thread-Index: AQHOzogvgOHANmOzQNGU4fpZSblfKZn/7zcA//+bIxA= Date: Mon, 21 Oct 2013 19:59:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC4864C2SEAEXMB1telecomsy_" MIME-Version: 1.0 Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:01:09 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC4864C2SEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Richard: You suggested text: "any solution presented must not rely on assumptions sp= ecific to a given jurisdiction or region" I think your text mod takes us too far, since some of our ECRIT solutions d= o rely on assumptions specific to a given jurisdiction... (but not only tha= t jurisdiction). What's wrong with the original text, when it says, "any solution presented must be useful regardless of jurisdiction" I believe means that we should build "general purpose solutions" that could= be applied anywhere (though assuming only with Internet technologies). Randy: Your objection to the text, "...and it must be possible to use without requiring a single, central authority. " yes, this has applied to routing, but I don't think it is/was limited to ju= st routing (It doesn't even preclude having a single, central authority). = I think this could be taken to mean any distributed service, including ric= h data sources and the like. No solutions that _require_ a central authori= ty to own it all. -roger. -roger. From: Randall Gellens [mailto:randy@qti.qualcomm.com] Sent: Monday, October 21, 2013 11:29 AM To: Richard Barnes Cc: Roger Marshall; ecrit_ietf.org Subject: Re: [Ecrit] Charter & Milestones update - Comments sought Hi Richard, At 9:05 PM +0300 10/21/13, Richard Barnes wrote: On Mon, Oct 21, 2013 at 8:47 PM, Randall Gellens > wrote: Hi Richard, I don't what what the phrase "useful regardless of jurisdiction" is suppose= d to mean in this context, and I'm concerned that it might be interpreted t= o mean that work needed for, e.g., eCall that is intended for use within th= e E.U. is out of scope. Likewise for work intended for NENA's needs. I ag= ree that we don't want to do work that *can't* be used broadly on the Inter= net, but that's different than prohibiting work *intended* (at least initia= lly) for use within a particular continent. I suppose we could say "potent= ially useful" instead of just "useful" to make it clear that the prohibitio= n is only on what the work *could* be used for, and not what it is initiall= y intended for use for. I still think we could just delete the sentence, s= ince I don't see the group in danger of doing work that can't be broadly us= ed. Ok, I think we're more or less on the same page w.r.t. the intent of the "j= urisdiction" text. How about this? OLD: "any solution presented must be useful regardless of jurisdiction" NEW: "any solution presented must not rely on assumptions specific to a giv= en jurisdiction or region" I'm not sure what this will mean in practice, and I'm concerned that it cou= ld limit work that NENA or eCall needs (someone could say that all of NENA = i3 is based on assumptions specific to North America). Let's take a step b= ack and see first if we feel that the group is likely to venture into somet= hing that we want to prohibit. If so, let's agree precisely what it is tha= t the group is likely to do and then agree on text to stop it. On the othe= r hand, if we think the group and its chairs are sufficiently mature at thi= s stage, maybe we don't need this text in the charter. Groups certainly do= need more restrictive charter text early on. To me, the phrase "it must be possible to use without requiring a single, c= entral authority" seems intended to limit the work that became LosT, to try= and avoid creating an LDAP-type situation that required a global root. However, it seems like that's still a desirable goal for other systems, rig= ht? Just to make something up, suppose an ACN system depended on a single,= standardized clearing house for ACN notifications. That would be bad, rig= ht? But it could also be tempting in a particular jurisdiction to assume t= hat such a clearing-house is set in the standard. So ISTM this text is val= uable for reminding people that things like that need to be discoverable. I'd rather not have charter language based on such made up examples, especi= ally for a group that is fairly mature and that doesn't seem to be in dange= r of heading off into dangerous areas. If someone proposed an ACN or even = an authority-to-citizen alert protocol that required a single authority to = clear all transactions, would the group be in danger of accepting the propo= sal? If not, then we don't need the charter to prohibit it. At 8:29 PM +0300 10/21/13, Richard Barnes wrote: Could you explain more why that sentence is problematic? After all, our jo= b here is to design things for the whole Internet; work that is only useful= to a given jurisdiction should be done there. That's not to say that the general work can't be based on locality-specific= work, and done at the same time -- RFC 6881 is arguably a generalization o= f a part of the NENA system. But what's done in the IETF needs to remain g= eneral. --Richard On Mon, Oct 21, 2013 at 8:24 PM, Randall Gellens > wrote: Hi Roger, I suggest deleting: "any solution presented must be useful regardless of jurisdiction, = and it must be possible to use without requiring a single, central authorit= y" The text seems to me to be more applicable to the solution that became LoST= . As such, I don't think it serves any purpose now. At 5:10 PM +0000 10/21/13, Roger Marshall wrote: Randy: I'm not sure what you're proposing as a change to the text. I agree that the present text has some history in pre-LoST, but I don't thi= nk its inclusion limits what you are suggesting, (ACN or pan-EU emergency c= alling). -roger. From: Randall Gellens [mailto:randy@qti.qualcomm.com] Sent: Monday, October 07, 2013 1:46 PM To: Roger Marshall; ecrit_ietf.org Subject: Re: [Ecrit] Charter & Milestones update - Comments sought I realize some of this language is a holdover from our very early days when= we weren't sure which way we could go for things which became LoST, for ex= ample. Still, I'm not sure exactly what "any solution presented must be us= eful regardless of jurisdiction, and it must be possible to use without req= uiring a single, central authority" mean today. In one sense, everything w= e do has dependency on jurisdiction, because not all jurisdictions will mig= rate to next-generation at the same time. A SIP-based emergency call won't= work in a legacy emergency call jurisdiction. We want to be sure that we can work on generic ACN and pan-Europen eCall. At 6:18 PM +0000 10/4/13, Roger Marshall wrote: Content-Language: en-US Content-Type: multipart/alternative; boundary=3D"_000_FBD5AAFFD0978846BF6D3FAB4C892ACC45811BSEAEXMB1telecom= sy_" The ECRIT working group agreed that the chairs would propose updated langua= ge to the wg charter, along with milestone data changes. Compare this to the original charter found at: http://tools.ietf.org/wg/ecr= it/charters. Please send your comments to the list, whether in favor, or with alternativ= e wording and/or dates. Regards, Roger Marshall/Marc Linsner ECRIT Chairs ECRIT charter (w/proposed revisions): Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems Mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group will describe where and how these mechanis= ms may be used. The group will show how the availability of location data and call routing information at different steps in the call session setup would enable communication between a user and a relevant emergenc= y response center. Though the term "call routing" is used in this documen= t, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. Beyond human initiated emergency call request mechanisms, this group wi= ll develop new methods to request emergency assistance, such as sensor initiated emergency requests, and additional processes specified that address topics such as authentication of location, service URN definiti= on and use, augmented information that could assist emergency call takers = or responders. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requ= iring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be handled independently. This working group cares about privacy and security concerns, and will address them within its documents. Milestones w/revised status/dates, as proposed Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG f= or consideration as an Experimental RFC Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for cons= ideration as a Standards Track RFC Dec 2013 - Submit a draft 'Policy for defining new service-identifying labels' to the IESG for consideration as BCP Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Personal experiences affect the facts that judges choose to see. --Judge Sotomayor -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The budget should be balanced. The treasury should be refilled. Public debt should be reduced. The arrogance of public officials should be controlled. --Marcus Tullius Cicero (106-43 B.C.) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I have learned To spell hors d'oeuvres Which still grates on Some people's n'oeuvres. -- Warren Knox -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- "SFPD Homicide: Our Day Begins when Yours End" --Slogan seen on back of San Francisco Police Jacket, as reported by Herb Caen in SF Chronicle --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC4864C2SEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ecrit] Charter & Milestones update - Comments sought</title= > <style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} tt {mso-style-priority:99; font-family:"Courier New";} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} span.EmailStyle22 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Richard:<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">You suggested text: ̶= 0;</span>any solution presented must not rely on assumptions specific to a = given jurisdiction or region”<o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I think your text mod tak= es us too far, since some of our ECRIT solutions do rely on assumptions spe= cific to a given jurisdiction… (but not only that jurisdiction).<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">What’s wrong with t= he original text, when it says,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">“</span>any solutio= n presented must be useful regardless of jurisdiction”<o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">I believe means that we s= hould build “general purpose solutions” that could be applied a= nywhere (though assuming only with Internet technologies).<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Randy:<o:p></o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Your objection to the tex= t,<o:p></o:p></span></p> <p class=3D"MsoNormal">“…and it must be possible to use without= requiring a<o:p></o:p></p> <p class=3D"MsoNormal">    single, central authority. &= #8220;<o:p></o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">yes, this has applied to = routing, but I don’t think it is/was limited to just routing  (I= t doesn’t even preclude having a single, central authority).  I = think this could be taken to mean any distributed service, including rich data s= ources and the like.  No solutions that _<i>require</i>_ a central aut= hority to own it all.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">-roger. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">-roger.<o:p></o:p></span>= </p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif"">From:</span></b><span style=3D"font-s= ize:10.0pt;font-family:"Tahoma","sans-serif""> Randall = Gellens [mailto:randy@qti.qualcomm.com] <br> <b>Sent:</b> Monday, October 21, 2013 11:29 AM<br> <b>To:</b> Richard Barnes<br> <b>Cc:</b> Roger Marshall; ecrit_ietf.org<br> <b>Subject:</b> Re: [Ecrit] Charter & Milestones update - Comments soug= ht<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal">Hi Richard,<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">At 9:05 PM +0300 10/21/13, Richard Barnes wrote:= <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">On Mon, Oct 21, 2013 at 8:47 PM, Randall Gellens <= ;<a href=3D"mailto:randy@qti.qualcomm.com">randy@qti.qualcomm.com</a>> w= rote:<o:p></o:p></p> <p class=3D"MsoNormal">Hi Richard,<o:p></o:p></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">I don't what what the phrase "useful regardless= of jurisdiction" is supposed to mean in this context, and I'm concern= ed that it might be interpreted to mean that work needed for, e.g., eCall t= hat is intended for use within the E.U. is out of scope.  Likewise for work intended for NENA's needs.  I agree= that we don't want to do work that *can't* be used broadly on the Internet= , but that's different than prohibiting work *intended* (at least initially= ) for use within a particular continent.  I suppose we could say "potentially useful" instead of just &quo= t;useful" to make it clear that the prohibition is only on what the wo= rk *could* be used for, and not what it is initially intended for use for.&= nbsp; I still think we could just delete the sentence, since I don't see the group in danger of doing work that can't be broadly used.<= o:p></o:p></p> </blockquote> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Ok, I think we're more or less on the same page w.r.= t. the intent of the "jurisdiction" text.  How about this?<o= :p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">OLD: "any solution presented must be useful reg= ardless of jurisdiction"<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">NEW: "any solution presented must not rely on a= ssumptions specific to a given jurisdiction or region"<o:p></o:p></p> </blockquote> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I'm not sure what this will mean in practice, and I'= m concerned that it could limit work that NENA or eCall needs (someone coul= d say that all of NENA i3 is based on assumptions specific to North America= ).  Let's take a step back and see first if we feel that the group is likely to venture into something that w= e want to prohibit.  If so, let's agree precisely what it is that the = group is likely to do and then agree on text to stop it.  On the other= hand, if we think the group and its chairs are sufficiently mature at this stage, maybe we don't need this text in th= e charter.  Groups certainly do need more restrictive charter text ear= ly on.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">To me, the phrase "it must be possible to use w= ithout requiring a single, central authority" seems intended to limit = the work that became LosT, to try and avoid creating an LDAP-type situation= that required a global root.<o:p></o:p></p> </blockquote> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">However, it seems like that's still a desirable goal= for other systems, right?  Just to make something up, suppose an ACN = system depended on a single, standardized clearing house for ACN notificati= ons.  That would be bad, right?  But it could also be tempting in a particular jurisdiction to assume that such a = clearing-house is set in the standard.  So ISTM this text is valuable = for reminding people that things like that need to be discoverable.<o:p></o= :p></p> </blockquote> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I'd rather not have charter language based on such m= ade up examples, especially for a group that is fairly mature and that does= n't seem to be in danger of heading off into dangerous areas.  If some= one proposed an ACN or even an authority-to-citizen alert protocol that required a single authority to clear all transactions,= would the group be in danger of accepting the proposal?  If not, then= we don't need the charter to prohibit it.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">At 8:29 PM +0300 10/21/13, Richard Barnes wrote:= <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><br> <br> <o:p></o:p></p> <p class=3D"MsoNormal">Could you explain more why that sentence is problema= tic?  After all, our job here is to design things for the whole Intern= et; work that is only useful to a given jurisdiction should be done there.<= o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">That's not to say that the general work can't be bas= ed on locality-specific work, and done at the same time -- RFC 6881 is argu= ably a generalization of a part of the NENA system.  But what's done i= n the IETF needs to remain general.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">--Richard<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">On Mon, Oct 21, 2013 at 8:24 PM, Randall Gellens <= ;<a href=3D"mailto:randy@qti.qualcomm.com">randy@qti.qualcomm.com</a>> w= rote:<o:p></o:p></p> <p class=3D"MsoNormal">Hi Roger,<o:p></o:p></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">I suggest deleting:<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">        "any= solution presented must be useful regardless of jurisdiction, and it must = be possible to use without requiring a single, central authority"<o:p>= </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">The text seems to me to be more applicable to the so= lution that became LoST.  As such, I don't think it serves any purpose= now.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">At 5:10 PM +0000 10/21/13, Roger Marshall wrote:= <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><br> <br> <o:p></o:p></p> <p class=3D"MsoNormal">Randy:<o:p></o:p></p> </blockquote> </blockquote> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">I'm not sure what you're proposing as a change to th= e text.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">I agree that the present text has some history in pr= e-LoST, but I don't think its inclusion limits what you are suggesting, (AC= N or pan-EU emergency calling).<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">-roger.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><b>From:</b> Randall Gellens [mailto:<a href=3D"mail= to:randy@qti.qualcomm.com">randy@qti.qualcomm.com</a>]<br> <b>Sent:</b> Monday, October 07, 2013 1:46 PM<br> <b>To:</b> Roger Marshall; <a href=3D"http://ecrit_ietf.org">ecrit_ietf.org= </a><br> <b>Subject:</b> Re: [Ecrit] Charter & Milestones update - Comments soug= ht<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">I realize some of this language is a holdover from o= ur very early days when we weren't sure which way we could go for things wh= ich became LoST, for example.  Still, I'm not sure exactly what "= any solution presented must be useful regardless of jurisdiction, and it must be possible to use without requiring a single= , central authority" mean today.  In one sense, everything we do = has dependency on jurisdiction, because not all jurisdictions will migrate = to next-generation at the same time.  A SIP-based emergency call won't work in a legacy emergency call jurisdiction.<o:p></o= :p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">We want to be sure that we can work on generic ACN a= nd pan-Europen eCall.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">At 6:18 PM +0000 10/4/13, Roger Marshall wrote:<= o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> <p class=3D"MsoNormal">Content-Language: en-US<br> Content-Type: multipart/alternative;<br>      boundary=3D"_000_FBD5AAFFD0978846BF6D3FAB4C89= 2ACC45811BSEAEXMB1telecomsy_"<o:p></o:p></p> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">The ECRIT working group agreed that the chairs would= propose updated language to the wg charter, along with milestone data chan= ges.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Compare this to the original charter found at: <a hr= ef=3D"http://tools.ietf.org/wg/ecrit/charters"> http://tools.ietf.org/wg/ecrit/charters</a>.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Please send your comments to the list, whether in fa= vor, or with alternative wording and/or dates.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Regards,<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Roger Marshall/Marc Linsner<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">ECRIT Chairs<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">ECRIT charter (w/proposed revisions):<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Description of Working Group:<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    In a number of areas, the public = switched telephone network (PSTN) has<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    been configured to recognize an e= xplicitly specified number (usually<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    one that is short and easily memo= rized) as a request for emergency<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    services.  These numbers (e.= g., 911, 112) are related to an emergency<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    service context and depend on a b= road, regional configuration of<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    service contact methods and a geo= graphically-constrained approach for<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    service delivery.  These cal= ls are intended to be delivered to special<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    call centers equipped to manage e= mergency response. Successful<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    delivery of an emergency service = call within those systems requires<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    an association of both the physic= al location of the originating device<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    along with appropriate call routi= ng to an emergency service center.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    Calls placed using Internet techn= ologies do not use the same systems<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    Mentioned above to achieve those = same goals, and the common use of<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    overlay networks and tunnels (eit= her as VPNs or for mobility) makes<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    meeting these goals even more cha= llenging.  There are, however,<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    Internet technologies available t= o manage location and to perform call<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    routing.  This working group= will describe where and how these mechanisms<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    may be used. The group will show = how the availability of location data<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    and call routing information at d= ifferent steps in the call session<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    setup would enable communication = between a user and a relevant emergency<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    response center. Though the term = "call routing" is used in this document,<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    it should be understood that some= of the mechanisms which will be<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    described might be used to enable= other types of media streams. Video<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    and text messaging, for example, = might be used to request emergency<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    services.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    Beyond human initiated emergency = call request mechanisms, this group will<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    develop new methods to request em= ergency assistance, such as sensor<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    initiated emergency requests, and= additional processes specified that<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    address topics such as authentica= tion of location, service URN definition<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    and use, augmented information th= at could assist emergency call takers or<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    responders.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    Explicitly outside the scope of t= his group is the question of<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    pre-emption or prioritization of = emergency services traffic. This<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    group is considering emergency se= rvices calls which might be made by<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    any user of the Internet, as oppo= sed to government or military<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    services that may impose very dif= ferent authentication and routing<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    requirements.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    While this group anticipates a cl= ose working relationship with groups<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    such as NENA and ETSI EMTEL, any = solution presented must be useful<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    regardless of jurisdiction, and i= t must be possible to use without requiring a<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    single, central authority.  = Further, it must be possible for multiple<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    delegations within a jurisdiction= to be handled independently, as call<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    routing for specific emergency ty= pes may be handled independently.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    This working group cares about pr= ivacy and security concerns, and will<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">    address them within its documents= .<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Milestones w/revised status/dates, as proposed<o:p><= /o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Done - Submit 'Public Safety Answering Point (PSAP) = Callbacks' to the IESG<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">for consideration as an Informational RFC<o:p></o:p>= </p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Nov 2013 - Submit 'Trustworthy Location Information'= to the IESG for<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">consideration as an Informational RFC<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Dec 2013 - Submit 'Additional Data related to a Call= for Emergency Call<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Purposes' to the IESG for consideration as a Standar= ds Track RFC<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Nov 2013 - Submit 'Common Alerting Protocol (CAP) ba= sed Data-Only<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Emergency Alerts using the Session Initiation Protoc= ol (SIP)' to the IESG for consideration as an<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Experimental RFC<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Dec 2013 - Submit 'Extensions to the Emergency Servi= ces Architecture for<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">dealing with Unauthenticated and Unauthorized Device= s' to the IESG for consideration<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">as a Standards Track RFC<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Dec 2013 - Submit a draft 'Policy for defining new s= ervice-identifying<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">labels' to the IESG for consideration as BCP<o:p></o= :p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Mar 2014 - Submit 'Using Imprecise Location for Emer= gency Call Routing'<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">to the IESG for consideration as an Informational RF= C<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Dec 2013 - Submit a draft 'URN For Country Specific = Emergency Services'<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">to the IESG for consideration as a Standards Track R= FC<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">CONFIDENTIALITY NOTICE: The information contained in= this message may be privileged and/or confidential. If you are not the int= ended recipient, or responsible for delivering this message to the intended= recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attach= ment(s) is strictly prohibited. If you have received this message in error,= please notify the sender immediately, and delete it and all attachments fr= om your computer and network.<o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><br> _______________________________________________<br> Ecrit mailing list<br> <a href=3D"mailto:Ecrit@ietf.org">Ecrit@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/ecrit">https://www.ietf.or= g/mailman/listinfo/ecrit</a><o:p></o:p></p> </blockquote> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><tt><span style=3D"font-size:10.0pt">--</span></tt><= o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal">Randall Gellens<br> Opinions are personal;    facts are suspect;  &nbs= p; I speak for myself only<br> -------------- Randomly selected tag: ---------------<br> Personal experiences affect the facts that judges choose to see.<br>        --Judge Sotomayor<o:p></o:p></p> </blockquote> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><tt><span style=3D"font-size:10.0pt">--</span></tt><= o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><span style=3D"color:black">Randall Gellens<br> Opinions are personal;    facts are suspect;  &nbs= p; I speak for myself only<br> -------------- Randomly selected tag: ---------------</span><o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><span style=3D"color:black">The budget should be bal= anced.  The treasury should be refilled.<br> Public debt should be reduced.  The arrogance of public officials<br> should be controlled.        --Marcus Tu= llius Cicero (106-43 B.C.)</span><o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><br> _______________________________________________<br> Ecrit mailing list<br> <a href=3D"mailto:Ecrit@ietf.org">Ecrit@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/ecrit">https://www.ietf.or= g/mailman/listinfo/ecrit</a><o:p></o:p></p> </blockquote> </blockquote> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><o:p> </o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><tt><span style=3D"font-size:10.0pt">--</span></tt><= o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"> <o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><span style=3D"color:black">Randall Gellens<br> Opinions are personal;    facts are suspect;  &nbs= p; I speak for myself only<br> -------------- Randomly selected tag: ---------------</span><o:p></o:p></p> </blockquote> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <p class=3D"MsoNormal"><span style=3D"color:black">I have learned<br> To spell hors d'oeuvres<br> Which still grates on<br> Some people's n'oeuvres.<br>        -- Warren Knox</span><o:p></o:p></p> </blockquote> </blockquote> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <pre>-- <o:p></o:p></pre> <div> <p class=3D"MsoNormal"><span style=3D"color:black">Randall Gellens<br> Opinions are personal;    facts are suspect;  &nbs= p; I speak for myself only<br> -------------- Randomly selected tag: ---------------</span><o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black">"SFPD Homicide: Our= Day Begins when Yours End" --Slogan seen on back of<br> San Francisco Police Jacket, as reported by Herb Caen in SF Chronicle</span= ><o:p></o:p></p> </div> </div> </body> </html> --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC4864C2SEAEXMB1telecomsy_-- From randy@qti.qualcomm.com Mon Oct 21 14:52:40 2013 Return-Path: <randy@qti.qualcomm.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF28811E86B1 for <ecrit@ietfa.amsl.com>; Mon, 21 Oct 2013 14:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.537 X-Spam-Level: X-Spam-Status: No, score=-104.537 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGzBL8YcdKkQ for <ecrit@ietfa.amsl.com>; Mon, 21 Oct 2013 14:52:36 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id D9FA411E862E for <ecrit@ietf.org>; Mon, 21 Oct 2013 14:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1382392354; x=1413928354; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=FgdTVVIriXXKm0CJmbg3KKim0y4YXvUB5Cy02oON7fQ=; b=vVbDLHy3qdNs5UsnfndjirCr/624XEBfXvKc7uuSMhWLEjm/yajVpg2z nDAcKpgLjfvvjdKl8CSWSrejLOpVKIHYvP5U648SXPuMHtu9d0e1zq+hO Eyp5TkCL769XGEd7GkDz2J4NpcGNrd6anV2JqAM6+Ym6qcKsWEytjdNny U=; X-IronPort-AV: E=McAfee;i="5400,1158,7235"; a="82357302" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 21 Oct 2013 14:52:34 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7235"; a="625977540" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 21 Oct 2013 14:52:31 -0700 Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 21 Oct 2013 14:51:57 -0700 Message-ID: <p0624060ace8b511669b9@[99.111.97.136]> In-Reply-To: <FBD5AAFFD0978846BF6D3FAB4C892ACC4864C2@SEA-EXMB-1.telecomsys.com> References: <FBD5AAFFD0978846BF6D3FAB4C892ACC45811B@SEA-EXMB-1.telecomsys.com> <p06240602ce78cc3a5e0a@10.184.126.229> <FBD5AAFFD0978846BF6D3FAB4C892ACC484ED7@SEA-EXMB-1.telecomsys.com> <p06240601ce8b1354f008@99.111.97.136> <CAL02cgRyXMNxe-UPPFBkJtDM2UeZjgardeTeXAy9TbbU2SuWWg@mail.gmail.com> <p06240604ce8b16239896@99.111.97.136> <CAL02cgSeKxrJv2B85Mjaw2SOTWNUMXfHhPnpLhCDwGZmh9xM0w@mail.gmail.com> <p06240606ce8b20c31647@[99.111.97.136]> <FBD5AAFFD0978846BF6D3FAB4C892ACC4864C2@SEA-EXMB-1.telecomsys.com> X-Mailer: Eudora for Mac OS X Date: Mon, 21 Oct 2013 14:51:55 -0700 To: Roger Marshall <RMarshall@telecomsys.com>, Richard Barnes <rlb@ipv.sx> From: Randall Gellens <randy@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Cc: "ecrit_ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Oct 2013 21:52:41 -0000 At 7:59 PM +0000 10/21/13, Roger Marshall wrote: > You suggested text: "any solution presented=20 > must not rely on assumptions specific to a=20 > given jurisdiction or region" > > I think your text mod takes us too far, since=20 > some of our ECRIT solutions do rely on=20 > assumptions specific to a given jurisdiction=8A=20 > (but not only that jurisdiction). > > What's wrong with the original text, when it says, > "any solution presented must be useful regardless of jurisdiction" > I believe means that we should build "general=20 > purpose solutions" that could be applied=20 > anywhere (though assuming only with Internet=20 > technologies). My concern is that it could be interpreted to=20 prohibit work needed for NENA or eCall, that is=20 intended for use within a specific continent.=20 Let's address your specific concern (general=20 purpose solutions). How about: "any solution presented must be general=20 enough to be potentially useful in or across=20 multiple regions or jurisdictions" -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Arguments are to be avoided; they are always vulgar and often convincing. --Oscar Wilde From RMarshall@telecomsys.com Mon Oct 21 15:32:00 2013 Return-Path: <RMarshall@telecomsys.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E28911E8333 for <ecrit@ietfa.amsl.com>; Mon, 21 Oct 2013 15:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyForsVf+BgE for <ecrit@ietfa.amsl.com>; Mon, 21 Oct 2013 15:31:51 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B31D11E8292 for <ecrit@ietf.org>; Mon, 21 Oct 2013 15:31:51 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id r9LMVfib007735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 21 Oct 2013 15:31:42 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.31]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0218.012; Mon, 21 Oct 2013 15:31:40 -0700 From: Roger Marshall <RMarshall@telecomsys.com> To: "ecrit@ietf.org" <ecrit@ietf.org> Thread-Topic: [Ecrit] Charter & Milestones update - Comments sought Thread-Index: Ac7BLfNZgOHANmOzQNGU4fpZSblfKQHOfvQAAAFQUYAAAHVsgP//94XNgAB+dAD/9FaK4A== Date: Mon, 21 Oct 2013 22:31:39 +0000 Message-ID: <FBD5AAFFD0978846BF6D3FAB4C892ACC486660@SEA-EXMB-1.telecomsys.com> References: <FBD5AAFFD0978846BF6D3FAB4C892ACC45811B@SEA-EXMB-1.telecomsys.com> <525AC37C.8090708@gmx.net> <525ACC4D.1020500@omnitor.se>, <525ACF61.7080102@gmx.net> <527682A7144B254C856D43E2B3D9E9371EFB798F@nasanexd01b.na.qualcomm.com> <525B3258.2040402@omnitor.se> In-Reply-To: <525B3258.2040402@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/mixed; boundary="_004_FBD5AAFFD0978846BF6D3FAB4C892ACC486660SEAEXMB1telecomsy_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 21 Oct 2013 16:33:24 -0700 Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 21 Oct 2013 22:32:01 -0000 --_004_FBD5AAFFD0978846BF6D3FAB4C892ACC486660SEAEXMB1telecomsy_ Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC486660SEAEXMB1telecomsy_" --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC486660SEAEXMB1telecomsy_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Based on text feedback from the list, I've updated the Charter text and Mil= estones. See below. (I've also included an attached file for redlined changes) ECRIT charter (as revised): Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems Mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group will describe where and how these mechanis= ms may be used. The group will show how the availability of location data and call routing information at different steps in the call session setup would enable communication between a user and a relevant emergenc= y response center. Though the term "call routing" is used, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Beyond human initiated emergency call request mechanisms, this group wi= ll develop new methods to request emergency assistance, such as sensor initiated emergency requests, and additional processes specified that address topics such as authentication of location, service URN definiti= on and use, augmented information that could assist emergency call takers = or responders. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA, EENA, 3GPP, and ETSI , any solution presented must be general enough to be potentially useful in or across multiple regions or jurisdictions, and it must be possible to use without requiring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, things such as call routing for specific emergency types, media types, languag= e contents, etc., may be routed differently depending on established policies and availability. This working group cares about privacy and security concerns, and will address them within its documents. Also, dependent on the above text, Gunnar has suggested the addition of the following milestone: xxx 2014 - Submit a draft 'Policy based routing in Emergency Services' to the IESG for consideration as a Standards Track RFC The complete Milestone list (as revised): Done Informational RFC containing terminology definitions and the requirem= ents Done An Informational document describing the threats and security conside= rations Done A Standards Track RFC describing how to identify a session set-up req= uest is to an emergency response center Done A Standards Track RFC describing how to route an emergency call based= on location information Done An Informational document describing the Mapping Protocol Architectur= e Done Submit 'Location Hiding: Problem Statement and Requirements' to the I= ESG for consideration as an Informational RFC. Done Submit 'Framework for Emergency Calling using Internet Multimedia' to= the IESG for consideration as an Informational RFC. Done Submit 'Best Current Practice for Communications Services in support = of Emergency Calling' to the IESG for consideration as a BCP document Done Submit 'LoST Extension for returning Boundary Information for Service= s' to the IESG for consideration as an Experimental RFC Done Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol= based Service Boundaries and Mapping Elements' to the IESG for considerati= on as an Experimental RFC Done Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG= for consideration as an Informational RFC Done Submit 'Extensions to the Emergency Services Architecture for deali= ng with Unauthenticated and Unauthorized Devices' to the IESG for considera= tion as a Standards Track RFC Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG f= or consideration as an Experimental RFC Dec 2013 - Submit a draft 'Policy for defining new service-identifying labels' to the IESG for consideration as BCP Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC Dec 2014 - Submit a draft 'Policy based routing in Emergency Services' to the IESG for consideration as a Standards Track RFC From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of G= unnar Hellstrom Sent: Sunday, October 13, 2013 4:53 PM To: Gellens, Randall Cc: ecrit@ietf.org Subject: Re: [Ecrit] Charter & Milestones update - Comments sought An addition could be made to this sentence: "Further, it must be possible for multiple delegations within a jurisdictio= n to be handled independently, as call routing for specific emergency types= may be handled independently." To "Further, it must be possible for multiple delegations within a jurisdictio= n to be handled independently, as call routing for specific emergency types= , media types, language contents etc. may be routed differently depending = on established policies and availability." And in the goals list include: xxx 2014 - Submit a draft 'Policy based routing in Emergency Services' to the IESG for consideration as a Standards Track RFC Regards Gunnar ________________________________ Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se> +46708204288 On 2013-10-13 19:22, Gellens, Randall wrote: The current NENA document on policy-based routing only deals with legacy ca= pabilities (that is, call diversion/exception handling). The NENA group in= tends to produce a version two that covers NG9-1-1 (NENA i3) capabilities w= ith the enhancements for call processing including media and other needs. ________________________________________ From: ecrit-bounces@ietf.org<mailto:ecrit-bounces@ietf.org> [ecrit-bounces@= ietf.org<mailto:ecrit-bounces@ietf.org>] on behalf of Hannes Tschofenig [ha= nnes.tschofenig@gmx.net<mailto:hannes.tschofenig@gmx.net>] Sent: Sunday, October 13, 2013 9:50 AM To: Gunnar Hellstrom Cc: ecrit@ietf.org<mailto:ecrit@ietf.org> Subject: Re: [Ecrit] Charter & Milestones update - Comments sought Hi Gunnar, that's fine with me but where do you want to add this remark in the charter text Roger proposed? Also, do we have any specific document in progress that is impacted by policy based routing? Ciao Hannes On 13.10.2013 19:37, Gunnar Hellstrom wrote: Hi, Policy based routing was once said to enable routing based on for example media requirements and capabilities to specific PSAPs equipped or educated for such calls. In latest NENA spec for policy based routing, only PSAP availability is mentioned as reason to route. I do not remember that we have anything sufficiently explicit from IETF on this topic, and suggest to include it in the goals. Thanks, Gunnar ------------------------------------------------------------------------ Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se> +46708204288 On 2013-10-13 11:59, Hannes Tschofenig wrote: Hi Roger, thanks for working on the updated charter text. The text is fine for me; I only have a few minor suggestions. On 04.10.2013 21:18, Roger Marshall wrote: The ECRIT working group agreed that the chairs would propose updated language to the wg charter, along with milestone data changes. Compare this to the original charter found at: http://tools.ietf.org/wg/ecrit/charters. Please send your comments to the list, whether in favor, or with alternative wording and/or dates. Regards, Roger Marshall/Marc Linsner ECRIT Chairs ECRIT charter (w/proposed revisions): Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems Mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group will describe where and how these mechanisms may be used. The group will show how the availability of location data and call routing information at different steps in the call session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used in this document, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. I would omit this last sentence. I also believe that the term "document" isn't appropriate here. Beyond human initiated emergency call request mechanisms, this group will develop new methods to request emergency assistance, such as sensor initiated emergency requests, and additional processes specified that address topics such as authentication of location, service URN definition and use, augmented information that could assist emergency call takers or responders. s/"authentication of location"/"trustworthy location" Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA and ETSI EMTEL, any solution presented must be useful You should add "EENA" and "3GPP" here as well and replace ETSI EMTEL with "ETSI" since we are now dealing also with other groups in ETSI in addition to EMTEL. regardless of jurisdiction, and it must be possible to use without requiring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, as call routing for specific emergency types may be handled independently. This working group cares about privacy and security concerns, and will address them within its documents. Milestones w/revised status/dates, as proposed Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Dec 2013 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration I thought that this document has been sent to the IESG already. as a Standards Track RFC Dec 2013 - Submit a draft 'Policy for defining new service-identifying labels' to the IESG for consideration as BCP Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC I believe you should also list all other concluded documents as well (and mark them as done). Ciao Hannes CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org<mailto:Ecrit@ietf.org> https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org<mailto:Ecrit@ietf.org> https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org<mailto:Ecrit@ietf.org> https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org<mailto:Ecrit@ietf.org> https://www.ietf.org/mailman/listinfo/ecrit --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC486660SEAEXMB1telecomsy_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <!--[if !mso]><style>v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style><![endif]--><style><!-- /* Font Definitions */ @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif"; color:black;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New"; color:black;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif"; color:black;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; color:black;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif"; color:black;} span.EmailStyle21 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Based on text feedback fr= om the list, I’ve updated the Charter text and Milestones.  See = below.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">(I’ve also included= an attached file for redlined changes)<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">ECRIT charter (as revised):<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">Description of Working Group:<o:p></o:p></sp= an></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    In a number of areas, the= public switched telephone network (PSTN) has<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    been configured to recogn= ize an explicitly specified number (usually<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    one that is short and eas= ily memorized) as a request for emergency<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    services.  These num= bers (e.g., 911, 112) are related to an emergency<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    service context and depen= d on a broad, regional configuration of<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    service contact methods a= nd a geographically-constrained approach for<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    service delivery.  T= hese calls are intended to be delivered to special<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    call centers equipped to = manage emergency response. Successful<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    delivery of an emergency = service call within those systems requires<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    an association of both th= e physical location of the originating device <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    along with appropria= te call routing to an emergency service center.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    Calls placed using Intern= et technologies do not use the same systems<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    Mentioned above to achiev= e those same goals, and the common use of <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    overlay networks and= tunnels (either as VPNs or for mobility) makes <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    meeting these goals = even more challenging.  There are, however, <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    Internet technologie= s available to manage location and to perform call <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    routing.  This = working group will describe where and how these mechanisms <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    may be used. The gro= up will show how the availability of location data <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    and call routing inf= ormation at different steps in the call session <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    setup would enable c= ommunication between a user and a relevant emergency <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    response center. Tho= ugh the term "call routing" is used, <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    it should be underst= ood that some of the mechanisms which will be<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    described might be used t= o enable other types of media streams. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    Beyond human initiated em= ergency call request mechanisms, this group will <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    develop new methods = to request emergency assistance, such as sensor <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    initiated emergency = requests, and additional processes specified that <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    address topics such = as authentication of location, service URN definition <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    and use, augmented i= nformation that could assist emergency call takers or <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    responders.<o:p></o:= p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">  <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    Explicitly outside t= he scope of this group is the question of<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    pre-emption or prioritiza= tion of emergency services traffic. This<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    group is considering emer= gency services calls which might be made by<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    any user of the Internet,= as opposed to government or military<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    services that may impose = very different authentication and routing<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    requirements.<o:p></o:p><= /span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    While this group anticipa= tes a close working relationship with groups<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    such as NENA, EENA, 3GPP,= and ETSI , any solution presented must be <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    general enough to be= potentially useful in or across multiple regions <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    or jurisdictions, an= d it must be possible to use without requiring a<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    single, central authority= .  Further, it must be possible for multiple <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    delegations within a= jurisdiction to be handled independently, things <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    such as call routing= for specific emergency types, media types, language <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    contents, etc., = ; may be routed differently depending on established <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    policies and availab= ility.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    This working group cares = about privacy and security concerns, and will<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New";color:#1F497D">    address them within its d= ocuments.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">Also, dependent on the ab= ove text, Gunnar has suggested the addition of the <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">following milestone:<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <pre>xxx 2014 - Submit a draft 'Policy based routing in Emergency Services'= <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>to the IESG for consideration as a Standards Track RFC<o:p></o:p></pre= > <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D">The complete Milestone li= st (as revised):<o:p></o:p></span></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done  Informational RFC containing terminology defini= tions and the requirements<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done  An Informational document describing the threat= s and security considerations<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done  A Standards Track RFC describing how to identif= y a session set-up request is to an emergency response center<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done  A Standards Track RFC describing how to route a= n emergency call based on location information<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done  An Informational document describing the Mappin= g Protocol Architecture<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done  Submit 'Location Hiding: Problem Statement and = Requirements' to the IESG for consideration as an Informational RFC.<o:p></= o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done  Submit 'Framework for Emergency Calling using I= nternet Multimedia' to the IESG for consideration as an Informational RFC.<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done  Submit 'Best Current Practice for Communication= s Services in support of Emergency Calling' to the IESG for consideration a= s a BCP document<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done  Submit 'LoST Extension for returning Boundary I= nformation for Services' to the IESG for consideration as an Experimental R= FC<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done  Submit 'Synchronizing Location-to-Service Trans= lation (LoST) Protocol based Service Boundaries and Mapping Elements' to th= e IESG for consideration as an Experimental RFC<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done    Submit 'Public Safety Answering Poi= nt (PSAP) Callbacks' to the IESG  for consideration as an Informationa= l RFC<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Done    Submit 'Extensions to the Emergency= Services Architecture for dealing with Unauthenticated and Unauthorized De= vices' to the IESG for consideration as a Standards Track RFC<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Nov 2013 - Submit 'Trustworthy Location Information' to th= e IESG for<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">consideration as an Informational RFC<o:p></o:p></span></p= > <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Dec 2013 - Submit 'Additional Data related to a Call for E= mergency Call <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Purposes' to the IESG for consideration as a Standards Tra= ck RFC<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Da= ta-Only<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Emergency Alerts using the Session Initiation Protocol (SI= P)' to the IESG for consideration as an<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Experimental RFC<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Dec 2013 - Submit a draft 'Policy for defining new service= -identifying<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">labels' to the IESG for consideration as BCP<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Mar 2014 - Submit 'Using Imprecise Location for Emergency = Call Routing'<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">to the IESG for consideration as an Informational RFC<o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">Dec 2013 - Submit a draft 'URN For Country Specific Emerge= ncy Services'<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">to the IESG for consideration as a Standards Track RFC<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <pre>Dec 2014 - Submit a draft 'Policy based routing in Emergency Services'= <o:p></o:p></pre> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New"">to the IESG for consideration as a Standards Track RFC<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Co= urier New""><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca= libri","sans-serif";color:#1F497D"><o:p> </o:p></span><= /p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:"= ;Tahoma","sans-serif";color:windowtext">From:</span></b><spa= n style=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif= ";color:windowtext"> ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf= .org] <b>On Behalf Of </b>Gunnar Hellstrom<br> <b>Sent:</b> Sunday, October 13, 2013 4:53 PM<br> <b>To:</b> Gellens, Randall<br> <b>Cc:</b> ecrit@ietf.org<br> <b>Subject:</b> Re: [Ecrit] Charter & Milestones update - Comments soug= ht<o:p></o:p></span></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <p class=3D"MsoNormal">An addition could be made to this sentence:<br> <br> "Further, it must be possible for multiple delegations within a jurisd= iction to be handled independently, as call routing for specific emergency = types may be handled independently."<br> <br> To<br> <br> "Further, it must be possible for multiple delegations within a jurisd= iction to be handled independently, as call routing for specific emergency = types, media types, language contents etc.  may be routed differently = depending on established policies and availability."<br> <br> And in the goals list include:<br> <br> <br> <o:p></o:p></p> <pre>xxx 2014 - Submit a draft 'Policy based routing in Emergency Services'= <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>to the IESG for consideration as a Standards Track RFC<o:p></o:p></pre= > <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br> Regards<br> <br> Gunnar<br> <br> <o:p></o:p></p> <div> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> <p class=3D"MsoNormal">Gunnar Hellstr=F6m<br> Omnitor<br> <a href=3D"mailto:gunnar.hellstrom@omnitor.se">gunnar.hellstrom@omnitor.se<= /a><br> +46708204288<o:p></o:p></p> </div> <p class=3D"MsoNormal">On 2013-10-13 19:22, Gellens, Randall wrote:<o:p></o= :p></p> </div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <pre>The current NENA document on policy-based routing only deals with lega= cy capabilities (that is, call diversion/exception handling).  The NEN= A group intends to produce a version two that covers NG9-1-1 (NENA i3) capa= bilities with the enhancements for call processing including media and othe= r needs.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>________________________________________<o:p></o:p></pre> <pre>From: <a href=3D"mailto:ecrit-bounces@ietf.org">ecrit-bounces@ietf.org= </a> [<a href=3D"mailto:ecrit-bounces@ietf.org">ecrit-bounces@ietf.org</a>]= on behalf of Hannes Tschofenig [<a href=3D"mailto:hannes.tschofenig@gmx.ne= t">hannes.tschofenig@gmx.net</a>]<o:p></o:p></pre> <pre>Sent: Sunday, October 13, 2013 9:50 AM<o:p></o:p></pre> <pre>To: Gunnar Hellstrom<o:p></o:p></pre> <pre>Cc: <a href=3D"mailto:ecrit@ietf.org">ecrit@ietf.org</a><o:p></o:p></p= re> <pre>Subject: Re: [Ecrit] Charter & Milestones update - Comments sought= <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Hi Gunnar,<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>that's fine with me but where do you want to add this remark in the<o:= p></o:p></pre> <pre>charter text Roger proposed?<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Also, do we have any specific document in progress that is impacted by= <o:p></o:p></pre> <pre>policy based routing?<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Ciao<o:p></o:p></pre> <pre>Hannes<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre>On 13.10.2013 19:37, Gunnar Hellstrom wrote:<o:p></o:p></pre> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <pre>Hi,<o:p></o:p></pre> <pre>Policy based routing was once said to enable routing based on for<o:p>= </o:p></pre> <pre>example media requirements and capabilities to specific PSAPs equipped= <o:p></o:p></pre> <pre>or educated for such calls.<o:p></o:p></pre> <pre>In latest NENA spec for policy based routing, only PSAP availability i= s<o:p></o:p></pre> <pre>mentioned as reason to route.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>I do not remember that we have anything sufficiently explicit from IET= F<o:p></o:p></pre> <pre>on this topic, and suggest to include it in the goals.<o:p></o:p></pre= > <pre><o:p> </o:p></pre> <pre>Thanks,<o:p></o:p></pre> <pre>Gunnar<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre>----------------------------------------------------------------------= --<o:p></o:p></pre> <pre>Gunnar Hellstr=F6m<o:p></o:p></pre> <pre>Omnitor<o:p></o:p></pre> <pre><a href=3D"mailto:gunnar.hellstrom@omnitor.se">gunnar.hellstrom@omnito= r.se</a><o:p></o:p></pre> <pre>+46708204288<o:p></o:p></pre> <pre>On 2013-10-13 11:59, Hannes Tschofenig wrote:<o:p></o:p></pre> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <pre>Hi Roger,<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>thanks for working on the updated charter text.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>The text is fine for me; I only have a few minor suggestions.<o:p></o:= p></pre> <pre><o:p> </o:p></pre> <pre>On 04.10.2013 21:18, Roger Marshall wrote:<o:p></o:p></pre> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <pre>The ECRIT working group agreed that the chairs would propose updated<o= :p></o:p></pre> <pre>language to the wg charter, along with milestone data changes.<o:p></o= :p></pre> <pre><o:p> </o:p></pre> <pre>Compare this to the original charter found at:<o:p></o:p></pre> <pre><a href=3D"http://tools.ietf.org/wg/ecrit/charters">http://tools.ietf.= org/wg/ecrit/charters</a>.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Please send your comments to the list, whether in favor, or with<o:p><= /o:p></pre> <pre>alternative wording and/or dates.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Regards,<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Roger Marshall/Marc Linsner<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>ECRIT Chairs<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>ECRIT charter (w/proposed revisions):<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Description of Working Group:<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>In a number of areas, the public switched telephone network (PSTN) has= <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>been configured to recognize an explicitly specified number (usually<o= :p></o:p></pre> <pre><o:p> </o:p></pre> <pre>one that is short and easily memorized) as a request for emergency<o:p= ></o:p></pre> <pre><o:p> </o:p></pre> <pre>services. These numbers (e.g., 911, 112) are related to an emergency<o= :p></o:p></pre> <pre><o:p> </o:p></pre> <pre>service context and depend on a broad, regional configuration of<o:p><= /o:p></pre> <pre><o:p> </o:p></pre> <pre>service contact methods and a geographically-constrained approach for<= o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>service delivery. These calls are intended to be delivered to special<= o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>call centers equipped to manage emergency response. Successful<o:p></o= :p></pre> <pre><o:p> </o:p></pre> <pre>delivery of an emergency service call within those systems requires<o:= p></o:p></pre> <pre><o:p> </o:p></pre> <pre>an association of both the physical location of the originating device= <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>along with appropriate call routing to an emergency service center.<o:= p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Calls placed using Internet technologies do not use the same systems<o= :p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Mentioned above to achieve those same goals, and the common use of<o:p= ></o:p></pre> <pre><o:p> </o:p></pre> <pre>overlay networks and tunnels (either as VPNs or for mobility) makes<o:= p></o:p></pre> <pre><o:p> </o:p></pre> <pre>meeting these goals even more challenging. There are, however,<o:p></o= :p></pre> <pre><o:p> </o:p></pre> <pre>Internet technologies available to manage location and to perform call= <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>routing. This working group will describe where and how these mechanis= ms<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>may be used. The group will show how the availability of location data= <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>and call routing information at different steps in the call session<o:= p></o:p></pre> <pre><o:p> </o:p></pre> <pre>setup would enable communication between a user and a relevant emergen= cy<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>response center. Though the term "call routing" is used in t= his<o:p></o:p></pre> <pre>document,<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>it should be understood that some of the mechanisms which will be<o:p>= </o:p></pre> <pre><o:p> </o:p></pre> <pre>described might be used to enable other types of media streams. Video<= o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>and text messaging, for example, might be used to request emergency<o:= p></o:p></pre> <pre><o:p> </o:p></pre> <pre>services.<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>I would omit this last sentence. I also believe that the term<o:p></o:= p></pre> <pre>"document" isn't appropriate here.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <pre><o:p> </o:p></pre> <pre>Beyond human initiated emergency call request mechanisms, this group<o= :p></o:p></pre> <pre>will<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>develop new methods to request emergency assistance, such as sensor<o:= p></o:p></pre> <pre><o:p> </o:p></pre> <pre>initiated emergency requests, and additional processes specified that<= o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>address topics such as authentication of location, service URN<o:p></o= :p></pre> <pre>definition<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>and use, augmented information that could assist emergency call<o:p></= o:p></pre> <pre>takers or<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>responders.<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>s/"authentication of location"/"trustworthy location&qu= ot;<o:p></o:p></pre> <pre><o:p> </o:p></pre> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <pre><o:p> </o:p></pre> <pre>Explicitly outside the scope of this group is the question of<o:p></o:= p></pre> <pre><o:p> </o:p></pre> <pre>pre-emption or prioritization of emergency services traffic. This<o:p>= </o:p></pre> <pre><o:p> </o:p></pre> <pre>group is considering emergency services calls which might be made by<o= :p></o:p></pre> <pre><o:p> </o:p></pre> <pre>any user of the Internet, as opposed to government or military<o:p></o= :p></pre> <pre><o:p> </o:p></pre> <pre>services that may impose very different authentication and routing<o:p= ></o:p></pre> <pre><o:p> </o:p></pre> <pre>requirements.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>While this group anticipates a close working relationship with groups<= o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>such as NENA and ETSI EMTEL, any solution presented must be useful<o:p= ></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>You should add "EENA" and "3GPP" here as well and = replace ETSI EMTEL<o:p></o:p></pre> <pre>with "ETSI" since we are now dealing also with other groups = in ETSI in<o:p></o:p></pre> <pre>addition to EMTEL.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <pre><o:p> </o:p></pre> <pre>regardless of jurisdiction, and it must be possible to use without<o:p= ></o:p></pre> <pre>requiring a<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>single, central authority. Further, it must be possible for multiple<o= :p></o:p></pre> <pre><o:p> </o:p></pre> <pre>delegations within a jurisdiction to be handled independently, as call= <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>routing for specific emergency types may be handled independently.<o:p= ></o:p></pre> <pre><o:p> </o:p></pre> <pre>This working group cares about privacy and security concerns, and will= <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>address them within its documents.<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Milestones w/revised status/dates, as proposed<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Done - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the<= o:p></o:p></pre> <pre>IESG<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>for consideration as an Informational RFC<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Nov 2013 - Submit 'Trustworthy Location Information' to the IESG for<o= :p></o:p></pre> <pre><o:p> </o:p></pre> <pre>consideration as an Informational RFC<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Dec 2013 - Submit 'Additional Data related to a Call for Emergency Cal= l<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Purposes' to the IESG for consideration as a Standards Track RFC<o:p><= /o:p></pre> <pre><o:p> </o:p></pre> <pre>Nov 2013 - Submit 'Common Alerting Protocol (CAP) based Data-Only<o:p>= </o:p></pre> <pre><o:p> </o:p></pre> <pre>Emergency Alerts using the Session Initiation Protocol (SIP)' to the<o= :p></o:p></pre> <pre>IESG for consideration as an<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Experimental RFC<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Dec 2013 - Submit 'Extensions to the Emergency Services Architecture f= or<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>dealing with Unauthenticated and Unauthorized Devices' to the IESG for= <o:p></o:p></pre> <pre>consideration<o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>I thought that this document has been sent to the IESG already.<o:p></= o:p></pre> <pre><o:p> </o:p></pre> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <pre><o:p> </o:p></pre> <pre>as a Standards Track RFC<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Dec 2013 - Submit a draft 'Policy for defining new service-identifying= <o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>labels' to the IESG for consideration as BCP<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Mar 2014 - Submit 'Using Imprecise Location for Emergency Call Routing= '<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>to the IESG for consideration as an Informational RFC<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>Dec 2013 - Submit a draft 'URN For Country Specific Emergency Services= '<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre>to the IESG for consideration as a Standards Track RFC<o:p></o:p></pre= > </blockquote> <pre><o:p> </o:p></pre> <pre>I believe you should also list all other concluded documents as well<o= :p></o:p></pre> <pre>(and mark them as done).<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre>Ciao<o:p></o:p></pre> <pre>Hannes<o:p></o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <pre><o:p> </o:p></pre> <pre>CONFIDENTIALITY NOTICE: The information contained in this message may = be<o:p></o:p></pre> <pre>privileged and/or confidential. If you are not the intended recipient,= <o:p></o:p></pre> <pre>or responsible for delivering this message to the intended recipient,<= o:p></o:p></pre> <pre>any review, forwarding, dissemination, distribution or copying of this= <o:p></o:p></pre> <pre>communication or any attachment(s) is strictly prohibited. If you have= <o:p></o:p></pre> <pre>received this message in error, please notify the sender immediately,<= o:p></o:p></pre> <pre>and delete it and all attachments from your computer and network.<o:p>= </o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre>_______________________________________________<o:p></o:p></pre> <pre>Ecrit mailing list<o:p></o:p></pre> <pre><a href=3D"mailto:Ecrit@ietf.org">Ecrit@ietf.org</a><o:p></o:p></pre> <pre><a href=3D"https://www.ietf.org/mailman/listinfo/ecrit">https://www.ie= tf.org/mailman/listinfo/ecrit</a><o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>_______________________________________________<o:p></o:p></pre> <pre>Ecrit mailing list<o:p></o:p></pre> <pre><a href=3D"mailto:Ecrit@ietf.org">Ecrit@ietf.org</a><o:p></o:p></pre> <pre><a href=3D"https://www.ietf.org/mailman/listinfo/ecrit">https://www.ie= tf.org/mailman/listinfo/ecrit</a><o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre><o:p> </o:p></pre> <pre>_______________________________________________<o:p></o:p></pre> <pre>Ecrit mailing list<o:p></o:p></pre> <pre><a href=3D"mailto:Ecrit@ietf.org">Ecrit@ietf.org</a><o:p></o:p></pre> <pre><a href=3D"https://www.ietf.org/mailman/listinfo/ecrit">https://www.ie= tf.org/mailman/listinfo/ecrit</a><o:p></o:p></pre> </blockquote> <pre><o:p> </o:p></pre> <pre>_______________________________________________<o:p></o:p></pre> <pre>Ecrit mailing list<o:p></o:p></pre> <pre><a href=3D"mailto:Ecrit@ietf.org">Ecrit@ietf.org</a><o:p></o:p></pre> <pre><a href=3D"https://www.ietf.org/mailman/listinfo/ecrit">https://www.ie= tf.org/mailman/listinfo/ecrit</a><o:p></o:p></pre> </blockquote> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC486660SEAEXMB1telecomsy_-- --_004_FBD5AAFFD0978846BF6D3FAB4C892ACC486660SEAEXMB1telecomsy_ Content-Type: application/octet-stream; name="ECRIT_Charter_revised_2013102104_3.mht" Content-Description: ECRIT_Charter_revised_2013102104_3.mht Content-Disposition: attachment; filename="ECRIT_Charter_revised_2013102104_3.mht"; size=39366; creation-date="Mon, 21 Oct 2013 22:28:06 GMT"; modification-date="Mon, 21 Oct 2013 22:28:07 GMT" Content-Transfer-Encoding: base64 TUlNRS1WZXJzaW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L3JlbGF0ZWQ7IGJvdW5k YXJ5PSItLS0tPV9OZXh0UGFydF8wMUNFQ0U3Mi4yNDQxRDFEMCINCg0KVGhpcyBkb2N1bWVudCBp cyBhIFNpbmdsZSBGaWxlIFdlYiBQYWdlLCBhbHNvIGtub3duIGFzIGEgV2ViIEFyY2hpdmUgZmls ZS4gIElmIHlvdSBhcmUgc2VlaW5nIHRoaXMgbWVzc2FnZSwgeW91ciBicm93c2VyIG9yIGVkaXRv ciBkb2Vzbid0IHN1cHBvcnQgV2ViIEFyY2hpdmUgZmlsZXMuICBQbGVhc2UgZG93bmxvYWQgYSBi cm93c2VyIHRoYXQgc3VwcG9ydHMgV2ViIEFyY2hpdmUsIHN1Y2ggYXMgV2luZG93c64gSW50ZXJu ZXQgRXhwbG9yZXKuLg0KDQotLS0tLS09X05leHRQYXJ0XzAxQ0VDRTcyLjI0NDFEMUQwDQpDb250 ZW50LUxvY2F0aW9uOiBmaWxlOi8vL0M6LzY3MjhEQzEzL0VDUklUX0NoYXJ0ZXJfcmV2aXNlZF8y MDEzMTAyMTA0XzMuaHRtDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRh YmxlDQpDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD0id2luZG93cy0xMjUyIg0KDQo8 aHRtbCB4bWxuczp2PTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIg0KeG1sbnM6bz0z RCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiDQp4bWxuczp3PTNEInVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiDQp4bWxuczptPTNEImh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCINCnhtbG5zPTNEImh0dHA6 Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 M0RDb250ZW50LVR5cGUgY29udGVudD0zRCJ0ZXh0L2h0bWw7IGNoYXJzZXQ9M0R3aW5kb3dzLTEy NT0NCjIiPg0KPG1ldGEgbmFtZT0zRFByb2dJZCBjb250ZW50PTNEV29yZC5Eb2N1bWVudD4NCjxt ZXRhIG5hbWU9M0RHZW5lcmF0b3IgY29udGVudD0zRCJNaWNyb3NvZnQgV29yZCAxNCI+DQo8bWV0 YSBuYW1lPTNET3JpZ2luYXRvciBjb250ZW50PTNEIk1pY3Jvc29mdCBXb3JkIDE0Ij4NCjxsaW5r IHJlbD0zREZpbGUtTGlzdCBocmVmPTNEIkVDUklUX0NoYXJ0ZXJfcmV2aXNlZF8yMDEzMTAyMTA0 XzNfZmlsZXMvZmlsZT0NCmxpc3QueG1sIj4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxv OkRvY3VtZW50UHJvcGVydGllcz4NCiAgPG86QXV0aG9yPlJvZ2VyIE1hcnNoYWxsPC9vOkF1dGhv cj4NCiAgPG86VGVtcGxhdGU+Tm9ybWFsPC9vOlRlbXBsYXRlPg0KICA8bzpMYXN0QXV0aG9yPlJv Z2VyIE1hcnNoYWxsPC9vOkxhc3RBdXRob3I+DQogIDxvOlJldmlzaW9uPjI8L286UmV2aXNpb24+ DQogIDxvOlRvdGFsVGltZT43NjwvbzpUb3RhbFRpbWU+DQogIDxvOkNyZWF0ZWQ+MjAxMy0xMC0y MVQyMjoyODowMFo8L286Q3JlYXRlZD4NCiAgPG86TGFzdFNhdmVkPjIwMTMtMTAtMjFUMjI6Mjg6 MDBaPC9vOkxhc3RTYXZlZD4NCiAgPG86UGFnZXM+MTwvbzpQYWdlcz4NCiAgPG86V29yZHM+NTM1 PC9vOldvcmRzPg0KICA8bzpDaGFyYWN0ZXJzPjMwNTY8L286Q2hhcmFjdGVycz4NCiAgPG86Q29t cGFueT5UZWxlY29tbXVuaWNhdGlvbiBTeXN0ZW1zLCBJTkMuPC9vOkNvbXBhbnk+DQogIDxvOkxp bmVzPjI1PC9vOkxpbmVzPg0KICA8bzpQYXJhZ3JhcGhzPjc8L286UGFyYWdyYXBocz4NCiAgPG86 Q2hhcmFjdGVyc1dpdGhTcGFjZXM+MzU4NDwvbzpDaGFyYWN0ZXJzV2l0aFNwYWNlcz4NCiAgPG86 VmVyc2lvbj4xNC4wMDwvbzpWZXJzaW9uPg0KIDwvbzpEb2N1bWVudFByb3BlcnRpZXM+DQogPG86 T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCiAgPG86QWxsb3dQTkcvPg0KIDwvbzpPZmZpY2VEb2N1 bWVudFNldHRpbmdzPg0KPC94bWw+PCFbZW5kaWZdLS0+DQo8bGluayByZWw9M0R0aGVtZURhdGEN CmhyZWY9M0QiRUNSSVRfQ2hhcnRlcl9yZXZpc2VkXzIwMTMxMDIxMDRfM19maWxlcy90aGVtZWRh dGEudGhteCI+DQo8bGluayByZWw9M0Rjb2xvclNjaGVtZU1hcHBpbmcNCmhyZWY9M0QiRUNSSVRf Q2hhcnRlcl9yZXZpc2VkXzIwMTMxMDIxMDRfM19maWxlcy9jb2xvcnNjaGVtZW1hcHBpbmcueG1s Ij4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDx3OldvcmREb2N1bWVudD4NCiAgPHc6U3Bl bGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0KICA8dzpHcmFtbWFyU3RhdGU+Q2xl YW48L3c6R3JhbW1hclN0YXRlPg0KICA8dzpUcmFja1JldmlzaW9ucy8+DQogIDx3OlRyYWNrTW92 ZXM+ZmFsc2U8L3c6VHJhY2tNb3Zlcz4NCiAgPHc6VHJhY2tGb3JtYXR0aW5nLz4NCiAgPHc6UHVu Y3R1YXRpb25LZXJuaW5nLz4NCiAgPHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQogIDx3OlNh dmVJZlhNTEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCiAgPHc6SWdub3JlTWl4 ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCiAgPHc6QWx3YXlzU2hvd1Bs YWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KICA8dzpE b05vdFByb21vdGVRRi8+DQogIDx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlkVGhlbWVPdGhl cj4NCiAgPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVBc2lhbj4NCiAgPHc6TGlk VGhlbWVDb21wbGV4U2NyaXB0PlgtTk9ORTwvdzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+DQogIDx3 OkNvbXBhdGliaWxpdHk+DQogICA8dzpCcmVha1dyYXBwZWRUYWJsZXMvPg0KICAgPHc6U25hcFRv R3JpZEluQ2VsbC8+DQogICA8dzpXcmFwVGV4dFdpdGhQdW5jdC8+DQogICA8dzpVc2VBc2lhbkJy ZWFrUnVsZXMvPg0KICAgPHc6RG9udEdyb3dBdXRvZml0Lz4NCiAgIDx3OlNwbGl0UGdCcmVha0Fu ZFBhcmFNYXJrLz4NCiAgIDx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQogICA8dzpEb250Rmxp cE1pcnJvckluZGVudHMvPg0KICAgPHc6T3ZlcnJpZGVUYWJsZVN0eWxlSHBzLz4NCiAgPC93OkNv bXBhdGliaWxpdHk+DQogIDx3OkJyb3dzZXJMZXZlbD5NaWNyb3NvZnRJbnRlcm5ldEV4cGxvcmVy NDwvdzpCcm93c2VyTGV2ZWw+DQogIDxtOm1hdGhQcj4NCiAgIDxtOm1hdGhGb250IG06dmFsPTNE IkNhbWJyaWEgTWF0aCIvPg0KICAgPG06YnJrQmluIG06dmFsPTNEImJlZm9yZSIvPg0KICAgPG06 YnJrQmluU3ViIG06dmFsPTNEIiYjNDU7LSIvPg0KICAgPG06c21hbGxGcmFjIG06dmFsPTNEIm9m ZiIvPg0KICAgPG06ZGlzcERlZi8+DQogICA8bTpsTWFyZ2luIG06dmFsPTNEIjAiLz4NCiAgIDxt OnJNYXJnaW4gbTp2YWw9M0QiMCIvPg0KICAgPG06ZGVmSmMgbTp2YWw9M0QiY2VudGVyR3JvdXAi Lz4NCiAgIDxtOndyYXBJbmRlbnQgbTp2YWw9M0QiMTQ0MCIvPg0KICAgPG06aW50TGltIG06dmFs PTNEInN1YlN1cCIvPg0KICAgPG06bmFyeUxpbSBtOnZhbD0zRCJ1bmRPdnIiLz4NCiAgPC9tOm1h dGhQcj48L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRlPTNEImZhbHNlIiBEZWZV bmhpZGVXaGVuVXNlZD0zRCJ0cnVlIg0KICBEZWZTZW1pSGlkZGVuPTNEInRydWUiIERlZlFGb3Jt YXQ9M0QiZmFsc2UiIERlZlByaW9yaXR5PTNEIjk5Ig0KICBMYXRlbnRTdHlsZUNvdW50PTNEIjI2 NyI+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjAiIFNl bWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgUUZvcm1hdD0z RCJ0cnVlIiBOYW1lPTNEIk5vcm1hbCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZh bHNlIiBQcmlvcml0eT0zRCI5IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9M0QiZmFsc2UiIFFGb3JtYXQ9M0QidHJ1ZSIgTmFtZT0zRCJoZWFkaW5nIDEiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiOSIgUUZvcm1hdD0zRCJ0 cnVlIiBOYW1lPTNEIj0NCmhlYWRpbmcgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNE ImZhbHNlIiBQcmlvcml0eT0zRCI5IiBRRm9ybWF0PTNEInRydWUiIE5hbWU9M0QiPQ0KaGVhZGlu ZyAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjki IFFGb3JtYXQ9M0QidHJ1ZSIgTmFtZT0zRCI9DQpoZWFkaW5nIDQiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiOSIgUUZvcm1hdD0zRCJ0cnVlIiBOYW1l PTNEIj0NCmhlYWRpbmcgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQ cmlvcml0eT0zRCI5IiBRRm9ybWF0PTNEInRydWUiIE5hbWU9M0QiPQ0KaGVhZGluZyA2Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjkiIFFGb3JtYXQ9 M0QidHJ1ZSIgTmFtZT0zRCI9DQpoZWFkaW5nIDciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiOSIgUUZvcm1hdD0zRCJ0cnVlIiBOYW1lPTNEIj0NCmhl YWRpbmcgOCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0z RCI5IiBRRm9ybWF0PTNEInRydWUiIE5hbWU9M0QiPQ0KaGVhZGluZyA5Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjM5IiBOYW1lPTNEInRvYyAxIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjM5IiBOYW1l PTNEInRvYyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5 PTNEIjM5IiBOYW1lPTNEInRvYyAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFs c2UiIFByaW9yaXR5PTNEIjM5IiBOYW1lPTNEInRvYyA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjM5IiBOYW1lPTNEInRvYyA1Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjM5IiBOYW1lPTNEInRvYyA2 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjM5IiBO YW1lPTNEInRvYyA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9y aXR5PTNEIjM5IiBOYW1lPTNEInRvYyA4Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Qi ZmFsc2UiIFByaW9yaXR5PTNEIjM5IiBOYW1lPTNEInRvYyA5Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjM1IiBRRm9ybWF0PTNEInRydWUiIE5hbWU9 M0Q9DQoiY2FwdGlvbiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlv cml0eT0zRCIxMCIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZh bHNlIiBRRm9ybWF0PTNEInRydWUiIE5hbWU9M0QiVGl0bGUiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiMSIgTmFtZT0zRCJEZWZhdWx0IFBhcmFncmFw aD0NCiBGb250Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5 PTNEIjExIiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2Ui IFFGb3JtYXQ9M0QidHJ1ZSIgTmFtZT0zRCJTdWJ0aXRsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCIyMiIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBRRm9ybWF0PTNEInRydWUiIE5hbWU9M0QiU3Ryb25n Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjIwIiBT ZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIFFGb3JtYXQ9 M0QidHJ1ZSIgTmFtZT0zRCJFbXBoYXNpcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNE ImZhbHNlIiBQcmlvcml0eT0zRCI1OSIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIlRhYmxlIEdyaWQiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0zRCJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiUGxhY2Vo bz0NCmxkZXIgVGV4dCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlv cml0eT0zRCIxIiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFs c2UiIFFGb3JtYXQ9M0QidHJ1ZSIgTmFtZT0zRCJObyBTcGFjaW5nIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjYwIiBTZW1pSGlkZGVuPTNEImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiTGlnaHQgU2hhZGluZyIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2MSIgU2VtaUhp ZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIkxpZ2h0 IExpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0Qi NjIiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFt ZT0zRCJMaWdodCBHcmlkIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFBy aW9yaXR5PTNEIjYzIiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0Qi ZmFsc2UiIE5hbWU9M0QiTWVkaXVtIFNoYWRpbmcgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2NCIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBTaGFkaW5nIDIiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjUiIFNlbWlIaWRkZW49 M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0gTGlz dCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjY2 IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9 M0QiTWVkaXVtIExpc3QgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQ cmlvcml0eT0zRCI2NyIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNE ImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBHcmlkIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjgiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0gR3JpZCAyIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjY5IiBTZW1pSGlkZGVuPTNEImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiTWVkaXVtIEdyaWQgMyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI3MCIgU2Vt aUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIkRh cmsgTGlzdCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0z RCI3MSIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBO YW1lPTNEIkNvbG9yZnVsIFNoYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJm YWxzZSIgUHJpb3JpdHk9M0QiNzIiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJDb2xvcmZ1bCBMaXN0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjczIiBTZW1pSGlkZGVuPTNEImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiQ29sb3JmdWwgR3JpZCIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2MCIgU2VtaUhpZGRl bj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIkxpZ2h0IFNo YWRpbmcgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJp b3JpdHk9M0QiNjEiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJm YWxzZSIgTmFtZT0zRCJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjYyIiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiTGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2MyIgU2VtaUhp ZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1 bSBTaGFkaW5nIDEgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxz ZSIgUHJpb3JpdHk9M0QiNjQiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjY1IiBTZW1pSGlkZGVuPTNE ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiTWVkaXVtIExpc3Qg MSBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJSZXZpc2lvPQ0KbiIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCIzNCIgU2VtaUhpZGRlbj0zRCJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBRRm9ybWF0PTNEInRydWUiIE5hbWU9M0QiTGlz dCBQYXJhZ3JhcGgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3Jp dHk9M0QiMjkiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxz ZSIgUUZvcm1hdD0zRCJ0cnVlIiBOYW1lPTNEIlF1b3RlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjMwIiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIFFGb3JtYXQ9M0QidHJ1ZSIgTmFtZT0zRCJJbnRlbnNl IFF1b3RlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNE IjY2IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5h bWU9M0QiTWVkaXVtIExpc3QgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PTNEImZhbHNlIiBQcmlvcml0eT0zRCI2NyIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBHcmlkIDEgQWNjZW50IDEiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjgiIFNlbWlIaWRk ZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0g R3JpZCAyIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFBy aW9yaXR5PTNEIjY5IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0Qi ZmFsc2UiIE5hbWU9M0QiTWVkaXVtIEdyaWQgMyBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI3MCIgU2VtaUhpZGRlbj0zRCJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIkRhcmsgTGlzdCBBY2NlbnQgMSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI3MSIgU2Vt aUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIkNv bG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJm YWxzZSIgUHJpb3JpdHk9M0QiNzIiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJDb2xvcmZ1bCBMaXN0IEFjY2VudCAxIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjczIiBTZW1pSGlkZGVuPTNE ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiQ29sb3JmdWwgR3Jp ZCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0 eT0zRCI2MCIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNl IiBOYW1lPTNEIkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjEiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJMaWdodCBMaXN0IEFjY2VudCAyIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjYyIiBTZW1pSGlk ZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiTGlnaHQg R3JpZCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlv cml0eT0zRCI2MyIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZh bHNlIiBOYW1lPTNEIk1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjQiIFNlbWlIaWRkZW49M0QiZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0gU2hhZGluZyAyIEFj Y2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNE IjY1IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5h bWU9M0QiTWVkaXVtIExpc3QgMSBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PTNEImZhbHNlIiBQcmlvcml0eT0zRCI2NiIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjciIFNlbWlIaWRk ZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0g R3JpZCAxIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFBy aW9yaXR5PTNEIjY4IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0Qi ZmFsc2UiIE5hbWU9M0QiTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2OSIgU2VtaUhpZGRlbj0zRCJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBHcmlkIDMgQWNjZW50 IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNzAi IFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0z RCJEYXJrIExpc3QgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxz ZSIgUHJpb3JpdHk9M0QiNzEiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0zRCJmYWxzZSIgTmFtZT0zRCJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAyIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjcyIiBTZW1pSGlkZGVuPTNE ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiQ29sb3JmdWwgTGlz dCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0 eT0zRCI3MyIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNl IiBOYW1lPTNEIkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjAiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJMaWdodCBTaGFkaW5nIEFjY2VudCAzIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjYxIiBTZW1p SGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiTGln aHQgTGlzdCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQ cmlvcml0eT0zRCI2MiIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNE ImZhbHNlIiBOYW1lPTNEIkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjMiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0gU2hhZGluZyAxIEFjY2Vu dCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjY0 IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9 M0QiTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PTNEImZhbHNlIiBQcmlvcml0eT0zRCI2NSIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjYiIFNlbWlIaWRk ZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0g TGlzdCAyIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFBy aW9yaXR5PTNEIjY3IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0Qi ZmFsc2UiIE5hbWU9M0QiTWVkaXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2OCIgU2VtaUhpZGRlbj0zRCJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBHcmlkIDIgQWNjZW50 IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjki IFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0z RCJNZWRpdW0gR3JpZCAzIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Qi ZmFsc2UiIFByaW9yaXR5PTNEIjcwIiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiRGFyayBMaXN0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjcxIiBTZW1pSGlkZGVuPTNEImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiQ29sb3JmdWwgU2hhZGlu ZyBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0 eT0zRCI3MiIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNl IiBOYW1lPTNEIkNvbG9yZnVsIExpc3QgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNzMiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjYwIiBTZW1p SGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiTGln aHQgU2hhZGluZyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNl IiBQcmlvcml0eT0zRCI2MSIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PTNEImZhbHNlIiBOYW1lPTNEIkxpZ2h0IExpc3QgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjIiIFNlbWlIaWRkZW49M0QiZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJMaWdodCBHcmlkIEFjY2VudCA0 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjYzIiBT ZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0Qi TWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNE ImZhbHNlIiBQcmlvcml0eT0zRCI2NCIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDQiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjUiIFNlbWlIaWRk ZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0g TGlzdCAxIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFBy aW9yaXR5PTNEIjY2IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0Qi ZmFsc2UiIE5hbWU9M0QiTWVkaXVtIExpc3QgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2NyIgU2VtaUhpZGRlbj0zRCJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBHcmlkIDEgQWNjZW50 IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjgi IFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0z RCJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Qi ZmFsc2UiIFByaW9yaXR5PTNEIjY5IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI3MCIgU2VtaUhpZGRlbj0z RCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIkRhcmsgTGlzdCBB Y2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0z RCI3MSIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBO YW1lPTNEIkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNzIiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjczIiBTZW1p SGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiQ29s b3JmdWwgR3JpZCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNl IiBQcmlvcml0eT0zRCI2MCIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PTNEImZhbHNlIiBOYW1lPTNEIkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjEiIFNlbWlIaWRkZW49M0QiZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJMaWdodCBMaXN0IEFjY2Vu dCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjYy IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9 M0QiTGlnaHQgR3JpZCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZh bHNlIiBQcmlvcml0eT0zRCI2MyIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5V c2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjQiIFNlbWlIaWRkZW49 M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0gU2hh ZGluZyAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFBy aW9yaXR5PTNEIjY1IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0Qi ZmFsc2UiIE5hbWU9M0QiTWVkaXVtIExpc3QgMSBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2NiIgU2VtaUhpZGRlbj0zRCJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBMaXN0IDIgQWNjZW50 IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjci IFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0z RCJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Qi ZmFsc2UiIFByaW9yaXR5PTNEIjY4IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiTWVkaXVtIEdyaWQgMiBBY2NlbnQgNSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2OSIgU2VtaUhpZGRlbj0z RCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBHcmlk IDMgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3Jp dHk9M0QiNzAiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxz ZSIgTmFtZT0zRCJEYXJrIExpc3QgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNzEiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA1Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjcyIiBTZW1p SGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiQ29s b3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNl IiBQcmlvcml0eT0zRCI3MyIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PTNEImZhbHNlIiBOYW1lPTNEIkNvbG9yZnVsIEdyaWQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjAiIFNlbWlIaWRkZW49M0QiZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJMaWdodCBTaGFkaW5nIEFj Y2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNE IjYxIiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5h bWU9M0QiTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNE ImZhbHNlIiBQcmlvcml0eT0zRCI2MiIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIkxpZ2h0IEdyaWQgQWNjZW50IDYiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjMiIFNlbWlIaWRkZW49M0Qi ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJNZWRpdW0gU2hhZGlu ZyAxIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9y aXR5PTNEIjY0IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFs c2UiIE5hbWU9M0QiTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2NSIgU2VtaUhpZGRlbj0zRCJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBMaXN0IDEgQWNjZW50 IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNjYi IFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0z RCJNZWRpdW0gTGlzdCAyIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Qi ZmFsc2UiIFByaW9yaXR5PTNEIjY3IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlvcml0eT0zRCI2OCIgU2VtaUhpZGRlbj0z RCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPTNEImZhbHNlIiBOYW1lPTNEIk1lZGl1bSBHcmlk IDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3Jp dHk9M0QiNjkiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxz ZSIgTmFtZT0zRCJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjcwIiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiRGFyayBMaXN0IEFjY2VudCA2Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjcxIiBTZW1pSGlk ZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIE5hbWU9M0QiQ29sb3Jm dWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNl IiBQcmlvcml0eT0zRCI3MiIgU2VtaUhpZGRlbj0zRCJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PTNEImZhbHNlIiBOYW1lPTNEIkNvbG9yZnVsIExpc3QgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiNzMiIFNlbWlIaWRkZW49M0QiZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgTmFtZT0zRCJDb2xvcmZ1bCBHcmlkIEFj Y2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNE IjE5IiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9M0QiZmFsc2UiIFFG b3JtYXQ9M0QidHJ1ZSIgTmFtZT0zRCJTdWJ0bGUgRW1waGFzaXMiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiMjEiIFNlbWlIaWRkZW49M0QiZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgUUZvcm1hdD0zRCJ0cnVlIiBOYW1lPTNEIklu dGVuc2UgRW1waGFzaXMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJp b3JpdHk9M0QiMzEiIFNlbWlIaWRkZW49M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJm YWxzZSIgUUZvcm1hdD0zRCJ0cnVlIiBOYW1lPTNEIlN1YnRsZSBSZWZlcmVuY2UiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0zRCJmYWxzZSIgUHJpb3JpdHk9M0QiMzIiIFNlbWlIaWRkZW49 M0QiZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0zRCJmYWxzZSIgUUZvcm1hdD0zRCJ0cnVlIiBO YW1lPTNEIkludGVuc2UgUmVmZXJlbmNlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0Qi ZmFsc2UiIFByaW9yaXR5PTNEIjMzIiBTZW1pSGlkZGVuPTNEImZhbHNlIg0KICAgVW5oaWRlV2hl blVzZWQ9M0QiZmFsc2UiIFFGb3JtYXQ9M0QidHJ1ZSIgTmFtZT0zRCJCb29rIFRpdGxlIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9M0QiZmFsc2UiIFByaW9yaXR5PTNEIjM3IiBOYW1lPTNE IkJpYmxpb2dyYXBoeSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPTNEImZhbHNlIiBQcmlv cml0eT0zRCIzOSIgUUZvcm1hdD0zRCJ0cnVlIiBOYW1lPTNEPQ0KIlRPQyBIZWFkaW5nIi8+DQog PC93OkxhdGVudFN0eWxlcz4NCjwveG1sPjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0KIC8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0K CW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxl Ow0KCW1zby1mb250LXNpZ25hdHVyZTotNTIwMDkyOTI5IDEwNzM3ODYxMTEgOSAwIDQxNSAwO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg NSA0IDQgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWls eTpzd2lzczsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6 LTUyMDA4MTY2NSAtMTA3MzcxNzE1NyA0MSAwIDY2MDQ3IDA7fQ0KIC8qIFN0eWxlIERlZmluaXRp b25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28t c3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFy ZW50OiIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdp bmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tZmFyZWFzdC10aGVtZS1mb250Om1pbm9yLWxhdGluO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246 d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFy ZWFzdC10aGVtZS1mb250Om1pbm9yLWxhdGluO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0 eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJbXNvLWFu c2ktZm9udC1zaXplOjguMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OlRhaG9t YTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6VGFob21hOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OlRhaG9tYTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5k ZXJsaW5lOnNpbmdsZTsNCgljb2xvcjp0ZWFsO30NCnNwYW4ubXNvRGVsDQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjps aW5lLXRocm91Z2g7DQoJY29sb3I6cmVkO30NCnNwYW4uR3JhbUUNCgl7bXNvLXN0eWxlLW5hbWU6 IiI7DQoJbXNvLWdyYW0tZTp5ZXM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lpLWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC10aGVtZS1mb250Om1p bm9yLWxhdGluOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS10 aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iOw0KCW1zby1iaWRpLXRoZW1lLWZvbnQ6bWlub3ItYmlkaTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluOw0KCW1zby1oZWFkZXItbWFyZ2luOi41aW47DQoJbXNvLWZvb3Rlci1tYXJnaW46LjVpbjsN Cgltc28tcGFwZXItc291cmNlOjA7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gMTBdPg0KPHN0eWxlPg0KIC8q IFN0eWxlIERlZmluaXRpb25zICovDQogdGFibGUuTXNvTm9ybWFsVGFibGUNCgl7bXNvLXN0eWxl LW5hbWU6IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRzdHlsZS1yb3diYW5kLXNpemU6MDsNCgltc28t dHN0eWxlLWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1wYWRkaW5nLWFsdDow aW4gNS40cHQgMGluIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbjowaW47DQoJbXNvLXBhcmEtbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNv LWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3It bGF0aW47DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLXRoZW1l LWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7DQoJbXNvLWJpZGktdGhlbWUtZm9udDptaW5vci1iaWRpO30NCjwvc3R5bGU+DQo8IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PTNE ImVkaXQiIHNwaWRtYXg9M0QiMTAyNiIvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9M0QiZWRpdCI+DQogIDxvOmlkbWFw IHY6ZXh0PTNEImVkaXQiIGRhdGE9M0QiMSIvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz0zREVOLVVTIHN0eWxlPTNEJ3RhYi1pbnRl cnZhbDouNWluJz4NCg0KPGRpdiBjbGFzcz0zRFdvcmRTZWN0aW9uMT4NCg0KPHAgY2xhc3M9M0RN c29Ob3JtYWw+RUNSSVQgY2hhcnRlciAody9wcm9wb3NlZCByZXZpc2lvbnMpOjwvcD4NCg0KPHAg Y2xhc3M9M0RNc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPTNETXNv Tm9ybWFsPkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6PC9wPg0KDQo8cCBjbGFzcz0zRE1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+Jm5i c3A7Jm5ic3A7Jm5ic3A7IEluIGEgbnVtYmVyIG9mIGFyZWFzLCB0aGUgcHVibGljIHN3PQ0KaXRj aGVkDQp0ZWxlcGhvbmUgbmV0d29yayAoUFNUTikgaGFzPC9wPg0KDQo8cCBjbGFzcz0zRE1zb05v cm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsgPHNwYW4gY2xhc3M9M0RHcmFtRT5iZWVuPC9zcGFuPiBj b249DQpmaWd1cmVkDQp0byByZWNvZ25pemUgYW4gZXhwbGljaXRseSBzcGVjaWZpZWQgbnVtYmVy ICh1c3VhbGx5PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsg PHNwYW4gY2xhc3M9M0RHcmFtRT5vbmU8L3NwYW4+IHRoYXQ9DQogaXMNCnNob3J0IGFuZCBlYXNp bHkgbWVtb3JpemVkKSBhcyBhIHJlcXVlc3QgZm9yIGVtZXJnZW5jeTwvcD4NCg0KPHAgY2xhc3M9 M0RNc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxzcGFuIGNsYXNzPTNER3JhbUU+c2Vydmlj ZXM8L3NwYW4+PQ0KLiZuYnNwOw0KVGhlc2UgbnVtYmVycyAoZS5nLiwgOTExLCAxMTIpIGFyZSBy ZWxhdGVkIHRvIGFuIGVtZXJnZW5jeTwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxzcGFuIGNsYXNzPTNER3JhbUU+c2VydmljZTwvc3Bhbj4gPQ0KY29udGV4 dA0KYW5kIGRlcGVuZCBvbiBhIGJyb2FkLCByZWdpb25hbCBjb25maWd1cmF0aW9uIG9mPC9wPg0K DQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsgPHNwYW4gY2xhc3M9M0RH cmFtRT5zZXJ2aWNlPC9zcGFuPiA9DQpjb250YWN0DQptZXRob2RzIGFuZCBhIGdlb2dyYXBoaWNh bGx5LWNvbnN0cmFpbmVkIGFwcHJvYWNoIGZvcjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxzcGFuIGNsYXNzPTNER3JhbUU+c2VydmljZTwvc3Bhbj4NCmRl bGl2ZXJ5LiZuYnNwOyBUaGVzZSBjYWxscyBhcmUgaW50ZW5kZWQgdG8gYmUgZGVsaXZlcmVkIHRv IHNwZWNpYWw8L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPiZuYnNwOyZuYnNwOyZuYnNwOyA8 c3BhbiBjbGFzcz0zREdyYW1FPmNhbGw8L3NwYW4+IGNlbj0NCnRlcnMNCmVxdWlwcGVkIHRvIG1h bmFnZSBlbWVyZ2VuY3kgcmVzcG9uc2UuIFN1Y2Nlc3NmdWw8L3A+DQoNCjxwIGNsYXNzPTNETXNv Tm9ybWFsPiZuYnNwOyZuYnNwOyZuYnNwOyA8c3BhbiBjbGFzcz0zREdyYW1FPmRlbGl2ZXJ5PC9z cGFuPj0NCiBvZiBhbg0KZW1lcmdlbmN5IHNlcnZpY2UgY2FsbCB3aXRoaW4gdGhvc2Ugc3lzdGVt cyByZXF1aXJlczwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxzcGFuIGNsYXNzPTNER3JhbUU+YW48L3NwYW4+IGFzc29jPQ0KaWF0aW9uDQpvZiBib3RoIHRo ZSBwaHlzaWNhbCBsb2NhdGlvbiBvZiB0aGUgb3JpZ2luYXRpbmcgZGV2aWNlIDwvcD4NCg0KPHAg Y2xhc3M9M0RNc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9M0RH cmFtRT5hbG9uZzwvc3BhPQ0Kbj4gd2l0aA0KYXBwcm9wcmlhdGUgY2FsbCByb3V0aW5nIHRvIGFu IGVtZXJnZW5jeSBzZXJ2aWNlIGNlbnRlci48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsmbmJzcDsm bmJzcDsgQ2FsbHMgcGxhY2VkIHVzaW5nIEludGVybmV0IHRlY2hub2w9DQpvZ2llcw0KZG8gbm90 IHVzZSB0aGUgc2FtZSBzeXN0ZW1zPC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsm bmJzcDsmbmJzcDsgTWVudGlvbmVkIGFib3ZlIHRvIGFjaGlldmUgdGhvc2Ugc2E9DQptZQ0KZ29h bHMsIGFuZCB0aGUgY29tbW9uIHVzZSBvZiA8L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPTNER3JhbUU+b3ZlcmxheTwvcz0NCnBh bj4NCm5ldHdvcmtzIGFuZCB0dW5uZWxzIChlaXRoZXIgYXMgVlBOcyBvciBmb3IgbW9iaWxpdHkp IG1ha2VzIDwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9M0RHcmFtRT5tZWV0aW5nPC9zPQ0KcGFuPg0KdGhlc2UgZ29hbHMgZXZl biBtb3JlIGNoYWxsZW5naW5nLiZuYnNwOyBUaGVyZSBhcmUsIGhvd2V2ZXIsIDwvcD4NCg0KPHAg Y2xhc3M9M0RNc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SW50ZXJuZXQgdGVjaG5v bG9naWVzIGF2YWlsYWJsPQ0KZSB0bw0KbWFuYWdlIGxvY2F0aW9uIGFuZCB0byBwZXJmb3JtIGNh bGwgPC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0zREdyYW1FPnJvdXRpbmc8L3M9DQpwYW4+LiZuYnNwOw0KVGhpcyB3b3JraW5n IGdyb3VwIHdpbGwgZGVzY3JpYmUgd2hlcmUgYW5kIGhvdyB0aGVzZSBtZWNoYW5pc21zIDwvcD4N Cg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9M0RHcmFtRT5tYXk8L3NwYW4+PQ0KIGJlDQp1c2VkLiBUaGUgZ3JvdXAgd2lsbCBzaG93IGhv dyB0aGUgYXZhaWxhYmlsaXR5IG9mIGxvY2F0aW9uIGRhdGEgPC9wPg0KDQo8cCBjbGFzcz0zRE1z b05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0zREdyYW1FPmFuZDwv c3Bhbj49DQogY2FsbA0Kcm91dGluZyBpbmZvcm1hdGlvbiBhdCBkaWZmZXJlbnQgc3RlcHMgaW4g dGhlIGNhbGwgc2Vzc2lvbiA8L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPTNER3JhbUU+c2V0dXA8L3NwYT0NCm4+IHdvdWxkDQpl bmFibGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGEgdXNlciBhbmQgYSByZWxldmFudCBlbWVyZ2Vu Y3kgPC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0zREdyYW1FPnJlc3BvbnNlPC89DQpzcGFuPg0KY2VudGVyLiBUaG91Z2ggdGhl IHRlcm0gJnF1b3Q7Y2FsbCByb3V0aW5nJnF1b3Q7IGlzIHVzZWQ8c3BhbiBjbGFzcz0zRG1zb0Rl PQ0KbD48ZGVsDQpjaXRlPTNEIm1haWx0bzpSb2dlciUyME1hcnNoYWxsIiBkYXRldGltZT0zRCIy MDEzLTEwLTIxVDA5OjUxIj4gaW4gdGhpcyBkb2M9DQp1bWVudDwvZGVsPjwvc3Bhbj4sDQo8L3A+ DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNs YXNzPTNER3JhbUU+aXQ8L3NwYW4+ID0NCnNob3VsZA0KYmUgdW5kZXJzdG9vZCB0aGF0IHNvbWUg b2YgdGhlIG1lY2hhbmlzbXMgd2hpY2ggd2lsbCBiZTwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3Jt YWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxzcGFuIGNsYXNzPTNER3JhbUU+ZGVzY3JpYmVkPC9zcGFu PQ0KPiBtaWdodA0KYmUgdXNlZCB0byBlbmFibGUgb3RoZXIgdHlwZXMgb2YgbWVkaWEgc3RyZWFt cy4gPHNwYW4gY2xhc3M9M0Rtc29EZWw+PGRlbA0KY2l0ZT0zRCJtYWlsdG86Um9nZXIlMjBNYXJz aGFsbCIgZGF0ZXRpbWU9M0QiMjAxMy0xMC0yMVQwOTo1MSI+VmlkZW88bzpwPjwvPQ0KbzpwPjwv ZGVsPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuIGNsYXNzPTNEbXNv RGVsPjxkZWwgY2l0ZT0zRCJtYWlsdG86Um9nZXIlMjBNYXJzaD0NCmFsbCINCmRhdGV0aW1lPTNE IjIwMTMtMTAtMjFUMDk6NTEiPiZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgdGV4dCBtZXNzYWdpbmcs IGZvciBleD0NCmFtcGxlLA0KbWlnaHQgYmUgdXNlZCB0byByZXF1ZXN0IGVtZXJnZW5jeTxvOnA+ PC9vOnA+PC9kZWw+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PHNwYW4gY2xh c3M9M0Rtc29EZWw+PGRlbCBjaXRlPTNEIm1haWx0bzpSb2dlciUyME1hcnNoPQ0KYWxsIg0KZGF0 ZXRpbWU9M0QiMjAxMy0xMC0yMVQwOTo1MSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZpY2VzLjwv ZGVsPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsgQmV5b25kIGh1 bWFuIGluaXRpYXRlZCBlbWVyZ2VuY3kgY2E9DQpsbA0KcmVxdWVzdCBtZWNoYW5pc21zLCB0aGlz IGdyb3VwIHdpbGwgPC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0zREdyYW1FPmRldmVsb3A8L3M9DQpwYW4+IG5ldw0KbWV0aG9k cyB0byByZXF1ZXN0IGVtZXJnZW5jeSBhc3Npc3RhbmNlLCBzdWNoIGFzIHNlbnNvciA8L3A+DQoN CjxwIGNsYXNzPTNETXNvTm9ybWFsPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PTNER3JhbUU+aW5pdGlhdGVkPD0NCi9zcGFuPiBlbWVyZ2VuY3kNCnJlcXVlc3RzLCBhbmQgYWRk aXRpb25hbCBwcm9jZXNzZXMgc3BlY2lmaWVkIHRoYXQgPC9wPg0KDQo8cCBjbGFzcz0zRE1zb05v cm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0zREdyYW1FPmFkZHJlc3M8 L3M9DQpwYW4+DQp0b3BpY3Mgc3VjaCBhcyBhdXRoZW50aWNhdGlvbiBvZiBsb2NhdGlvbiwgc2Vy dmljZSBVUk4gZGVmaW5pdGlvbiA8L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPTNER3JhbUU+YW5kPC9zcGFuPj0NCiB1c2UsDQph dWdtZW50ZWQgaW5mb3JtYXRpb24gdGhhdCBjb3VsZCBhc3Npc3QgZW1lcmdlbmN5IGNhbGwgdGFr ZXJzIG9yIDwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PHNwYW4gY2xhc3M9M0RHcmFtRT5yZXNwb25kZXJzPQ0KPC9zcGFuPi48L3A+DQoNCjxwIGNs YXNzPTNETXNvTm9ybWFsPiZuYnNwOyA8L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO0V4cGxpY2l0bHkgb3V0c2lkZSB0aGUgc2NvcGUgbz0NCmYgdGhp cw0KZ3JvdXAgaXMgdGhlIHF1ZXN0aW9uIG9mPC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4m bmJzcDsmbmJzcDsmbmJzcDsgPHNwYW4gY2xhc3M9M0RHcmFtRT5wcmUtZW1wdGlvbjwvc3A9DQph bj4gb3INCnByaW9yaXRpemF0aW9uIG9mIGVtZXJnZW5jeSBzZXJ2aWNlcyB0cmFmZmljLiBUaGlz PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsgPHNwYW4gY2xh c3M9M0RHcmFtRT5ncm91cDwvc3Bhbj4gaXMNCmNvbnNpZGVyaW5nIGVtZXJnZW5jeSBzZXJ2aWNl cyBjYWxscyB3aGljaCBtaWdodCBiZSBtYWRlIGJ5PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1h bD4mbmJzcDsmbmJzcDsmbmJzcDsgPHNwYW4gY2xhc3M9M0RHcmFtRT5hbnk8L3NwYW4+IHVzZXI9 DQogb2YgdGhlDQpJbnRlcm5ldCwgYXMgb3Bwb3NlZCB0byBnb3Zlcm5tZW50IG9yIG1pbGl0YXJ5 PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsgPHNwYW4gY2xh c3M9M0RHcmFtRT5zZXJ2aWNlczwvc3Bhbj49DQogdGhhdA0KbWF5IGltcG9zZSB2ZXJ5IGRpZmZl cmVudCBhdXRoZW50aWNhdGlvbiBhbmQgcm91dGluZzwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3Jt YWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxzcGFuIGNsYXNzPTNER3JhbUU+cmVxdWlyZW1lbnRzPC9z PQ0KcGFuPi48L3A+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD4mbmJzcDsmbmJzcDsmbmJzcDsgV2hpbGUgdGhpcyBn cm91cCBhbnRpY2lwYXRlcyBhIGNsb3NlDQp3b3JraW5nIHJlbGF0aW9uc2hpcCB3aXRoIGdyb3Vw czwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxzcGFuIGNs YXNzPTNER3JhbUU+c3VjaDwvc3Bhbj4gYXMgPQ0KTkVOQTxzcGFuDQpjbGFzcz0zRG1zb0lucz48 aW5zIGNpdGU9M0QibWFpbHRvOlJvZ2VyJTIwTWFyc2hhbGwiIGRhdGV0aW1lPTNEIjIwMTMtMTAt MjE9DQpUMTA6MTUiPiwNCkVFTkEsIDNHUFAsPC9pbnM+PC9zcGFuPiBhbmQgRVRTSSA8c3BhbiBj bGFzcz0zRG1zb0RlbD48ZGVsDQpjaXRlPTNEIm1haWx0bzpSb2dlciUyME1hcnNoYWxsIiBkYXRl dGltZT0zRCIyMDEzLTEwLTIxVDEwOjE1Ij5FTVRFTDwvZGVsPjw9DQovc3Bhbj4sIDxzcGFuDQpj bGFzcz0zRG1zb0lucz48aW5zIGNpdGU9M0QibWFpbHRvOlJvZ2VyJTIwTWFyc2hhbGwiIGRhdGV0 aW1lPTNEIjIwMTMtMTAtMjE9DQpUMTU6MjciPmFueQ0Kc29sdXRpb24gcHJlc2VudGVkIG11c3Qg YmUgZ2VuZXJhbCBlbm91Z2ggdG8gYmUgcG90ZW50aWFsbHkgdXNlZnVsIGluIG9yIGFjPQ0Kcm9z cw0KbXVsdGlwbGUgcmVnaW9ucyBvciBqdXJpc2RpY3Rpb25zPC9pbnM+PC9zcGFuPjxzcGFuIGNs YXNzPTNEbXNvRGVsPjxkZWwNCmNpdGU9M0QibWFpbHRvOlJvZ2VyJTIwTWFyc2hhbGwiIGRhdGV0 aW1lPTNEIjIwMTMtMTAtMjFUMTE6MTUiPmFueSBzb2x1dGlvbg0KcHJlc2VudGVkIG11c3QgYmUg dXNlZnVsPG86cD48L286cD48L2RlbD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1h bD48c3BhbiBjbGFzcz0zRG1zb0RlbD48ZGVsIGNpdGU9M0QibWFpbHRvOlJvZ2VyJTIwTWFyc2g9 DQphbGwiDQpkYXRldGltZT0zRCIyMDEzLTEwLTIxVDExOjE1Ij4mbmJzcDsmbmJzcDsmbmJzcDsg cmVnYXJkbGVzcyBvZiBqdXJpc2RpY3Rpb249DQo8L2RlbD48L3NwYW4+LA0KYW5kIGl0IG11c3Qg YmUgcG9zc2libGUgdG8gdXNlIHdpdGhvdXQgcmVxdWlyaW5nIGE8L3A+DQoNCjxwIGNsYXNzPTNE TXNvTm9ybWFsPiZuYnNwOyZuYnNwOyZuYnNwOyA8c3BhbiBjbGFzcz0zREdyYW1FPnNpbmdsZTwv c3Bhbj4sID0NCmNlbnRyYWwNCmF1dGhvcml0eS4mbmJzcDsgPHNwYW4gc3R5bGU9M0QnbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPj0NCjxzcGFuDQpjbGFzcz0zRG1z b0lucz48aW5zIGNpdGU9M0QibWFpbHRvOlJvZ2VyJTIwTWFyc2hhbGwiIGRhdGV0aW1lPTNEIjIw MTMtMTAtMjE9DQpUMDk6NTIiPkZ1cnRoZXIsDQppdCBtdXN0IGJlIHBvc3NpYmxlIGZvciBtdWx0 aXBsZSBkZWxlZ2F0aW9ucyB3aXRoaW4gYSBqdXJpc2RpY3Rpb24gdG8gYmUNCmhhbmRsZWQgaW5k ZXBlbmRlbnRseSw8L2lucz48L3NwYW4+PHNwYW4gY2xhc3M9M0Rtc29JbnM+PGlucw0KY2l0ZT0z RCJtYWlsdG86Um9nZXIlMjBNYXJzaGFsbCIgZGF0ZXRpbWU9M0QiMjAxMy0xMC0yMVQwOTo1MyI+ IHRoaW5nczwvaW5zPQ0KPjwvc3Bhbj48c3Bhbg0KY2xhc3M9M0Rtc29JbnM+PGlucyBjaXRlPTNE Im1haWx0bzpSb2dlciUyME1hcnNoYWxsIiBkYXRldGltZT0zRCIyMDEzLTEwLTIxPQ0KVDA5OjUy Ij4gPC9pbnM+PC9zcGFuPjxzcGFuDQpjbGFzcz0zRG1zb0lucz48aW5zIGNpdGU9M0QibWFpbHRv OlJvZ2VyJTIwTWFyc2hhbGwiIGRhdGV0aW1lPTNEIjIwMTMtMTAtMjE9DQpUMDk6NTMiPnN1Y2gN CjwvaW5zPjwvc3Bhbj48c3BhbiBjbGFzcz0zRG1zb0lucz48aW5zIGNpdGU9M0QibWFpbHRvOlJv Z2VyJTIwTWFyc2hhbGwiDQpkYXRldGltZT0zRCIyMDEzLTEwLTIxVDA5OjUyIj5hcyBjYWxsPHUx OnA+PC91MTpwPiByb3V0aW5nIGZvciBzcGVjaWZpYyBlbWU9DQpyZ2VuY3kNCnR5cGVzLCBtZWRp YSB0eXBlcywgbGFuZ3VhZ2UgY29udGVudHM8L2lucz48L3NwYW4+PHNwYW4gY2xhc3M9M0Rtc29J bnM+PGlucw0KY2l0ZT0zRCJtYWlsdG86Um9nZXIlMjBNYXJzaGFsbCIgZGF0ZXRpbWU9M0QiMjAx My0xMC0yMVQwOTo1NCI+LDwvaW5zPjwvc3BhPQ0Kbj48c3Bhbg0KY2xhc3M9M0Rtc29JbnM+PGlu cyBjaXRlPTNEIm1haWx0bzpSb2dlciUyME1hcnNoYWxsIiBkYXRldGltZT0zRCIyMDEzLTEwLTIx PQ0KVDA5OjUyIj4NCmV0Yy4sJm5ic3A7IG1heSBiZSByb3V0ZWQgZGlmZmVyZW50bHkgZGVwZW5k aW5nIG9uIGVzdGFibGlzaGVkIHBvbGljaWVzIGFuZA0KYXZhaWxhYmlsaXR5LjwvaW5zPjwvc3Bh bj48L3NwYW4+PHNwYW4gY2xhc3M9M0Rtc29EZWw+PGRlbA0KY2l0ZT0zRCJtYWlsdG86Um9nZXIl MjBNYXJzaGFsbCIgZGF0ZXRpbWU9M0QiMjAxMy0xMC0yMVQwOTo1MiI+RnVydGhlciwgaXQgPQ0K bXVzdCBiZQ0KcG9zc2libGUgZm9yIG11bHRpcGxlPG86cD48L286cD48L2RlbD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48c3BhbiBjbGFzcz0zRG1zb0RlbD48ZGVsIGNpdGU9 M0QibWFpbHRvOlJvZ2VyJTIwTWFyc2g9DQphbGwiDQpkYXRldGltZT0zRCIyMDEzLTEwLTIxVDA5 OjUyIj4mbmJzcDsgJm5ic3A7Jm5ic3A7ZGVsZWdhdGlvbnMgd2l0aGluIGENCmp1cmlzZGljdGlv biB0byBiZSBoYW5kbGVkIGluZGVwZW5kZW50bHksIGFzIGNhbGw8bzpwPjwvbzpwPjwvZGVsPjwv c3Bhbj48Lz0NCnA+DQoNCjxwIGNsYXNzPTNETXNvTm9ybWFsPjxzcGFuIGNsYXNzPTNEbXNvRGVs PjxkZWwgY2l0ZT0zRCJtYWlsdG86Um9nZXIlMjBNYXJzaD0NCmFsbCINCmRhdGV0aW1lPTNEIjIw MTMtMTAtMjFUMDk6NTIiPiZuYnNwOyZuYnNwOyZuYnNwOyByb3V0aW5nIGZvciBzcGVjaWZpYyBl bWVyZz0NCmVuY3kNCnR5cGVzIG1heSBiZSBoYW5kbGVkIGluZGVwZW5kZW50bHk8L2RlbD48L3Nw YW4+LjwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoN CjxwIGNsYXNzPTNETXNvTm9ybWFsPiZuYnNwOyAmbmJzcDsmbmJzcDtUaGlzIHdvcmtpbmcgZ3Jv dXAgY2FyZXMgYWJvdXQgcHJpdj0NCmFjeQ0KYW5kIHNlY3VyaXR5IGNvbmNlcm5zLCBhbmQgd2ls bDwvcD4NCg0KPHAgY2xhc3M9M0RNc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxzcGFuIGNs YXNzPTNER3JhbUU+YWRkcmVzczwvc3Bhbj4gPQ0KdGhlbQ0Kd2l0aGluIGl0cyBkb2N1bWVudHMu PC9wPg0KDQo8cCBjbGFzcz0zRE1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjwvYm9keT4NCg0KPC9odG1sPg0KDQotLS0tLS09X05leHRQYXJ0XzAxQ0VDRTcyLjI0 NDFEMUQwDQpDb250ZW50LUxvY2F0aW9uOiBmaWxlOi8vL0M6LzY3MjhEQzEzL0VDUklUX0NoYXJ0 ZXJfcmV2aXNlZF8yMDEzMTAyMTA0XzNfZmlsZXMvdGhlbWVkYXRhLnRobXgNCkNvbnRlbnQtVHJh bnNmZXItRW5jb2Rpbmc6IGJhc2U2NA0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi92bmQubXMt b2ZmaWNldGhlbWUNCg0KVUVzREJCUUFCZ0FJQUFBQUlRRHAzZysvL3dBQUFCd0NBQUFUQUFBQVcw TnZiblJsYm5SZlZIbHdaWE5kTG5odGJLeVJ5MDdETUJCRg0KOTBqOGcrVXRTcHl5UUFnbDZZTEhq c2VpZk1ESW1TUVd5ZGl5cDFYNzkwelNWRUtvSUJac0xOa3o5NTQ3NDNLOUh3ZTF3NWljcDBxdg0K OGtJckpPc2JSMTJsM3pkUDJhMVdpWUVhR0R4aHBRK1k5THErdkNnM2g0QkppWnBTcFh2bWNHZE1z ajJPa0hJZmtLVFMramdDeXpWMg0KSm9EOWdBN05kVkhjR091SmtUamp5VVBYNVFPMnNCMVlQZTds K1pnazRwQzB1ajgyVHF4S1F3aURzOENTMU95bytVYkpGa0l1eXJrbg0KOVM2a0s0bWh6Vm5DVlBr WnNPaGVaVFhSTmFqZUlQSUxqQkxEc0F5Slg4OW5JQmt0NXI4N25vbnMyOVpaYkx6ZGpyS09mRFpl ekU3Qg0KL3hSZzlUL29FOVBNZjF0L0FnQUEvLzhEQUZCTEF3UVVBQVlBQ0FBQUFDRUFwZGFuNThB QUFBQTJBUUFBQ3dBQUFGOXlaV3h6THk1eQ0KWld4emhJL1Bhc013RElmdmhiMkQwWDFSMHNNWUpY WXZwWkJETDZOOUFPRW9mMmdpRzlzYjY5dFB4d1lLdXdpRXBPLzNxVDMrcm92NQ0KNFpUbklCYWFx Z2JENGtNL3kyamhkajIvZjRMSmhhU25KUWhiZUhDR28zdmJ0Vis4VU5HalBNMHhHNlZJdGpDVkVn K0kyVSs4VXE1Qw0KWk5ISkVOSktSZHMwWWlSL3A1RnhYOWNmbUo0WjREWk0wL1VXVXRjM1lLNlBx TW4vczhNd3pKNVB3WCt2TE9WRkJHNDNsRXhwNUdLaA0KcUMvalU3MlFxR1dxMUI3UXRiajUxdjBC QUFELy93TUFVRXNEQkJRQUJnQUlBQUFBSVFCcmVaWVdnd0FBQUlvQUFBQWNBQUFBZEdobA0KYldV dmRHaGxiV1V2ZEdobGJXVk5ZVzVoWjJWeUxuaHRiQXpNVFFyRElCQkE0WDJoZDVEWk4yTzdLRVZp c3N1dXUvWUFRNXdhUWNlZw0KMHAvYjErWGpnemZPM3hUVm0wc05XU3ljQncyS1pjMHVpTGZ3ZkN5 bkc2amFTQnpGTEd6aHh4WG02WGdZeWJTTkU5OUp5SE5SZlNQVg0Ka0lXdHRkMGcxclVyMVNIdkxO MWV1U1JxUFl0SFYralQ5eW5pUmVzckpnb0NPUDBCQUFELy93TUFVRXNEQkJRQUJnQUlBQUFBSVFB dw0KM1VNcHFBWUFBS1FiQUFBV0FBQUFkR2hsYldVdmRHaGxiV1V2ZEdobGJXVXhMbmh0Yk94WlQy L2JOaFMvRDloM0lIUnZZeWQyR2dkMQ0KaXRpeG15MU5HOFJ1aHg1cGlaYllVS0pBMGtsOUc5cmpn QUhEdW1HSEZkaHRoMkZiZ1JiWXBmczAyVHBzSGRDdnNFZFNrc1ZZWHBJMg0KMklxdFBpUVMrZVA3 L3g0ZnFhdlg3c2NNSFJJaEtVL2FYdjF5elVNazhYbEFrN0R0M1I3Mkw2MTVTQ3FjQkpqeGhMUzlL WkhldFkzMw0KMzd1SzExVkVZb0pnZlNMWGNkdUxsRXJYbDVha0Q4TllYdVlwU1dCdXpFV01GYnlL Y0NrUStBam94bXhwdVZaYlhZb3hUVHlVNEJqSQ0KM2hxUHFVL1FVSlAwTm5MaVBRYXZpWko2d0dk aW9Fa1RaNFhCQmdkMWpaQlQyV1VDSFdMVzlvQlB3SStHNUw3eUVNTlN3VVRicTVtZg0KdDdSeGRR bXZaNHVZV3JDMnRLNXZmdG02YkVGd3NHeDRpbkJVTUszM0c2MHJXd1Y5QTJCcUh0ZnI5YnE5ZWtI UEFMRHZnNlpXbGpMTg0KUm4rdDNzbHBsa0QyY1o1MnQ5YXNOVng4aWY3S25NeXRUcWZUYkdXeVdL SUdaQjhiYy9pMTJtcGpjOW5CRzVERk4rZndqYzVtdDd2cQ0KNEEzSTRsZm44UDBycmRXR2l6ZWdp TkhrWUE2dEhkcnZaOVFMeUppejdVcjRHc0RYYWhsOGhvSm9LS0pMc3hqelJDMkt0UmpmNDZJUA0K QUExa1dORUVxV2xLeHRpSEtPN2llQ1FvMWd6d09zR2xHVHZreTdraHpRdEpYOUJVdGIwUFV3d1pN YVAzNnZuM3I1NC9SY2NQbmgwLw0KK09uNDRjUGpCejlhUXM2cWJaeUU1VlV2di8zc3o4Y2Zveitl ZnZQeTBSZlZlRm5HLy9yREo3LzgvSGsxRU5KbkpzNkxMNS84OXV6Sg0KaTY4Ky9mMjdSeFh3VFlG SFpmaVF4a1NpbStRSTdmTVlGRE5XY1NVbkkzRytGY01JMC9LS3pTU1VPTUdhU3dYOW5vb2M5TTBw WnBsMw0KSERrNnhMWGdIUUhsb3dwNGZYTFBFWGdRaVltaUZaeDNvdGdCN25MT09seFVXbUZIOHlx WmVUaEp3bXJtWWxMRzdXTjhXTVc3aXhQSA0KdjcxSkNuVXpEMHRIOFc1RUhESDNHRTRVRGtsQ0ZO SnovSUNRQ3UzdVV1cllkWmY2Z2tzK1Z1Z3VSUjFNSzAweXBDTW5tbWFMdG1rTQ0KZnBsVzZReitk bXl6ZXdkMU9LdlNlb3NjdWtqSUNzd3FoQjhTNXBqeE9wNG9IRmVSSE9LWWxRMStBNnVvU3NqQlZQ aGxYRThxOEhSSQ0KR0VlOWdFaFp0ZWFXQUgxTFR0L0JVTEVxM2I3THByR0xGSW9lVk5HOGdUa3ZJ N2Y0UVRmQ2NWcUZIZEFrS21NL2tBY1FvaGp0Y1ZVRg0KMytWdWh1aDM4QU5PRnJyN0RpV091MCt2 QnJkcDZJZzBDeEE5TXhFVnZyeE91Qk8vZ3lrYlkySktEUlIxcDFiSE5QbTd3czBvVkc3TA0KNGVJ S041VEtGMTgvcnBEN2JTM1ptN0I3VmVYTTlvbEN2UWgzc2p4M3VRam8yMStkdC9BazJTT1FFUE5i MUx2aS9LNDRlLy81NHJ3bw0KbnkrK0pNK3FNQlJvM1l2WVJ0dTAzZkhDcm50TUdSdW9LU00zcEdt OEpldzlRUjhHOVRwejRpVEZLU3lONEZGbk1qQndjS0hBWmcwUw0KWEgxRVZUU0ljQXBOZTkzVFJF S1prUTRsU3JtRXc2SVpycVN0OGRENEszdlViT3BEaUswY0VxdGRIdGpoRlQyY256VUtNa2FxMEJ4 bw0KYzBZcm1zQlptYTFjeVlpQ2JxL0RySzZGT2pPM3VoSE5GRVdIVzZHeU5yRTVsSVBKQzlWZ3NM QW1ORFVJV2lHdzhpcWMrVFZyT094Zw0KUmdKdGQrdWozQzNHQ3hmcElobmhnR1ErMG5yUCs2aHVu SlRIeXB3aVdnOGJEUHJnZUlyVlN0eGFtdXdiY0R1TGs4cnNHZ3ZZNWQ1Nw0KRXkvbEVUenpFbEE3 bVk0c0tTY25TOUJSMjJzMWw1c2U4bkhhOXNad1RvYkhPQVd2UzkxSFloYkNaWk92aEEzN1U1UFpa UG5NbTYxYw0KTVRjSjZuRDFZZTArcDdCVEIxSWgxUmFXa1EwTk01V0ZBRXMwSnl2L2NoUE1lbEVL VkZTanMwbXhzZ2JCOEs5SkFYWjBYVXZHWStLcg0Kc3JOTEk5cDI5alVycFh5aWlCaEV3UkVhc1lu WXgrQitIYXFnVDBBbFhIZVlpcUJmNEc1T1c5dE11Y1U1UzdyeWpaakIyWEhNMGdobg0KNVZhbmFK N0pGbTRLVWlHRGVTdUpCN3BWeW02VU83OHFKdVV2U0pWeUdQL1BWTkg3Q2R3K3JBVGFBejVjRFF1 TWRLYTBQUzVVeEtFSw0KcFJIMSt3SWFCMU03SUZyZ2ZoZW1JYWpnZ3RyOEYrUlEvN2M1WjJtWXRJ WkRwTnFuSVJJVTlpTVZDVUwyb0N5WjZEdUZXRDNidXl4Sg0KbGhFeUVWVVNWNlpXN0JFNUpHeW9h K0NxM3RzOUZFR29tMnFTbFFHRE94bC83bnVXUWFOUU56bmxmSE1xV2JIMzJoejRwenNmbTh5Zw0K bEZ1SFRVT1QyNzhRc1dnUFpydXFYVytXNTN0dldSRTlNV3V6R25sV0FMUFNWdERLMHY0MVJUam5W bXNyMXB6R3k4MWNPUERpdk1Zdw0KV0RSRUtkd2hJZjBIOWo4cWZHYS9kdWdOZGNqM29iWWkrSGlo aVVIWVFGUmZzbzBIMGdYU0RvNmdjYktETnBnMEtXdmFySFhTVnNzMw0KNnd2dWRBdStKNHl0SlR1 THY4OXA3S0k1YzlrNXVYaVJ4czRzN05qYWppMDBOWGoyWklyQzBEZy95QmpIbU05azVTOVpmSFFQ SEwwRg0KM3d3bVRFa1RUUENkU21Eb29RY21EeUQ1TFVlemRPTXZBQUFBLy84REFGQkxBd1FVQUFZ QUNBQUFBQ0VBRGRHUW43WUFBQUFiQVFBQQ0KSndBQUFIUm9aVzFsTDNSb1pXMWxMMTl5Wld4ekwz Um9aVzFsVFdGdVlXZGxjaTU0Yld3dWNtVnNjNFNQVFFyQ01CU0U5NEozQ0c5dg0KMDdvUWtTYmRp TkN0MUFPRTVEVU5OajhrVWV6dERhNHNDQzZIWWI2WmFidVhuY2tUWXpMZU1XaXFHZ2c2NlpWeG1z RnR1T3lPUUZJVw0KVG9uWk8yU3dZSUtPYnpmdEZXZVJTeWhOSmlSU0tDNHhtSElPSjBxVG5OQ0tW UG1BcmppamoxYmtJcU9tUWNpNzBFajNkWDJnOFpzQg0KZk1Va3ZXSVFlOVVBR1paUW12K3ovVGdh aVdjdkh4WmQvbEZCYzltRkJTaWl4c3pnSTV1cVRBVEtXN3E2eE44QUFBRC8vd01BVUVzQg0KQWkw QUZBQUdBQWdBQUFBaEFPbmVENy8vQUFBQUhBSUFBQk1BQUFBQUFBQUFBQUFBQUFBQUFBQUFBRnRE YjI1MFpXNTBYMVI1Y0dWeg0KWFM1NGJXeFFTd0VDTFFBVUFBWUFDQUFBQUNFQXBkYW41OEFBQUFB MkFRQUFDd0FBQUFBQUFBQUFBQUFBQUFBd0FRQUFYM0psYkhNdg0KTG5KbGJITlFTd0VDTFFBVUFB WUFDQUFBQUNFQWEzbVdGb01BQUFDS0FBQUFIQUFBQUFBQUFBQUFBQUFBQUFBWkFnQUFkR2hsYldV dg0KZEdobGJXVXZkR2hsYldWTllXNWhaMlZ5TG5odGJGQkxBUUl0QUJRQUJnQUlBQUFBSVFBdzNV TXBxQVlBQUtRYkFBQVdBQUFBQUFBQQ0KQUFBQUFBQUFBTllDQUFCMGFHVnRaUzkwYUdWdFpTOTBh R1Z0WlRFdWVHMXNVRXNCQWkwQUZBQUdBQWdBQUFBaEFBM1JrSisyQUFBQQ0KR3dFQUFDY0FBQUFB QUFBQUFBQUFBQUFBc2drQUFIUm9aVzFsTDNSb1pXMWxMMTl5Wld4ekwzUm9aVzFsVFdGdVlXZGxj aTU0Yld3dQ0KY21Wc2MxQkxCUVlBQUFBQUJRQUZBRjBCQUFDdENnQUFBQUE9DQoNCi0tLS0tLT1f TmV4dFBhcnRfMDFDRUNFNzIuMjQ0MUQxRDANCkNvbnRlbnQtTG9jYXRpb246IGZpbGU6Ly8vQzov NjcyOERDMTMvRUNSSVRfQ2hhcnRlcl9yZXZpc2VkXzIwMTMxMDIxMDRfM19maWxlcy9jb2xvcnNj aGVtZW1hcHBpbmcueG1sDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRh YmxlDQpDb250ZW50LVR5cGU6IHRleHQveG1sDQoNCjw/eG1sIHZlcnNpb249M0QiMS4wIiBlbmNv ZGluZz0zRCJVVEYtOCIgc3RhbmRhbG9uZT0zRCJ5ZXMiPz4NCjxhOmNsck1hcCB4bWxuczphPTNE Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9kcmF3aW5nbWwvMjAwNi9tYWluIj0N CiBiZzE9M0QibHQxIiB0eDE9M0QiZGsxIiBiZzI9M0QibHQyIiB0eDI9M0QiZGsyIiBhY2NlbnQx PTNEImFjY2VudDEiIGFjY2VudD0NCjI9M0QiYWNjZW50MiIgYWNjZW50Mz0zRCJhY2NlbnQzIiBh Y2NlbnQ0PTNEImFjY2VudDQiIGFjY2VudDU9M0QiYWNjZW50NSIgYT0NCmNjZW50Nj0zRCJhY2Nl bnQ2IiBobGluaz0zRCJobGluayIgZm9sSGxpbms9M0QiZm9sSGxpbmsiLz4NCi0tLS0tLT1fTmV4 dFBhcnRfMDFDRUNFNzIuMjQ0MUQxRDANCkNvbnRlbnQtTG9jYXRpb246IGZpbGU6Ly8vQzovNjcy OERDMTMvRUNSSVRfQ2hhcnRlcl9yZXZpc2VkXzIwMTMxMDIxMDRfM19maWxlcy9maWxlbGlzdC54 bWwNCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCkNvbnRlbnQt VHlwZTogdGV4dC94bWw7IGNoYXJzZXQ9InV0Zi04Ig0KDQo8eG1sIHhtbG5zOm89M0QidXJuOnNj aGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIj4NCiA8bzpNYWluRmlsZSBIUmVmPTNE Ii4uL0VDUklUX0NoYXJ0ZXJfcmV2aXNlZF8yMDEzMTAyMTA0XzMuaHRtIi8+DQogPG86RmlsZSBI UmVmPTNEInRoZW1lZGF0YS50aG14Ii8+DQogPG86RmlsZSBIUmVmPTNEImNvbG9yc2NoZW1lbWFw cGluZy54bWwiLz4NCiA8bzpGaWxlIEhSZWY9M0QiZmlsZWxpc3QueG1sIi8+DQo8L3htbD4NCi0t LS0tLT1fTmV4dFBhcnRfMDFDRUNFNzIuMjQ0MUQxRDAtLQ0K --_004_FBD5AAFFD0978846BF6D3FAB4C892ACC486660SEAEXMB1telecomsy_-- From hannes.tschofenig@gmx.net Tue Oct 22 08:43:19 2013 Return-Path: <hannes.tschofenig@gmx.net> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9DD11E846A for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 08:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpwS63k67J+e for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 08:43:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFB321E8088 for <ecrit@ietf.org>; Tue, 22 Oct 2013 08:43:14 -0700 (PDT) Received: from [172.16.254.200] ([80.92.115.161]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mh5h7-1VLlxJ3oAr-00MIQg for <ecrit@ietf.org>; Tue, 22 Oct 2013 17:43:13 +0200 Message-ID: <52669D2B.8000402@gmx.net> Date: Tue, 22 Oct 2013 17:43:39 +0200 From: Hannes Tschofenig <hannes.tschofenig@gmx.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Brian Rosen <br@brianrosen.net>, Christer Holmberg <christer.holmberg@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B1C41E829@ESESSMB209.ericsson.se> <CAOPrzE1SgvCGP8R2B=pUzz9KjPjOyHY-x4wHu-h4JP7FWUCVKQ@mail.gmail.com> In-Reply-To: <CAOPrzE1SgvCGP8R2B=pUzz9KjPjOyHY-x4wHu-h4JP7FWUCVKQ@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Dg6eThNcw4pqeSiG/WzPjD+nRJZNx5Xsw8WFQNQVRT3psiD8z54 GzNGidYiTa9TUMJOhjo5JaP3Y/NRmpPnydMuaEzeZf16+rCGptZsgZ0bUjncDm/NzmgQ0pI BeSEBMc+NdCtODy/rJOkyUbfkRrSO/xK2rBkskmNHU/plhdqCGb6zDLcDFlKUb2+kEzfahE uLrvTCVlrERHqupvAxWlQ== Cc: "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 15:43:20 -0000 Hi Christer, I agree with Brian's response and I added a few lines of text to clarify the relationship between the proposed element and the language tag. Here is the text: ----- 3.1.6. Data Provider Languages(s) Supported Data Element: Data Provider Language(s) supported Use: Required. XML Element: <Language> Description: The language used by the entity at the Data Provider Contact URI as an alpha 2-character code as defined in ISO 639-1:2002 Codes for the representation of names of languages -- Part 1: Alpha-2 code Multiple instances of this element may occur. Order is significant; preferred language should appear first. The content MUST reflect the languages supported at the contact URI. Note that the 'language' media feature tag, defined in RFC 3840 [RFC3840] and the more extensive language negotiation mechanism proposed with [I-D.gellens-negotiating-human-language] are ----- Is this OK for you? Do you think it will help to clarify? Ciao Hannes On 08/06/2013 05:33 PM, Brian Rosen wrote: > That feature is not the spoken or signed or typed language in the media. > There is an ongoing effort to provide a facility to negotiate those, > but even still, it's useful to know in advance of a call what languages > the service provider can handle. > > Brian > > On Tuesday, August 6, 2013, Christer Holmberg wrote: > > Hi,____ > > __ __ > > In SIP, it is possible to indicate supported languages using the > “language” media feature tag, defined in RFC 3840.____ > > __ __ > > Is the semantics different from the data provider language defined > in the additional-data draft?____ > > __ __ > > Do we need to say something about which/how to use?____ > > __ __ > > Regards,____ > > __ __ > > Christer____ > > __ __ > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@gmx.net Tue Oct 22 08:45:07 2013 Return-Path: <hannes.tschofenig@gmx.net> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B030211E846A for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 08:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwM9QAxOEfKN for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 08:45:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 771D111E83E9 for <ecrit@ietf.org>; Tue, 22 Oct 2013 08:45:01 -0700 (PDT) Received: from [172.16.254.200] ([80.92.115.161]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MHso5-1Va0W10lDh-003eR4 for <ecrit@ietf.org>; Tue, 22 Oct 2013 17:45:00 +0200 Message-ID: <52669D95.8030501@gmx.net> Date: Tue, 22 Oct 2013 17:45:25 +0200 From: Hannes Tschofenig <hannes.tschofenig@gmx.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Roger Marshall <RMarshall@telecomsys.com>, 'Christer Holmberg' <christer.holmberg@ericsson.com>, Brian Rosen <br@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se>, <CAOPrzE3XQGhXgH_zPpNDeLBrPb4hRUp2JefV2s9TqW1Ku0=RSA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C422DB7@ESESSMB209.ericsson.se> <FBD5AAFFD0978846BF6D3FAB4C892ACC3EDF01@SEA-EXMB-1.telecomsys.com> In-Reply-To: <FBD5AAFFD0978846BF6D3FAB4C892ACC3EDF01@SEA-EXMB-1.telecomsys.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:uWdcfq7B3xV/5psNyH3PZ8GKPfEK9FpVEeIFzaucW9q3LvpZtij kP5I8RZUEOvCTTsw9jydXxQ1w0TGoVwhzlKuP1JyRt9bbjUCNxReNjCpFvADK09nt+pib8w /2CfBSFyVPTcxWtb6dB7QfeHakaq75MOPJ5wCR742HZQhgYrZ5Hcr1ixZNenQ61JlRLWP3f Xahf7W39loxZB3AMrHNJA== Cc: "ecrit_ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 15:45:07 -0000 Hi Christer, as discussed in this email thread I added text for clarification: ---- 3.1.5. Data Provider Contact URI Data Element: Data Provider Contact URI Use: Required XML Element: <ContactURI> Description: When provided by a service provider or an access provider, this information MUST be a URI to a 24/7 support organization tasked to provide PSAP support for this emergency call. If the call is from a device, this would reflect the contact information of the owner of the device. If a telephone number is the contact address then it MUST be tel URI. If it is provided as a SIP URI then it MUST be in the form of sip:telephonenumber@serviceprovider:user=phone. Note that this contact information is not used by PSAPs for callbacks using a SIP Priority header field with the value set to "psap- callback", as described in [I-D.ietf-ecrit-psap-callback]. ---- Do you think that I managed to capture your concern? Ciao Hannes On 08/26/2013 10:33 PM, Roger Marshall wrote: > I agree with Christer’s suggestion to add caution text. > > -roger. > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Christer Holmberg > *Sent:* Thursday, August 08, 2013 9:44 PM > *To:* Brian Rosen > *Cc:* ecrit_ietf.org > *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on > scope of the Contact URI, defined in section 3.1.5 > > Hi, > > If the PSAP is not supposed to use the field when/if making a callback, > I think we shall explicitly state that in the document, and/or in > general say that the field must not be used for calls that are expected > to be given priority/special handling, and give callback as an example. > > Regards, > > Christer > > > > Sent from */Windows/* using *TouchDown*(www.nitrodesk.com > <http://www.nitrodesk.com>) > > > -----Original Message----- > *From:* Brian Rosen [br@brianrosen.net] > *To:* Christer Holmberg [christer.holmberg@ericsson.com] > *CC:* ecrit_ietf.org [ecrit@ietf.org] > *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on > scope of the Contact URI, defined in section 3.1.5 > > The Contact is how the PSAP contacts the service provider to get help > from the SP. > > It's not a "call back" in the sense of an emergency call (the network > doesn't treat it differently than a normal call), at least as far as I > have considered it. I suppose it might be nice to know that it's > important, but I don't think that is worth any big new mechanism. > > Brian > > > > On Thursday, August 8, 2013, Christer Holmberg wrote: > > I haven't seen any reply to this. Brian, do you have any opinion? > > Regards, > > Christer > > > > Sent from */Windows/* using *TouchDown* (www.nitrodesk.com > <http://www.nitrodesk.com>) > > > -----Original Message----- > *From:* Christer Holmberg [christer.holmberg@ericsson.com] > *To:* ecrit@ietf.org [ecrit@ietf.org] > *Subject:* [Ecrit] draft-ietf-ecrit-additional-data-11: Question on > scope of the Contact URI, defined in section 3.1.5 > > Hi, > > A question on the scope of the Contact URI, defined in section 3.1.5 of > draft-ietf-ecrit-additional-data-11.txt. > > Is the Contact URI supposed by the PSAP when making callbacks? > > If the value represents a “service provider”, should PSAP callbacks also > be made to the service provider? > > Regards, > > Christer > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, > or responsible for delivering this message to the intended recipient, > any review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, > and delete it and all attachments from your computer and network. > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@gmx.net Tue Oct 22 08:54:34 2013 Return-Path: <hannes.tschofenig@gmx.net> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD2111E82D2 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 08:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdqVcaHARCjc for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 08:54:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id C304811E84CA for <ecrit@ietf.org>; Tue, 22 Oct 2013 08:54:23 -0700 (PDT) Received: from [172.16.254.200] ([80.92.115.161]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MMGWH-1VeONn20k9-0084k9 for <ecrit@ietf.org>; Tue, 22 Oct 2013 17:54:22 +0200 Message-ID: <52669FC8.4060009@gmx.net> Date: Tue, 22 Oct 2013 17:54:48 +0200 From: Hannes Tschofenig <hannes.tschofenig@gmx.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Brian Rosen <br@brianrosen.net>, James Winterbottom <a.james.winterbottom@gmail.com>, Christer Holmberg <christer.holmberg@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> In-Reply-To: <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:LetQrMhbeL1+OBJ4J86M43HJtmmh9J9OoicF3jLawv/u8tGpPAG IZyd+Q7O2Bbexm3vzNOOgeOsClCmFsxg0rKWESfKlmbDg5fI+moasqbBiIk149a3bCCNap8 DcjdAXz8/tDTsAvqSOPEOnwJPHm8nBcKAJxGPRu9O6GmOsHnaKihbudmCT8rK/kAhlCVXC/ hrdB4V2FmFOSa4d4WwD/Q== Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 15:54:34 -0000 Hi Christer, Brian, James, I believe you guys raised a couple of issues, namely: * Could we provide more and better examples? We have a number of examples in the document but we do not illustrate more complex versions. I am thinking about how to add a longer example. * Did we double-check whether there are any constraints regarding the number of blocks a single data provider can add and whether there are problems when multiple data provider add information? My suggestion is obvious: we have to double-check whether we introduced a bug. * Do we always have information about the source of the data provider? Brian claimed that we have lost that feature over time. I double-checked it and there is indeed some fuzziness in the text. Here is the relevant part: ------ 3.1. Data Provider Information This block is intended to be provided by any service provider in the path of the call or the access network provider. It includes identification and contact information. This block SHOULD be provided by every service provider in the call path, and by the access network provider. Devices MAY use this block to provide identifying information. The MIME subtype is "application/ emergencyCall.ProviderInfo+xml". An access network provider SHOULD provide this block either by value or by reference in the Provided-By section of a PIDF-LO ------ I believe I hear Brian saying that he wants to have the data provider block be added whenever data is added. I suggest the following modification: ------ 3.1. Data Provider Information This block MUST be provided by * any service provider in the path of the call, * the access network provider, and * the device, if these entities act as a source for additional data. The data provider information block offers identification and contact information of the data source The MIME subtype is "application/emergencyCall.ProviderInfo+xml". ------ What do you think? Ciao Hannes On 08/07/2013 02:52 PM, Brian Rosen wrote: > There is a requirement for multiple entities to add information. I > don't think there needs to be a requirement that it happen by value, but > its at least desirable. > > James, it's perfectly clear that some blocks need to be repeated For > example the block that says who provided the data. Others are more > specialized. So generically, it's a requirement that at least some > blocks are supplied by multiple enties. > > Brian > > On Wednesday, August 7, 2013, James Winterbottom wrote: > > Actually, I think that the requirement is more whether a single > entity should be able to add multiple types if information. > > Cheers > James > > Sent from my iPhone > > On 07/08/2013, at 4:32 PM, Christer Holmberg > <christer.holmberg@ericsson.com <javascript:;>> wrote: > > > Hi Brian, > > > >> Not sure pictures in ascii art would help, but more words might. > > > > I think some ascii art, showing the calling device (user or > sensor), some intermediary ("server") and the PSAP would help. > > > >> My usual example is a medical sensor based device adds some, a > specialized service provider who services the device adds some and a > communications service provider adds some. all of thise go in the > SIP message. then the access network sends some in the PIDF. > >> > >> With respect to multiple entities adding data, proxies can't add > bodies, but B2BUAs can. > > > > Well, that is protocol/solution talk - the question is whether > there is a REQUIREMENT that multiple entities should be able to add > information :) > > > > (If so, we then have to either mandate B2BUA functionality, or > use some other mechanism. For example, data that can be defined as > capabilities could be indicated also using feature capability > indicators.) > > > > Regards, > > > > Christer > > > > > > > > > > > > > > However, you have pointed out a problem that arose in the > evolution of the mechanism. Originally, there was an outer envelope > wit the blocks inside it. That would let us know the source of each > block because the data provider block is required. The current > mechanism doesn't have that. It's a problem. > > > > Brian > > > > On Tuesday, August 6, 2013, Christer Holmberg wrote: > > Hi, > > > > The draft talks about all kind of different entities that might > add additional data to an emergency call. > > > > First, I think it would be good to have some pictures showing a > few different scenarios. > > > > Second, the draft doesn't seem to describe the case where > multiple entities are adding data - for the same call. Will multiple > MIMEs etc be used, are there restrictions, etc etc etc? OR, is it > not allowed to begin with? > > > > Regards, > > > > Christer > > > > > > > > Sent from Windows using TouchDown (www.nitrodesk.com > <http://www.nitrodesk.com>) > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org <javascript:;> > > https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Tue Oct 22 11:30:24 2013 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051F311E820F for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 11:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.438 X-Spam-Level: X-Spam-Status: No, score=-103.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZFi6esZGB1R for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 11:30:19 -0700 (PDT) Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9B81F11E8231 for <ecrit@ietf.org>; Tue, 22 Oct 2013 11:30:12 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id f64so2220194yha.7 for <ecrit@ietf.org>; Tue, 22 Oct 2013 11:30:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=d21uK0t3Kp8TtagrV7iNuPFoNVbD8CUvBVwvl9vAYEg=; b=bBQQxoQj8ZFhZZ3KYjbfkMRZdbcT3lllQza1aXYoeqiswLVWgrdN+BB4eWvoWVRrYh ne/I63TXw/lF+ISBpMoRjHHwKmOpEAw/b3KbCTMFC6nHwniiFLYmOuDPpeQuV39R2Dig P8kdt5UCVgiECceVC6HGQCSjWwm443dDs6oOFEcwWrj7WBUZGJvWOvgzdhaz9istJF/x hiYFkb+0Rav55E5aotoudfoc7DT/uJanYQv7EiZcAx/zBDQG4JuVQ7W00J5S9H4dKNUb skA0r5cymv1aSLR+r4xiyl4HQqNEP3DUOfxHqSSIDJIInpwP7P7gXUGaEyDZC69ICHcg gL4g== X-Gm-Message-State: ALoCoQlGMMFYac1MqNerkDIU1Xyke+V8Or5q43AQEx6mm6rcE+4Z/YqV1dNqskWr0rgnQv50dD1c X-Received: by 10.236.38.74 with SMTP id z50mr1127340yha.134.1382466612024; Tue, 22 Oct 2013 11:30:12 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id r1sm38101307yhf.17.2013.10.22.11.30.10 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 11:30:11 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Rosen <br@brianrosen.net> In-Reply-To: <52669FC8.4060009@gmx.net> Date: Tue, 22 Oct 2013 14:30:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net> X-Mailer: Apple Mail (2.1510) Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 18:30:24 -0000 I don't think this is sufficient. I think there has to be a way to know = which data provider which block. What you have is: SP A provided some info SP B provided some info Info X, don't know who provided it Info Y, don't know who provided it Brian On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig = <Hannes.Tschofenig@gmx.net> wrote: > Hi Christer, Brian, James, >=20 > I believe you guys raised a couple of issues, namely: >=20 > * Could we provide more and better examples? We have a number of = examples in the document but we do not illustrate more complex versions. >=20 > I am thinking about how to add a longer example. >=20 > * Did we double-check whether there are any constraints regarding the = number of blocks a single data provider can add and whether there are = problems when multiple data provider add information? >=20 > My suggestion is obvious: we have to double-check whether we = introduced a bug. >=20 > * Do we always have information about the source of the data provider? = Brian claimed that we have lost that feature over time. I double-checked = it and there is indeed some fuzziness in the text. Here is the relevant = part: >=20 > ------ >=20 > 3.1. Data Provider Information >=20 > This block is intended to be provided by any service provider in the > path of the call or the access network provider. It includes > identification and contact information. This block SHOULD be > provided by every service provider in the call path, and by the > access network provider. Devices MAY use this block to provide > identifying information. The MIME subtype is "application/ > emergencyCall.ProviderInfo+xml". An access network provider SHOULD > provide this block either by value or by reference in the = Provided-By > section of a PIDF-LO >=20 > ------ >=20 > I believe I hear Brian saying that he wants to have the data provider = block be added whenever data is added. I suggest the following = modification: >=20 > ------ >=20 > 3.1. Data Provider Information >=20 > This block MUST be provided by > * any service provider in the path of the call, > * the access network provider, and > * the device, > if these entities act as a source for additional data. The data = provider information block offers identification and contact information = of the data source >=20 > The MIME subtype is "application/emergencyCall.ProviderInfo+xml". >=20 > ------ >=20 > What do you think? >=20 > Ciao > Hannes >=20 >=20 > On 08/07/2013 02:52 PM, Brian Rosen wrote: >> There is a requirement for multiple entities to add information. I >> don't think there needs to be a requirement that it happen by value, = but >> its at least desirable. >>=20 >> James, it's perfectly clear that some blocks need to be repeated For >> example the block that says who provided the data. Others are more >> specialized. So generically, it's a requirement that at least some >> blocks are supplied by multiple enties. >>=20 >> Brian >>=20 >> On Wednesday, August 7, 2013, James Winterbottom wrote: >>=20 >> Actually, I think that the requirement is more whether a single >> entity should be able to add multiple types if information. >>=20 >> Cheers >> James >>=20 >> Sent from my iPhone >>=20 >> On 07/08/2013, at 4:32 PM, Christer Holmberg >> <christer.holmberg@ericsson.com <javascript:;>> wrote: >>=20 >> > Hi Brian, >> > >> >> Not sure pictures in ascii art would help, but more words = might. >> > >> > I think some ascii art, showing the calling device (user or >> sensor), some intermediary ("server") and the PSAP would help. >> > >> >> My usual example is a medical sensor based device adds some, a >> specialized service provider who services the device adds some and = a >> communications service provider adds some. all of thise go in the >> SIP message. then the access network sends some in the PIDF. >> >> >> >> With respect to multiple entities adding data, proxies can't = add >> bodies, but B2BUAs can. >> > >> > Well, that is protocol/solution talk - the question is whether >> there is a REQUIREMENT that multiple entities should be able to = add >> information :) >> > >> > (If so, we then have to either mandate B2BUA functionality, or >> use some other mechanism. For example, data that can be defined as >> capabilities could be indicated also using feature capability >> indicators.) >> > >> > Regards, >> > >> > Christer >> > >> > >> > >> > >> > >> > >> > However, you have pointed out a problem that arose in the >> evolution of the mechanism. Originally, there was an outer = envelope >> wit the blocks inside it. That would let us know the source of = each >> block because the data provider block is required. The current >> mechanism doesn't have that. It's a problem. >> > >> > Brian >> > >> > On Tuesday, August 6, 2013, Christer Holmberg wrote: >> > Hi, >> > >> > The draft talks about all kind of different entities that might >> add additional data to an emergency call. >> > >> > First, I think it would be good to have some pictures showing a >> few different scenarios. >> > >> > Second, the draft doesn't seem to describe the case where >> multiple entities are adding data - for the same call. Will = multiple >> MIMEs etc be used, are there restrictions, etc etc etc? OR, is it >> not allowed to begin with? >> > >> > Regards, >> > >> > Christer >> > >> > >> > >> > Sent from Windows using TouchDown (www.nitrodesk.com >> <http://www.nitrodesk.com>) >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org <javascript:;> >> > https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 From christer.holmberg@ericsson.com Tue Oct 22 11:38:43 2013 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037CE11E8212 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 11:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vCXeSclrhd6 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 11:38:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 29CAA11E81CA for <ecrit@ietf.org>; Tue, 22 Oct 2013 11:38:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-1b-5266c619eb8e Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F0.61.16099.916C6625; Tue, 22 Oct 2013 20:38:17 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 20:38:16 +0200 From: Christer Holmberg <christer.holmberg@ericsson.com> To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Brian Rosen <br@brianrosen.net> Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 Thread-Index: Ac6Ss7RGKH4c9vYBRvaO2LXJyDkPv///67sAgHkGSYCAAFGQof///z2m Date: Tue, 22 Oct 2013 18:38:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EBC0C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41E829@ESESSMB209.ericsson.se> <CAOPrzE1SgvCGP8R2B=pUzz9KjPjOyHY-x4wHu-h4JP7FWUCVKQ@mail.gmail.com>, <52669D2B.8000402@gmx.net> In-Reply-To: <52669D2B.8000402@gmx.net> 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_7594FB04B1934943A5C02806D1A2204B1C4EBC0CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvja7ksbQggxtvxCye3p/GZtG46Cmr xdKd91gdmD3uf/vL7rF40342jyVLfjIFMEdx2aSk5mSWpRbp2yVwZdzfuYmlYId9xcp/s5ka GPeZdDFyckgImEic6XrLBGGLSVy4t56ti5GLQ0jgMKPE/yO3WCCcJYwSEzY2AWU4ONgELCS6 /2mDNIgIhEhMbNnNDGIzC6hKnGt8DFYvLLCWUeLVjM1MII6IwDpGibu3trFDdLhJHFi+gAXE ZgHquHB2NVg3r4CvxMl761lBbCGB9YwS088Ig9icAuoSew80gsUZgc77fmoNE8Q2cYlbT+ZD nS0gsWTPeWYIW1Ti5eN/rCCHSggoSUzbmgZRni/R2/OLBWKVoMTJmU9YJjCKzkIyaRaSsllI yiDiBhLvz81nhrC1JZYtfA1l60ts/HKWEcK2lri3YC0jspoFjByrGNlzEzNz0ssNNzECI/Dg lt+6OxhPnRM5xCjNwaIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbWx0EnT549 LDBn64NJnHftJj6+7PD6+oYpJS3afYXrj37ZNWGv6gP7yT2PTM781s2oNnSUk3FcdX9zxbwt y6dsYdu9bpKid15A6VENa56Ovd/uMnAXhM9w6BZkU5hcKn72kafcHZ3Z758khGn+9dn5aadl 31TLL7Ur1uuaHwy88+LKmp0qNu3uSizFGYmGWsxFxYkAcQe0tI4CAAA= Cc: "ecrit@ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possible conflict between language feature tag and data provider language, defined in section 3.1.6 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 18:38:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4EBC0CESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Hannes, When reading the description, I still don't see the difference: the media f= eature that also indicate the supported languages. But, if you could provide me with the full note (it seems like you didn't c= opy all text), maybe I'll understand better :) Regards, Christer ________________________________ From: Hannes Tschofenig [hannes.tschofenig@gmx.net] Sent: Tuesday, 22 October 2013 6:43 PM To: Brian Rosen; Christer Holmberg Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on possi= ble conflict between language feature tag and data provider language, defin= ed in section 3.1.6 Hi Christer, I agree with Brian's response and I added a few lines of text to clarify the relationship between the proposed element and the language tag. Here is the text: ----- 3.1.6. Data Provider Languages(s) Supported Data Element: Data Provider Language(s) supported Use: Required. XML Element: <Language> Description: The language used by the entity at the Data Provider Contact URI as an alpha 2-character code as defined in ISO 639-1:2002 Codes for the representation of names of languages -- Part 1: Alpha-2 code Multiple instances of this element may occur. Order is significant; preferred language should appear first. The content MUST reflect the languages supported at the contact URI. Note that the 'language' media feature tag, defined in RFC 3840 [RFC3840] and the more extensive language negotiation mechanism proposed with [I-D.gellens-negotiating-human-language] are ----- Is this OK for you? Do you think it will help to clarify? Ciao Hannes On 08/06/2013 05:33 PM, Brian Rosen wrote: > That feature is not the spoken or signed or typed language in the media. > There is an ongoing effort to provide a facility to negotiate those, > but even still, it's useful to know in advance of a call what languages > the service provider can handle. > > Brian > > On Tuesday, August 6, 2013, Christer Holmberg wrote: > > Hi,____ > > __ __ > > In SIP, it is possible to indicate supported languages using the > =93language=94 media feature tag, defined in RFC 3840.____ > > __ __ > > Is the semantics different from the data provider language defined > in the additional-data draft?____ > > __ __ > > Do we need to say something about which/how to use?____ > > __ __ > > Regards,____ > > __ __ > > Christer____ > > __ __ > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --_000_7594FB04B1934943A5C02806D1A2204B1C4EBC0CESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: <AF5F17C48CBA144AAC2A1D554AF9324C@ericsson.com> Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <!-- converted from text --> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <style>.EmailQuote {=0A= PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt; BORDER-LEFT: #800000 2px solid=0A= }=0A= </style><style id=3D"owaParaStyle">P {=0A= MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px=0A= }=0A= </style> </head> <body ocsi=3D"0" fpstyle=3D"1"> <div style=3D"color: rgb(0, 0, 0); font-family: Tahoma; font-size: 10pt; di= rection: ltr;"> <p>Hi Hannes,</p> <p> </p> <p>When reading the description, I still don't see the difference: the medi= a feature that also indicate the supported languages.</p> <p> </p> <p>But, if you could provide me with the full note (it seems like you didn'= t copy all text), maybe I'll understand better :)</p> <p> </p> <p>Regards,</p> <p> </p> <p>Christer</p> <p> </p> <div> <hr tabindex=3D"-1"> <div id=3D"x_divRplyFwdMsg"><font color=3D"#000000" face=3D"Tahoma" size=3D= "2"><b>From:</b> Hannes Tschofenig [hannes.tschofenig@gmx.net]<br> <b>Sent:</b> Tuesday, 22 October 2013 6:43 PM<br> <b>To:</b> Brian Rosen; Christer Holmberg<br> <b>Cc:</b> ecrit@ietf.org<br> <b>Subject:</b> Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n possible conflict between language feature tag and data provider language= , defined in section 3.1.6<br> </font><br> </div> <div></div> </div> <font size=3D"2"><span style=3D"font-size: 10pt;"> <div class=3D"PlainText">Hi Christer,<br> <br> I agree with Brian's response and I added a few lines of text to clarify <b= r> the relationship between the proposed element and the language tag.<br> <br> Here is the text:<br> <br> <br> -----<br> <br> <br> 3.1.6.  Data Provider Languages(s) Supported<br> <br>     Data Element:  Data Provider Language(s) supported<= br> <br>     Use:  Required.<br> <br>     XML Element:  <Language><br> <br>     Description:  The language used by the entity at th= e Data Provider<br>        Contact URI as an alpha 2-character co= de as defined in ISO<br>        639-1:2002 Codes for the representatio= n of names of languages --<br>        Part 1: Alpha-2 code Multiple instance= s of this element may occur.<br>        Order is significant; preferred langua= ge should appear first.  The<br>        content MUST reflect the languages sup= ported at the contact URI.<br> <br>        Note that the 'language' media feature= tag, defined in RFC 3840<br>        [RFC3840] and the more extensive langu= age negotiation mechanism<br>        proposed with [I-D.gellens-negotiating= -human-language] are<br> <br> -----<br> <br> Is this OK for you? Do you think it will help to clarify?<br> <br> Ciao<br> Hannes<br> <br> <br> <br> On 08/06/2013 05:33 PM, Brian Rosen wrote:<br> > That feature is not the spoken or signed or typed language in the medi= a.<br> >   There is an ongoing effort to provide a facility to negoti= ate those,<br> > but even still, it's useful to know in advance of a call what language= s<br> > the service provider can handle.<br> ><br> > Brian<br> ><br> > On Tuesday, August 6, 2013, Christer Holmberg wrote:<br> ><br> >     Hi,____<br> ><br> >     __ __<br> ><br> >     In SIP, it is possible to indicate supported l= anguages using the<br> >     =93language=94 media feature tag, defined in R= FC 3840.____<br> ><br> >     __ __<br> ><br> >     Is the semantics different from the data provi= der language defined<br> >     in the additional-data draft?____<br> ><br> >     __ __<br> ><br> >     Do we need to say something about which/how to= use?____<br> ><br> >     __ __<br> ><br> >     Regards,____<br> ><br> >     __ __<br> ><br> >     Christer____<br> ><br> >     __ __<br> ><br> ><br> ><br> > _______________________________________________<br> > Ecrit mailing list<br> > Ecrit@ietf.org<br> > <a href=3D"https://www.ietf.org/mailman/listinfo/ecrit" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/ecrit</a><br> ><br> <br> </div> </span></font></div> </body> </html> --_000_7594FB04B1934943A5C02806D1A2204B1C4EBC0CESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Oct 22 11:44:32 2013 Return-Path: <christer.holmberg@ericsson.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF5911E821A for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 11:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.623 X-Spam-Level: X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeJ875fzFQGo for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 11:44:21 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3D87411E82AA for <ecrit@ietf.org>; Tue, 22 Oct 2013 11:43:56 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-9a-5266c76a0131 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9B.FB.03802.A67C6625; Tue, 22 Oct 2013 20:43:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 20:43:54 +0200 From: Christer Holmberg <christer.holmberg@ericsson.com> To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Roger Marshall <RMarshall@telecomsys.com>, Brian Rosen <br@brianrosen.net> Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 Thread-Index: Ac6Sss0vFs+I00HHTNynzH+gXjYA8QBz4d9t///kzQCAAIy+2YAbnzOAgFlEhICAAFI4Af///tFk Date: Tue, 22 Oct 2013 18:43:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EBC2B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C41E812@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C422BC7@ESESSMB209.ericsson.se>, <CAOPrzE3XQGhXgH_zPpNDeLBrPb4hRUp2JefV2s9TqW1Ku0=RSA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C422DB7@ESESSMB209.ericsson.se> <FBD5AAFFD0978846BF6D3FAB4C892ACC3EDF01@SEA-EXMB-1.telecomsys.com>, <52669D95.8030501@gmx.net> In-Reply-To: <52669D95.8030501@gmx.net> 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_7594FB04B1934943A5C02806D1A2204B1C4EBC2BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3Rjf7eFqQwb4HnBZP709js2hc9JTV YunOe6wWh68uZXJg8bj/7S+7x+JN+9k8liz5yeSxYesp5gCWKC6blNSczLLUIn27BK6M/mdf WAqOZFecn7SNrYHxWmQXIweHhICJxMcG6S5GTiBTTOLCvfVsXYxcHEIChxkljrSuZodwljBK zP8+gQ2kgU3AQqL7nzZIg4hAvcSh4+uZQcLMAsoSJzrjQcLCAlUSV/5OYYQoqZbYcnQTI0iJ iECUxIIeFZAwi4CqxJWORSwgNq+Ar8Sifw9ZIDb9Z5J43P6WHSTBKaAu8fNJN9gcRqDbvp9a wwRiMwuIS9x6Mp8J4mYBiSV7zjND2KISLx//Y4V4S0li2tY0iPJ8iTmT50HtEpQ4OfMJywRG 0VlIJs1CUjYLSRlE3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hLv9x9kQ1azgJFjFSN7bmJm Tnq50SZGYDQe3PJbdQfjnXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cCYajJpRnGGTYDgt2rNFwvqTx5o7Z8lrBT6vcbk5QqGlCrt522JrysOMn38F9zNt+Ddi3tP rrx7XB/yK2ntvuQVLy6dXbVMzr4x/b/HlRUHNGYpPfC//ln5v1Xn+R1NTDfNDVXYO64v3xdu kZV2iEu39lPS1xiJqd7Lu1YeFFvCnBTq1KaZsE5FiaU4I9FQi7moOBEAjjw/zZQCAAA= Cc: "ecrit_ietf.org" <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope of the Contact URI, defined in section 3.1.5 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 18:44:33 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4EBC2BESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I would suggest that the contact information MUST NOT be used by the PSAP f= or callbacks, and also say that the reason is because the contact informati= on may not be associated with the user or the device that made the emergenc= y call. No need to mention the Priority header field, simply refer to the p= sap-callback draft. Something like: "Note that this contact information MUST NOT be used by PSAPs for callb= acks, as described in [I-D.ietf-ecrit-psap-callback], as the contact informat= ion might not be associated with the user or device that made the emergency call.= " Regards, Christer ________________________________ From: Hannes Tschofenig [hannes.tschofenig@gmx.net] Sent: Tuesday, 22 October 2013 6:45 PM To: Roger Marshall; Christer Holmberg; Brian Rosen Cc: ecrit_ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on scope= of the Contact URI, defined in section 3.1.5 Hi Christer, as discussed in this email thread I added text for clarification: ---- 3.1.5. Data Provider Contact URI Data Element: Data Provider Contact URI Use: Required XML Element: <ContactURI> Description: When provided by a service provider or an access provider, this information MUST be a URI to a 24/7 support organization tasked to provide PSAP support for this emergency call. If the call is from a device, this would reflect the contact information of the owner of the device. If a telephone number is the contact address then it MUST be tel URI. If it is provided as a SIP URI then it MUST be in the form of sip:telephonenumber@serviceprovider:user=3Dphone. Note that this contact information is not used by PSAPs for callbacks using a SIP Priority header field with the value set to "psap- callback", as described in [I-D.ietf-ecrit-psap-callback]. ---- Do you think that I managed to capture your concern? Ciao Hannes On 08/26/2013 10:33 PM, Roger Marshall wrote: > I agree with Christer=92s suggestion to add caution text. > > -roger. > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Christer Holmberg > *Sent:* Thursday, August 08, 2013 9:44 PM > *To:* Brian Rosen > *Cc:* ecrit_ietf.org > *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on > scope of the Contact URI, defined in section 3.1.5 > > Hi, > > If the PSAP is not supposed to use the field when/if making a callback, > I think we shall explicitly state that in the document, and/or in > general say that the field must not be used for calls that are expected > to be given priority/special handling, and give callback as an example. > > Regards, > > Christer > > > > Sent from */Windows/* using *TouchDown*(<http:///>www.nitrodesk.com > <http://www.nitrodesk.com<http://www.nitrodesk.com/>>) > > > -----Original Message----- > *From:* Brian Rosen [br@brianrosen.net] > *To:* Christer Holmberg [christer.holmberg@ericsson.com] > *CC:* ecrit_ietf.org [ecrit@ietf.org] > *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question on > scope of the Contact URI, defined in section 3.1.5 > > The Contact is how the PSAP contacts the service provider to get help > from the SP. > > It's not a "call back" in the sense of an emergency call (the network > doesn't treat it differently than a normal call), at least as far as I > have considered it. I suppose it might be nice to know that it's > important, but I don't think that is worth any big new mechanism. > > Brian > > > > On Thursday, August 8, 2013, Christer Holmberg wrote: > > I haven't seen any reply to this. Brian, do you have any opinion? > > Regards, > > Christer > > > > Sent from */Windows/* using *TouchDown* (<http:///>www.nitrodesk.com > <http://www.nitrodesk.com<http://www.nitrodesk.com/>>) > > > -----Original Message----- > *From:* Christer Holmberg [christer.holmberg@ericsson.com] > *To:* ecrit@ietf.org [ecrit@ietf.org] > *Subject:* [Ecrit] draft-ietf-ecrit-additional-data-11: Question on > scope of the Contact URI, defined in section 3.1.5 > > Hi, > > A question on the scope of the Contact URI, defined in section 3.1.5 of > draft-ietf-ecrit-additional-data-11.txt. > > Is the Contact URI supposed by the PSAP when making callbacks? > > If the value represents a =93service provider=94, should PSAP callbacks a= lso > be made to the service provider? > > Regards, > > Christer > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, > or responsible for delivering this message to the intended recipient, > any review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, > and delete it and all attachments from your computer and network. > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --_000_7594FB04B1934943A5C02806D1A2204B1C4EBC2BESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2E9EB1BE9508064FAC3E41E507DCC826@ericsson.com> Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <!-- converted from text --> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <style>.EmailQuote {=0A= PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt; BORDER-LEFT: #800000 2px solid=0A= }=0A= </style><style id=3D"owaParaStyle">P {=0A= MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px=0A= }=0A= </style> </head> <body ocsi=3D"0" fpstyle=3D"1"> <div style=3D"color: rgb(0, 0, 0); font-family: Tahoma; font-size: 10pt; di= rection: ltr;"> <p>Hi,</p> <p> </p> <p>I would suggest that the contact information MUST NOT be used by th= e PSAP for callbacks, and also say that the reason is because the contact i= nformation may not be associated with the user or the device that made the = emergency call. No need to mention the Priority header field, simply refer to the psap-callback draft.</p> <p> </p> <p>Something like:</p> <p> </p> <p>    "Note that this contact information MU= ST NOT be used by PSAPs for callbacks,</p> <p>    as described in [I-D.ietf-ecrit-psap-callback], = as the contact information might</p> <p>    not be associated with the user or device that m= ade the emergency call."</p> <p> </p> <p>Regards,</p> <p> </p> <p>Christer</p> <p> </p> <p> </p> <div> <hr tabindex=3D"-1"> <div id=3D"x_divRplyFwdMsg"><font color=3D"#000000" face=3D"Tahoma" size=3D= "2"><b>From:</b> Hannes Tschofenig [hannes.tschofenig@gmx.net]<br> <b>Sent:</b> Tuesday, 22 October 2013 6:45 PM<br> <b>To:</b> Roger Marshall; Christer Holmberg; Brian Rosen<br> <b>Cc:</b> ecrit_ietf.org<br> <b>Subject:</b> Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n scope of the Contact URI, defined in section 3.1.5<br> </font><br> </div> <div></div> </div> <font size=3D"2"><span style=3D"font-size: 10pt;"> <div class=3D"PlainText">Hi Christer,<br> <br> as discussed in this email thread I added text for clarification:<br> <br> ----<br> <br> 3.1.5.  Data Provider Contact URI<br> <br>     Data Element:  Data Provider Contact URI<br> <br>     Use:  Required<br> <br>     XML Element:  <ContactURI><br> <br>     Description:  When provided by a service provider o= r an access<br>        provider, this information MUST be a U= RI to a 24/7 support<br>        organization tasked to provide PSAP su= pport for this emergency<br>        call.  If the call is from a devi= ce, this would reflect the<br>        contact information of the owner of th= e device.  If a telephone<br>        number is the contact address then it = MUST be tel URI.  If it is<br>        provided as a SIP URI then it MUST be = in the form of<br>        sip:telephonenumber@serviceprovider:us= er=3Dphone.  Note that this<br>        contact information is not used by PSA= Ps for callbacks using a SIP<br>        Priority header field with the value s= et to "psap- callback", as<br>        described in [I-D.ietf-ecrit-psap-call= back].<br>         <br>         <br> ----<br> <br> <br> Do you think that I managed to capture your concern?<br> <br> Ciao<br> Hannes<br> <br> <br> On 08/26/2013 10:33 PM, Roger Marshall wrote:<br> > I agree with Christer=92s suggestion to add caution text.<br> ><br> > -roger.<br> ><br> > *From:*ecrit-bounces@ietf.org [<a href=3D"mailto:ecrit-bounces@ietf.or= g" target=3D"_blank">mailto:ecrit-bounces@ietf.org</a>] *On Behalf<br> > Of *Christer Holmberg<br> > *Sent:* Thursday, August 08, 2013 9:44 PM<br> > *To:* Brian Rosen<br> > *Cc:* ecrit_ietf.org<br> > *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n<br> > scope of the Contact URI, defined in section 3.1.5<br> ><br> > Hi,<br> ><br> > If the PSAP is not supposed to use the field when/if making a callback= ,<br> > I think we shall explicitly state that in the document, and/or in<br> > general say that the field must not be used for calls that are expecte= d<br> > to be given priority/special handling, and give callback as an example= .<br> ><br> > Regards,<br> ><br> > Christer<br> ><br> ><br> ><br> > Sent from */Windows/* using *TouchDown*(<a href=3D"http:///" target=3D= "_blank"></a>www.nitrodesk.com<br> > <<a href=3D"http://www.nitrodesk.com/" target=3D"_blank">http://www= .nitrodesk.com</a>>)<br> ><br> ><br> > -----Original Message-----<br> > *From:* Brian Rosen [br@brianrosen.net]<br> > *To:* Christer Holmberg [christer.holmberg@ericsson.com]<br> > *CC:* ecrit_ietf.org [ecrit@ietf.org]<br> > *Subject:* Re: [Ecrit] draft-ietf-ecrit-additional-data-11: Question o= n<br> > scope of the Contact URI, defined in section 3.1.5<br> ><br> > The Contact is how the PSAP contacts the service provider to get help<= br> > from the SP.<br> ><br> > It's not a "call back" in the sense of an emergency call (th= e network<br> > doesn't treat it differently than a normal call), at least as far as I= <br> > have considered it.  I suppose it might be nice to know that it's= <br> > important, but I don't think that is worth any big new mechanism.<br> ><br> > Brian<br> ><br> ><br> ><br> > On Thursday, August 8, 2013, Christer Holmberg wrote:<br> ><br> > I haven't seen any reply to this. Brian, do you have any opinion?<br> ><br> > Regards,<br> ><br> > Christer<br> ><br> ><br> ><br> > Sent from */Windows/* using *TouchDown* (<a href=3D"http:///" target= =3D"_blank"></a>www.nitrodesk.com<br> > <<a href=3D"http://www.nitrodesk.com/" target=3D"_blank">http://www= .nitrodesk.com</a>>)<br> ><br> ><br> > -----Original Message-----<br> > *From:* Christer Holmberg [christer.holmberg@ericsson.com]<br> > *To:* ecrit@ietf.org [ecrit@ietf.org]<br> > *Subject:* [Ecrit] draft-ietf-ecrit-additional-data-11: Question on<br= > > scope of the Contact URI, defined in section 3.1.5<br> ><br> > Hi,<br> ><br> > A question on the scope of the Contact URI, defined in section 3.1.5 o= f<br> > draft-ietf-ecrit-additional-data-11.txt.<br> ><br> > Is the Contact URI supposed by the PSAP when making callbacks?<br> ><br> > If the value represents a =93service provider=94, should PSAP callback= s also<br> > be made to the service provider?<br> ><br> > Regards,<br> ><br> > Christer<br> ><br> > CONFIDENTIALITY NOTICE: The information contained in this message may = be<br> > privileged and/or confidential. If you are not the intended recipient,= <br> > or responsible for delivering this message to the intended recipient,<= br> > any review, forwarding, dissemination, distribution or copying of this= <br> > communication or any attachment(s) is strictly prohibited. If you have= <br> > received this message in error, please notify the sender immediately,<= br> > and delete it and all attachments from your computer and network.<br> ><br> ><br> ><br> > _______________________________________________<br> > Ecrit mailing list<br> > Ecrit@ietf.org<br> > <a href=3D"https://www.ietf.org/mailman/listinfo/ecrit" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/ecrit</a><br> ><br> <br> </div> </span></font></div> </body> </html> --_000_7594FB04B1934943A5C02806D1A2204B1C4EBC2BESESSMB209erics_-- From brian.rosen@neustar.biz Tue Oct 22 12:06:01 2013 Return-Path: <brian.rosen@neustar.biz> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D0511E821F for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 12:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne7liiB9mRzV for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 12:05:39 -0700 (PDT) Received: from neustar.com (mx11.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0B07B11E823E for <ecrit@ietf.org>; Tue, 22 Oct 2013 12:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1382468543; x=1697805297; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=ee67LkQ+US ZTrqx7frIERSVMh+FRHB25tDNFN8D/6AE=; b=iD5PgLuGI+4svVkbajVvkheUA/ c8ruD53NMISm10rR51w7Z6kTUAbMOA3u0BjFIHxaHWA+v4wxAhGKpwfeNtvA== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.26446494; Tue, 22 Oct 2013 15:02:22 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 22 Oct 2013 15:03:00 -0400 From: "Rosen, Brian" <Brian.Rosen@neustar.biz> To: ecrit <ecrit@ietf.org> Thread-Topic: Can I get some love for draft-marshall-similar-location? Thread-Index: AQHOz1lT9rNNkqG9OUaVMTviEPzK+A== Date: Tue, 22 Oct 2013 19:03:00 +0000 Message-ID: <C75BAA65-73A6-4BEA-8D59-F827C505A5F1@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.35] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 3ArV3h/slFMBUnfOAJOqvw== Content-Type: text/plain; charset="Windows-1252" Content-ID: <6B4E577CA61F4D4096C9ACEFB196CC8B@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Can I get some love for draft-marshall-similar-location? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 19:06:01 -0000 <longEmail> I presented this draft in Berlin. There is some support for it, mostly fro= m the NENA guys. I think it's pretty helpful. It solves two problems. When you get a location that you want to put into a LIS, you should validat= e it BEFORE you use it for an emergency call. So, you send a LoST query an= d specify validation. What is valid? That's undoubtedly a national matter, but one way to look at it is that it'= s a set of elements in the LI that describes a UNIQUE location that respond= ers can respond to. A really simple case is a residence that is addressed = by a house number, a street name, a city name, a state/province, and a coun= try. Provided that the combination of these elements is the location of on= e house, it's probably valid. But, let's say that there is also a county in the name. I give you two sce= narios. In both scenarios, there are two municipalities with the same name= in the state/province, but they are in different counties. In one of the scenarios, the street name only occurs in one of the two muni= cipalities. In the other scenario, it's in both of them. So, if I send LI that does not have a county, does have the street and (dup= licated) municipality, in scenario one, is it valid? It is UNIQUE, you kno= w where it is, because there is no Apple Street in Hooverville, Baskin Coun= ty, but there is an Apple Street in Hooverville, Robbins County. Now, it is a national matter whether the LoST server accepts the lack of a = county name for scenario 1. In most areas I am familiar with, County is no= t required unless it's needed to differentiate as it is in Scenario 2. But, the LoST server does know what the County is, and even in Scenario 1, = it might be a really good idea to confirm with the user entering the addres= s that the address is in Robbins County. In the current RFC5222 definition of LoST, there is no way for the server t= o return the County name. In Scenario 2, it would return County on the inv= alid list, indicating that County was missing, and needs to be provided. B= ut in Scenario 1, it could either do the same (always require County, even = if the address is unique without it), or just return Country, State, Street= and House Number as valid. What the draft does is extend LoST to allow it to return LI to inform the q= uerier that this address is valid, and is in Robbins County. That lets the= LIS confirm with the user, and it also let's it populate the LIS entry wit= h the County, which is a good thing to do if it is confirmed by the user. The other problem it solves is how to help the user in Scenario 2. The que= ry presented has invalid LI, and the response will indicate that County is = invalid. But, the only thing the LIS can do is demand that the user some h= ow come up with the name of the County. A better response would be that the LI given is invalid, but it could be ei= ther 124 Apple St, Hooverville, Baskin County, NJ, US or it could be 124 Ap= ple St, Hooverville, Robbins County, NJ, US. That is, it could offer one o= r more valid addresses as possible candidates for the LI that was offered i= n the query. The LoST server may not be able to return a small number of valid locations= the LI in the query suggests, but if it could, a response of "not that, bu= t could it be =85.?" is very useful. This also requires that the LoST server return LI. We'd really like to push this draft through ecrit. NENA does really need i= t, and we think it's generally useful for many countries. Can I get some love here? </longEmail> Brian= From a.james.winterbottom@gmail.com Tue Oct 22 12:17:10 2013 Return-Path: <a.james.winterbottom@gmail.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B3821F9D12 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 12:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2NLXxsH7BEU for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 12:17:01 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3260021F9BBD for <ecrit@ietf.org>; Tue, 22 Oct 2013 12:16:19 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so10320799pad.33 for <ecrit@ietf.org>; Tue, 22 Oct 2013 12:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=nIDcxeDxRsneMRQDgHN0F6iakUG6X6iuS9CP0RQX29A=; b=W8Nv1nmTyxj2u7+x8sbeCNuJFRkMUk1oLzuEMWV1hfmX5tjeufL2IZuYZIKW3HCG/g VjpB22mFm0uN0GsGxSugeDpxrZxszfwnDobu1p1v2Cpb4gHzYrxvWO0tVLvaQee7HYk8 x2ODTbDvSayfOIbJSiE9LSJ42xL0sxYK7E2FmcZ1Bc2CVmVTF6fnMwxb1yz46VV0befE 408Ra3eRcy2O3NjkGMNkgyIjTqEvcyTgd42YSM1/DjE0nafNbpUmZCG5R6RASIY6U6sI LlHnFeaEJCpUUVAW6JCTAdCgFH3cizVT1XXm0u4TCrD5JCBJrR7NkRk2EU/l4HZtCDUK UNwg== X-Received: by 10.68.235.72 with SMTP id uk8mr24592125pbc.93.1382469378886; Tue, 22 Oct 2013 12:16:18 -0700 (PDT) Received: from [192.168.1.14] (124-149-67-181.dyn.iinet.net.au. [124.149.67.181]) by mx.google.com with ESMTPSA id fb3sm29282859pbc.29.2013.10.22.12.16.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 12:16:17 -0700 (PDT) References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> Mime-Version: 1.0 (1.0) In-Reply-To: <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> X-Mailer: iPad Mail (10B329) From: James Winterbottom <a.james.winterbottom@gmail.com> Date: Wed, 23 Oct 2013 06:16:15 +1100 To: Brian Rosen <br@brianrosen.net> Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 19:17:12 -0000 One way to do that is through schema structure and constraints. Sent from my iPad On 23/10/2013, at 5:30 AM, Brian Rosen <br@brianrosen.net> wrote: > I don't think this is sufficient. I think there has to be a way to know w= hich data provider which block. >=20 > What you have is: > SP A provided some info > SP B provided some info > Info X, don't know who provided it > Info Y, don't know who provided it >=20 > Brian >=20 > On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net= > wrote: >=20 >> Hi Christer, Brian, James, >>=20 >> I believe you guys raised a couple of issues, namely: >>=20 >> * Could we provide more and better examples? We have a number of examples= in the document but we do not illustrate more complex versions. >>=20 >> I am thinking about how to add a longer example. >>=20 >> * Did we double-check whether there are any constraints regarding the num= ber of blocks a single data provider can add and whether there are problems w= hen multiple data provider add information? >>=20 >> My suggestion is obvious: we have to double-check whether we introduced a= bug. >>=20 >> * Do we always have information about the source of the data provider? Br= ian claimed that we have lost that feature over time. I double-checked it an= d there is indeed some fuzziness in the text. Here is the relevant part: >>=20 >> ------ >>=20 >> 3.1. Data Provider Information >>=20 >> This block is intended to be provided by any service provider in the >> path of the call or the access network provider. It includes >> identification and contact information. This block SHOULD be >> provided by every service provider in the call path, and by the >> access network provider. Devices MAY use this block to provide >> identifying information. The MIME subtype is "application/ >> emergencyCall.ProviderInfo+xml". An access network provider SHOULD >> provide this block either by value or by reference in the Provided-By >> section of a PIDF-LO >>=20 >> ------ >>=20 >> I believe I hear Brian saying that he wants to have the data provider blo= ck be added whenever data is added. I suggest the following modification: >>=20 >> ------ >>=20 >> 3.1. Data Provider Information >>=20 >> This block MUST be provided by >> * any service provider in the path of the call, >> * the access network provider, and >> * the device, >> if these entities act as a source for additional data. The data provider= information block offers identification and contact information of the data= source >>=20 >> The MIME subtype is "application/emergencyCall.ProviderInfo+xml". >>=20 >> ------ >>=20 >> What do you think? >>=20 >> Ciao >> Hannes >>=20 >>=20 >> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>> There is a requirement for multiple entities to add information. I >>> don't think there needs to be a requirement that it happen by value, but= >>> its at least desirable. >>>=20 >>> James, it's perfectly clear that some blocks need to be repeated For >>> example the block that says who provided the data. Others are more >>> specialized. So generically, it's a requirement that at least some >>> blocks are supplied by multiple enties. >>>=20 >>> Brian >>>=20 >>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>=20 >>> Actually, I think that the requirement is more whether a single >>> entity should be able to add multiple types if information. >>>=20 >>> Cheers >>> James >>>=20 >>> Sent from my iPhone >>>=20 >>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>> <christer.holmberg@ericsson.com <javascript:;>> wrote: >>>=20 >>>> Hi Brian, >>>>=20 >>>>> Not sure pictures in ascii art would help, but more words might. >>>>=20 >>>> I think some ascii art, showing the calling device (user or >>> sensor), some intermediary ("server") and the PSAP would help. >>>>=20 >>>>> My usual example is a medical sensor based device adds some, a >>> specialized service provider who services the device adds some and a >>> communications service provider adds some. all of thise go in the >>> SIP message. then the access network sends some in the PIDF. >>>>>=20 >>>>> With respect to multiple entities adding data, proxies can't add >>> bodies, but B2BUAs can. >>>>=20 >>>> Well, that is protocol/solution talk - the question is whether >>> there is a REQUIREMENT that multiple entities should be able to add >>> information :) >>>>=20 >>>> (If so, we then have to either mandate B2BUA functionality, or >>> use some other mechanism. For example, data that can be defined as >>> capabilities could be indicated also using feature capability >>> indicators.) >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> However, you have pointed out a problem that arose in the >>> evolution of the mechanism. Originally, there was an outer envelope >>> wit the blocks inside it. That would let us know the source of each >>> block because the data provider block is required. The current >>> mechanism doesn't have that. It's a problem. >>>>=20 >>>> Brian >>>>=20 >>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>> Hi, >>>>=20 >>>> The draft talks about all kind of different entities that might >>> add additional data to an emergency call. >>>>=20 >>>> First, I think it would be good to have some pictures showing a >>> few different scenarios. >>>>=20 >>>> Second, the draft doesn't seem to describe the case where >>> multiple entities are adding data - for the same call. Will multiple >>> MIMEs etc be used, are there restrictions, etc etc etc? OR, is it >>> not allowed to begin with? >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>> Sent from Windows using TouchDown (www.nitrodesk.com >>> <http://www.nitrodesk.com>) >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org <javascript:;> >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >=20 From br@brianrosen.net Tue Oct 22 12:21:29 2013 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA9021F9DD0 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 12:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.45 X-Spam-Level: X-Spam-Status: No, score=-103.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPVtHvkn2FND for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 12:21:24 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1E11111E810A for <ecrit@ietf.org>; Tue, 22 Oct 2013 12:21:22 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id j15so3615898qaq.13 for <ecrit@ietf.org>; Tue, 22 Oct 2013 12:21:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=pS1j92DuhYmHly9hv+it/9zhUU5UC6GFZlmdzEq8qd4=; b=FyODR8tGIy8SILhnf8w39USfQOvZ8szBiEn1Hqu0u3zP6FxkOeCnkdTdbzJJq2ltup 3ocsqRIUmOQ+yddubi142jwfhaVd/IUBYVS9myxhnAPJlVI5gDFM0L264GGVg4pB5TYK Dklk4ollHiiHJwhkCgV2Pmw2Z6Nk19uoK/ZMdg5gLiqLSFL9rawBYsHh4yvcKY3HUvHr 7XEyxB9CRKF7I1f1bP8Py4xjeh8V6RX3N5F1xXDS/ywQFNJizxiimQnSk68jrUjApwDI syUkBUloRHtrIZa/6Bne9uXO2NFK5c7Q7m0ccHlYeqdHbpOF2icdv26DvsXEzwSDK5Yf j/Bw== X-Gm-Message-State: ALoCoQmRO05WOYTVBcFx3dVeHZTShbGO9Cg+qCLeKElCh/PJnCtdOApQWrPJS2jgQkj+uqYTCB0M X-Received: by 10.49.94.226 with SMTP id df2mr32100270qeb.76.1382469681509; Tue, 22 Oct 2013 12:21:21 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id fx6sm45106523qeb.1.2013.10.22.12.21.20 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 12:21:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Rosen <br@brianrosen.net> In-Reply-To: <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> Date: Tue, 22 Oct 2013 15:21:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> To: James Winterbottom <a.james.winterbottom@gmail.com> X-Mailer: Apple Mail (2.1510) Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 19:21:29 -0000 I would be inclined to have a "source" attribute in every block, which = could be matched. It could contain any globally unique string (such as = a domain name) that labels the source of each block. Brian On Oct 22, 2013, at 3:16 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: > One way to do that is through schema structure and constraints. >=20 >=20 > Sent from my iPad >=20 > On 23/10/2013, at 5:30 AM, Brian Rosen <br@brianrosen.net> wrote: >=20 >> I don't think this is sufficient. I think there has to be a way to = know which data provider which block. >>=20 >> What you have is: >> SP A provided some info >> SP B provided some info >> Info X, don't know who provided it >> Info Y, don't know who provided it >>=20 >> Brian >>=20 >> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig = <Hannes.Tschofenig@gmx.net> wrote: >>=20 >>> Hi Christer, Brian, James, >>>=20 >>> I believe you guys raised a couple of issues, namely: >>>=20 >>> * Could we provide more and better examples? We have a number of = examples in the document but we do not illustrate more complex versions. >>>=20 >>> I am thinking about how to add a longer example. >>>=20 >>> * Did we double-check whether there are any constraints regarding = the number of blocks a single data provider can add and whether there = are problems when multiple data provider add information? >>>=20 >>> My suggestion is obvious: we have to double-check whether we = introduced a bug. >>>=20 >>> * Do we always have information about the source of the data = provider? Brian claimed that we have lost that feature over time. I = double-checked it and there is indeed some fuzziness in the text. Here = is the relevant part: >>>=20 >>> ------ >>>=20 >>> 3.1. Data Provider Information >>>=20 >>> This block is intended to be provided by any service provider in the >>> path of the call or the access network provider. It includes >>> identification and contact information. This block SHOULD be >>> provided by every service provider in the call path, and by the >>> access network provider. Devices MAY use this block to provide >>> identifying information. The MIME subtype is "application/ >>> emergencyCall.ProviderInfo+xml". An access network provider SHOULD >>> provide this block either by value or by reference in the = Provided-By >>> section of a PIDF-LO >>>=20 >>> ------ >>>=20 >>> I believe I hear Brian saying that he wants to have the data = provider block be added whenever data is added. I suggest the following = modification: >>>=20 >>> ------ >>>=20 >>> 3.1. Data Provider Information >>>=20 >>> This block MUST be provided by >>> * any service provider in the path of the call, >>> * the access network provider, and >>> * the device, >>> if these entities act as a source for additional data. The data = provider information block offers identification and contact information = of the data source >>>=20 >>> The MIME subtype is "application/emergencyCall.ProviderInfo+xml". >>>=20 >>> ------ >>>=20 >>> What do you think? >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>> There is a requirement for multiple entities to add information. I >>>> don't think there needs to be a requirement that it happen by = value, but >>>> its at least desirable. >>>>=20 >>>> James, it's perfectly clear that some blocks need to be repeated = For >>>> example the block that says who provided the data. Others are more >>>> specialized. So generically, it's a requirement that at least some >>>> blocks are supplied by multiple enties. >>>>=20 >>>> Brian >>>>=20 >>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>=20 >>>> Actually, I think that the requirement is more whether a single >>>> entity should be able to add multiple types if information. >>>>=20 >>>> Cheers >>>> James >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>> <christer.holmberg@ericsson.com <javascript:;>> wrote: >>>>=20 >>>>> Hi Brian, >>>>>=20 >>>>>> Not sure pictures in ascii art would help, but more words might. >>>>>=20 >>>>> I think some ascii art, showing the calling device (user or >>>> sensor), some intermediary ("server") and the PSAP would help. >>>>>=20 >>>>>> My usual example is a medical sensor based device adds some, a >>>> specialized service provider who services the device adds some and = a >>>> communications service provider adds some. all of thise go in the >>>> SIP message. then the access network sends some in the PIDF. >>>>>>=20 >>>>>> With respect to multiple entities adding data, proxies can't add >>>> bodies, but B2BUAs can. >>>>>=20 >>>>> Well, that is protocol/solution talk - the question is whether >>>> there is a REQUIREMENT that multiple entities should be able to = add >>>> information :) >>>>>=20 >>>>> (If so, we then have to either mandate B2BUA functionality, or >>>> use some other mechanism. For example, data that can be defined as >>>> capabilities could be indicated also using feature capability >>>> indicators.) >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> However, you have pointed out a problem that arose in the >>>> evolution of the mechanism. Originally, there was an outer = envelope >>>> wit the blocks inside it. That would let us know the source of = each >>>> block because the data provider block is required. The current >>>> mechanism doesn't have that. It's a problem. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>> Hi, >>>>>=20 >>>>> The draft talks about all kind of different entities that might >>>> add additional data to an emergency call. >>>>>=20 >>>>> First, I think it would be good to have some pictures showing a >>>> few different scenarios. >>>>>=20 >>>>> Second, the draft doesn't seem to describe the case where >>>> multiple entities are adding data - for the same call. Will = multiple >>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, is it >>>> not allowed to begin with? >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>> <http://www.nitrodesk.com>) >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org <javascript:;> >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 From a.james.winterbottom@gmail.com Tue Oct 22 13:17:29 2013 Return-Path: <a.james.winterbottom@gmail.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A0C11E8248 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 13:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id behTeZ0ccZz5 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 13:17:29 -0700 (PDT) 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 AFCF721F9A6D for <ecrit@ietf.org>; Tue, 22 Oct 2013 13:17:24 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id up7so284085pbc.26 for <ecrit@ietf.org>; Tue, 22 Oct 2013 13:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=E7upRWWpEcHm5E38C81y4v3XwsSBCf6LPbcsuE4mlHw=; b=0YJUhyrUD2wNtQIyBGX/M2YcmJIfYBQOvQHjnhCgP618bAty3qPIGkPCx/GJgpyNSJ ZJ5jHp+y9MFrlwGooxdRM/0izx/sa40pibq78zfRNzsFgCgVCqcVFBTPiUhmzBhloNQf Nw9RHlo+s0c6FF/E/uWPczOhiXyQ6tn0jMJjQ2y4QXa/zCeBCaWa0uvzWlWcuBINuEtb Z2yajbO2liMM9OaRkaLjAh//pfqJLRlr8LOFBkP54wqawS8wEvGyMx4mTpUD7MmLLX6J di1z6G2DMmJ9HAhmtZAv4X8MfqhRU2IN8Hju45Z5c7RFRsstupjTS1r0NI4M//HFrREM syOw== X-Received: by 10.68.219.167 with SMTP id pp7mr10524797pbc.125.1382473040164; Tue, 22 Oct 2013 13:17:20 -0700 (PDT) Received: from [192.168.1.14] (124-149-67-181.dyn.iinet.net.au. [124.149.67.181]) by mx.google.com with ESMTPSA id f2sm29447253pbg.44.2013.10.22.13.17.17 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 13:17:19 -0700 (PDT) References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> Mime-Version: 1.0 (1.0) In-Reply-To: <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> X-Mailer: iPad Mail (10B329) From: James Winterbottom <a.james.winterbottom@gmail.com> Date: Wed, 23 Oct 2013 07:17:17 +1100 To: Brian Rosen <br@brianrosen.net> Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 20:17:30 -0000 I think that that is more brittle. If the requirement is that the data provided be firmly linked to source then= tie them together more tightly. Sent from my iPad On 23/10/2013, at 6:21 AM, Brian Rosen <br@brianrosen.net> wrote: > I would be inclined to have a "source" attribute in every block, which cou= ld be matched. It could contain any globally unique string (such as a domai= n name) that labels the source of each block. >=20 > Brian >=20 > On Oct 22, 2013, at 3:16 PM, James Winterbottom <a.james.winterbottom@gmai= l.com> wrote: >=20 >> One way to do that is through schema structure and constraints. >>=20 >>=20 >> Sent from my iPad >>=20 >> On 23/10/2013, at 5:30 AM, Brian Rosen <br@brianrosen.net> wrote: >>=20 >>> I don't think this is sufficient. I think there has to be a way to know= which data provider which block. >>>=20 >>> What you have is: >>> SP A provided some info >>> SP B provided some info >>> Info X, don't know who provided it >>> Info Y, don't know who provided it >>>=20 >>> Brian >>>=20 >>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.n= et> wrote: >>>=20 >>>> Hi Christer, Brian, James, >>>>=20 >>>> I believe you guys raised a couple of issues, namely: >>>>=20 >>>> * Could we provide more and better examples? We have a number of exampl= es in the document but we do not illustrate more complex versions. >>>>=20 >>>> I am thinking about how to add a longer example. >>>>=20 >>>> * Did we double-check whether there are any constraints regarding the n= umber of blocks a single data provider can add and whether there are problem= s when multiple data provider add information? >>>>=20 >>>> My suggestion is obvious: we have to double-check whether we introduced= a bug. >>>>=20 >>>> * Do we always have information about the source of the data provider? B= rian claimed that we have lost that feature over time. I double-checked it a= nd there is indeed some fuzziness in the text. Here is the relevant part: >>>>=20 >>>> ------ >>>>=20 >>>> 3.1. Data Provider Information >>>>=20 >>>> This block is intended to be provided by any service provider in the >>>> path of the call or the access network provider. It includes >>>> identification and contact information. This block SHOULD be >>>> provided by every service provider in the call path, and by the >>>> access network provider. Devices MAY use this block to provide >>>> identifying information. The MIME subtype is "application/ >>>> emergencyCall.ProviderInfo+xml". An access network provider SHOULD >>>> provide this block either by value or by reference in the Provided-By >>>> section of a PIDF-LO >>>>=20 >>>> ------ >>>>=20 >>>> I believe I hear Brian saying that he wants to have the data provider b= lock be added whenever data is added. I suggest the following modification: >>>>=20 >>>> ------ >>>>=20 >>>> 3.1. Data Provider Information >>>>=20 >>>> This block MUST be provided by >>>> * any service provider in the path of the call, >>>> * the access network provider, and >>>> * the device, >>>> if these entities act as a source for additional data. The data provid= er information block offers identification and contact information of the da= ta source >>>>=20 >>>> The MIME subtype is "application/emergencyCall.ProviderInfo+xml". >>>>=20 >>>> ------ >>>>=20 >>>> What do you think? >>>>=20 >>>> Ciao >>>> Hannes >>>>=20 >>>>=20 >>>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>>> There is a requirement for multiple entities to add information. I >>>>> don't think there needs to be a requirement that it happen by value, b= ut >>>>> its at least desirable. >>>>>=20 >>>>> James, it's perfectly clear that some blocks need to be repeated For >>>>> example the block that says who provided the data. Others are more >>>>> specialized. So generically, it's a requirement that at least some >>>>> blocks are supplied by multiple enties. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>=20 >>>>> Actually, I think that the requirement is more whether a single >>>>> entity should be able to add multiple types if information. >>>>>=20 >>>>> Cheers >>>>> James >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>> <christer.holmberg@ericsson.com <javascript:;>> wrote: >>>>>=20 >>>>>> Hi Brian, >>>>>>=20 >>>>>>> Not sure pictures in ascii art would help, but more words might. >>>>>>=20 >>>>>> I think some ascii art, showing the calling device (user or >>>>> sensor), some intermediary ("server") and the PSAP would help. >>>>>>=20 >>>>>>> My usual example is a medical sensor based device adds some, a >>>>> specialized service provider who services the device adds some and a >>>>> communications service provider adds some. all of thise go in the >>>>> SIP message. then the access network sends some in the PIDF. >>>>>>>=20 >>>>>>> With respect to multiple entities adding data, proxies can't add >>>>> bodies, but B2BUAs can. >>>>>>=20 >>>>>> Well, that is protocol/solution talk - the question is whether >>>>> there is a REQUIREMENT that multiple entities should be able to add >>>>> information :) >>>>>>=20 >>>>>> (If so, we then have to either mandate B2BUA functionality, or >>>>> use some other mechanism. For example, data that can be defined as >>>>> capabilities could be indicated also using feature capability >>>>> indicators.) >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> However, you have pointed out a problem that arose in the >>>>> evolution of the mechanism. Originally, there was an outer envelope >>>>> wit the blocks inside it. That would let us know the source of each >>>>> block because the data provider block is required. The current >>>>> mechanism doesn't have that. It's a problem. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>> Hi, >>>>>>=20 >>>>>> The draft talks about all kind of different entities that might >>>>> add additional data to an emergency call. >>>>>>=20 >>>>>> First, I think it would be good to have some pictures showing a >>>>> few different scenarios. >>>>>>=20 >>>>>> Second, the draft doesn't seem to describe the case where >>>>> multiple entities are adding data - for the same call. Will multiple >>>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, is it >>>>> not allowed to begin with? >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>> <http://www.nitrodesk.com>) >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org <javascript:;> >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >=20 From br@brianrosen.net Tue Oct 22 13:51:42 2013 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BB511E8282 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 13:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBiQ0ZEDaZPk for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 13:51:37 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7100911E8264 for <ecrit@ietf.org>; Tue, 22 Oct 2013 13:51:37 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 8so5183273qea.32 for <ecrit@ietf.org>; Tue, 22 Oct 2013 13:51:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cFChMSsazUFwzONd32N8md4Hah5V+BV462cqTho03Cw=; b=jKVNudGnQWu4lMfe7j3msyUVahEd/3I3tNOW66rfYhuAGiDKFajzhjdkYagzj5D7wS U6J0zmOW0yvRIzi8997P9YGUcjXbILOKDKyGRo8NguAE4E7EOGS8QvjZzz1+r4MGdwt2 HKTJp0em/rQjrJGGMj7irKeSJtOBku2I+3rbREQemN7w1wTG0+qdhckZrhvMwGxV8g3B 5UFJ5wo31GcFyjbt2YZ45ERHCzTIXsx6RgDB5fa+t3sex8QJqPMfkJlxCJBxq8e792vR N81jGbFAqYkTYd6F0JKhohotn68YxzenMtARUddHlAstbebti9t4wThniblt2qSwTXwl Jx6A== X-Gm-Message-State: ALoCoQmj7sNaW3ZaLy/D/Sw7k+/71EO0lr2912er1Q+Fhq1Swmu7l5Bh96Fh6CeexvOeNO77qEZn X-Received: by 10.224.131.72 with SMTP id w8mr33427659qas.82.1382475094522; Tue, 22 Oct 2013 13:51:34 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id n7sm53653961qai.1.2013.10.22.13.51.33 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 13:51:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Rosen <br@brianrosen.net> In-Reply-To: <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> Date: Tue, 22 Oct 2013 16:51:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> To: James Winterbottom <a.james.winterbottom@gmail.com> X-Mailer: Apple Mail (2.1510) Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 20:51:42 -0000 By "fixing" the data structure to be a series of blocks, each with it's = own MIME type and schema, you can't really group them in useful ways. When I did the original, a given set of data from one source was one = object, and you could have more than one such object in the body, or = more than one URI to an entire object in the Call-Info. When we split = it up into blocks, we lost the ability to group. We could try doing something with mime/multipart hierarchy. I don't = know what is possible. I don't think requiring all blocks from the same = source to have a unique ID in them is brittle. Brian On Oct 22, 2013, at 4:17 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: > I think that that is more brittle. > If the requirement is that the data provided be firmly linked to = source then tie them together more tightly. >=20 >=20 >=20 > Sent from my iPad >=20 > On 23/10/2013, at 6:21 AM, Brian Rosen <br@brianrosen.net> wrote: >=20 >> I would be inclined to have a "source" attribute in every block, = which could be matched. It could contain any globally unique string = (such as a domain name) that labels the source of each block. >>=20 >> Brian >>=20 >> On Oct 22, 2013, at 3:16 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>=20 >>> One way to do that is through schema structure and constraints. >>>=20 >>>=20 >>> Sent from my iPad >>>=20 >>> On 23/10/2013, at 5:30 AM, Brian Rosen <br@brianrosen.net> wrote: >>>=20 >>>> I don't think this is sufficient. I think there has to be a way to = know which data provider which block. >>>>=20 >>>> What you have is: >>>> SP A provided some info >>>> SP B provided some info >>>> Info X, don't know who provided it >>>> Info Y, don't know who provided it >>>>=20 >>>> Brian >>>>=20 >>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig = <Hannes.Tschofenig@gmx.net> wrote: >>>>=20 >>>>> Hi Christer, Brian, James, >>>>>=20 >>>>> I believe you guys raised a couple of issues, namely: >>>>>=20 >>>>> * Could we provide more and better examples? We have a number of = examples in the document but we do not illustrate more complex versions. >>>>>=20 >>>>> I am thinking about how to add a longer example. >>>>>=20 >>>>> * Did we double-check whether there are any constraints regarding = the number of blocks a single data provider can add and whether there = are problems when multiple data provider add information? >>>>>=20 >>>>> My suggestion is obvious: we have to double-check whether we = introduced a bug. >>>>>=20 >>>>> * Do we always have information about the source of the data = provider? Brian claimed that we have lost that feature over time. I = double-checked it and there is indeed some fuzziness in the text. Here = is the relevant part: >>>>>=20 >>>>> ------ >>>>>=20 >>>>> 3.1. Data Provider Information >>>>>=20 >>>>> This block is intended to be provided by any service provider in = the >>>>> path of the call or the access network provider. It includes >>>>> identification and contact information. This block SHOULD be >>>>> provided by every service provider in the call path, and by the >>>>> access network provider. Devices MAY use this block to provide >>>>> identifying information. The MIME subtype is "application/ >>>>> emergencyCall.ProviderInfo+xml". An access network provider = SHOULD >>>>> provide this block either by value or by reference in the = Provided-By >>>>> section of a PIDF-LO >>>>>=20 >>>>> ------ >>>>>=20 >>>>> I believe I hear Brian saying that he wants to have the data = provider block be added whenever data is added. I suggest the following = modification: >>>>>=20 >>>>> ------ >>>>>=20 >>>>> 3.1. Data Provider Information >>>>>=20 >>>>> This block MUST be provided by >>>>> * any service provider in the path of the call, >>>>> * the access network provider, and >>>>> * the device, >>>>> if these entities act as a source for additional data. The data = provider information block offers identification and contact information = of the data source >>>>>=20 >>>>> The MIME subtype is "application/emergencyCall.ProviderInfo+xml". >>>>>=20 >>>>> ------ >>>>>=20 >>>>> What do you think? >>>>>=20 >>>>> Ciao >>>>> Hannes >>>>>=20 >>>>>=20 >>>>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>>>> There is a requirement for multiple entities to add information. = I >>>>>> don't think there needs to be a requirement that it happen by = value, but >>>>>> its at least desirable. >>>>>>=20 >>>>>> James, it's perfectly clear that some blocks need to be repeated = For >>>>>> example the block that says who provided the data. Others are = more >>>>>> specialized. So generically, it's a requirement that at least = some >>>>>> blocks are supplied by multiple enties. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>>=20 >>>>>> Actually, I think that the requirement is more whether a single >>>>>> entity should be able to add multiple types if information. >>>>>>=20 >>>>>> Cheers >>>>>> James >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>>> <christer.holmberg@ericsson.com <javascript:;>> wrote: >>>>>>=20 >>>>>>> Hi Brian, >>>>>>>=20 >>>>>>>> Not sure pictures in ascii art would help, but more words = might. >>>>>>>=20 >>>>>>> I think some ascii art, showing the calling device (user or >>>>>> sensor), some intermediary ("server") and the PSAP would help. >>>>>>>=20 >>>>>>>> My usual example is a medical sensor based device adds some, a >>>>>> specialized service provider who services the device adds some = and a >>>>>> communications service provider adds some. all of thise go in = the >>>>>> SIP message. then the access network sends some in the PIDF. >>>>>>>>=20 >>>>>>>> With respect to multiple entities adding data, proxies can't = add >>>>>> bodies, but B2BUAs can. >>>>>>>=20 >>>>>>> Well, that is protocol/solution talk - the question is whether >>>>>> there is a REQUIREMENT that multiple entities should be able to = add >>>>>> information :) >>>>>>>=20 >>>>>>> (If so, we then have to either mandate B2BUA functionality, or >>>>>> use some other mechanism. For example, data that can be defined = as >>>>>> capabilities could be indicated also using feature capability >>>>>> indicators.) >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Christer >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> However, you have pointed out a problem that arose in the >>>>>> evolution of the mechanism. Originally, there was an outer = envelope >>>>>> wit the blocks inside it. That would let us know the source of = each >>>>>> block because the data provider block is required. The current >>>>>> mechanism doesn't have that. It's a problem. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> The draft talks about all kind of different entities that might >>>>>> add additional data to an emergency call. >>>>>>>=20 >>>>>>> First, I think it would be good to have some pictures showing a >>>>>> few different scenarios. >>>>>>>=20 >>>>>>> Second, the draft doesn't seem to describe the case where >>>>>> multiple entities are adding data - for the same call. Will = multiple >>>>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, is it >>>>>> not allowed to begin with? >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Christer >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>>> <http://www.nitrodesk.com>) >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org <javascript:;> >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>=20 From a.james.winterbottom@gmail.com Tue Oct 22 13:54:56 2013 Return-Path: <a.james.winterbottom@gmail.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C0611E8272 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 13:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4rEPFp1yLzw for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 13:54:55 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 102A311E8264 for <ecrit@ietf.org>; Tue, 22 Oct 2013 13:54:54 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id un1so2654065pbc.33 for <ecrit@ietf.org>; Tue, 22 Oct 2013 13:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f6PpGf6Xqjl5L/gNMGDNPXG61FmV5PLzej+Nd/iA1lI=; b=C8re7hBsbkUl5EFuE6bXUQyj4hMPGVDbYhxXfXp+zyg5dKv0p+rSvV1oacnREUfkTm FBL8X2BsTNq+tuxd0mPMZXSS4PzJ5bICi0ILV4R04l3GykNURqh8xTY+dHN4Tpe3pFe5 wf1bspNjtwMuqPjzyDjg+n89xIXWqNlRVHWDn/UCC5K6x/mXF5Dlv++bXLevAYzmzAfD qhOxc2Lq6K+NMN/QXrotWwawYLic5YyRjlthWFh8jDRwKvEA4O93MlRMCako4W2t8z8g pNAkvDwKxjBnoC4al/3q7/1XKeRpdBAS6A8rtyHxv+uusQri7xtAGECaRsWSij8zy0nP W1qw== X-Received: by 10.68.218.68 with SMTP id pe4mr3712978pbc.181.1382475294773; Tue, 22 Oct 2013 13:54:54 -0700 (PDT) Received: from [192.168.1.9] (124-149-67-181.dyn.iinet.net.au. [124.149.67.181]) by mx.google.com with ESMTPSA id qn1sm29578992pbc.34.2013.10.22.13.54.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 13:54:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: James Winterbottom <a.james.winterbottom@gmail.com> In-Reply-To: <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> Date: Wed, 23 Oct 2013 07:54:49 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <74690D52-E081-419B-8615-DB04ED55B7D2@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> To: Brian Rosen <br@brianrosen.net> X-Mailer: Apple Mail (2.1510) Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 20:54:56 -0000 I am not sure that I understand why it is such a problem to have = provider blocks repeated if a single provider provides more than one = block of information. This addresses the MIME issue and the requirement = to have some kind of chaining unique ID. Cheers James On 23/10/2013, at 7:51 AM, Brian Rosen <br@brianrosen.net> wrote: > By "fixing" the data structure to be a series of blocks, each with = it's own MIME type and schema, you can't really group them in useful = ways. > When I did the original, a given set of data from one source was one = object, and you could have more than one such object in the body, or = more than one URI to an entire object in the Call-Info. When we split = it up into blocks, we lost the ability to group. >=20 > We could try doing something with mime/multipart hierarchy. I don't = know what is possible. I don't think requiring all blocks from the same = source to have a unique ID in them is brittle. >=20 > Brian >=20 > On Oct 22, 2013, at 4:17 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >=20 >> I think that that is more brittle. >> If the requirement is that the data provided be firmly linked to = source then tie them together more tightly. >>=20 >>=20 >>=20 >> Sent from my iPad >>=20 >> On 23/10/2013, at 6:21 AM, Brian Rosen <br@brianrosen.net> wrote: >>=20 >>> I would be inclined to have a "source" attribute in every block, = which could be matched. It could contain any globally unique string = (such as a domain name) that labels the source of each block. >>>=20 >>> Brian >>>=20 >>> On Oct 22, 2013, at 3:16 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>>=20 >>>> One way to do that is through schema structure and constraints. >>>>=20 >>>>=20 >>>> Sent from my iPad >>>>=20 >>>> On 23/10/2013, at 5:30 AM, Brian Rosen <br@brianrosen.net> wrote: >>>>=20 >>>>> I don't think this is sufficient. I think there has to be a way = to know which data provider which block. >>>>>=20 >>>>> What you have is: >>>>> SP A provided some info >>>>> SP B provided some info >>>>> Info X, don't know who provided it >>>>> Info Y, don't know who provided it >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig = <Hannes.Tschofenig@gmx.net> wrote: >>>>>=20 >>>>>> Hi Christer, Brian, James, >>>>>>=20 >>>>>> I believe you guys raised a couple of issues, namely: >>>>>>=20 >>>>>> * Could we provide more and better examples? We have a number of = examples in the document but we do not illustrate more complex versions. >>>>>>=20 >>>>>> I am thinking about how to add a longer example. >>>>>>=20 >>>>>> * Did we double-check whether there are any constraints regarding = the number of blocks a single data provider can add and whether there = are problems when multiple data provider add information? >>>>>>=20 >>>>>> My suggestion is obvious: we have to double-check whether we = introduced a bug. >>>>>>=20 >>>>>> * Do we always have information about the source of the data = provider? Brian claimed that we have lost that feature over time. I = double-checked it and there is indeed some fuzziness in the text. Here = is the relevant part: >>>>>>=20 >>>>>> ------ >>>>>>=20 >>>>>> 3.1. Data Provider Information >>>>>>=20 >>>>>> This block is intended to be provided by any service provider in = the >>>>>> path of the call or the access network provider. It includes >>>>>> identification and contact information. This block SHOULD be >>>>>> provided by every service provider in the call path, and by the >>>>>> access network provider. Devices MAY use this block to provide >>>>>> identifying information. The MIME subtype is "application/ >>>>>> emergencyCall.ProviderInfo+xml". An access network provider = SHOULD >>>>>> provide this block either by value or by reference in the = Provided-By >>>>>> section of a PIDF-LO >>>>>>=20 >>>>>> ------ >>>>>>=20 >>>>>> I believe I hear Brian saying that he wants to have the data = provider block be added whenever data is added. I suggest the following = modification: >>>>>>=20 >>>>>> ------ >>>>>>=20 >>>>>> 3.1. Data Provider Information >>>>>>=20 >>>>>> This block MUST be provided by >>>>>> * any service provider in the path of the call, >>>>>> * the access network provider, and >>>>>> * the device, >>>>>> if these entities act as a source for additional data. The data = provider information block offers identification and contact information = of the data source >>>>>>=20 >>>>>> The MIME subtype is "application/emergencyCall.ProviderInfo+xml". >>>>>>=20 >>>>>> ------ >>>>>>=20 >>>>>> What do you think? >>>>>>=20 >>>>>> Ciao >>>>>> Hannes >>>>>>=20 >>>>>>=20 >>>>>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>>>>> There is a requirement for multiple entities to add information. = I >>>>>>> don't think there needs to be a requirement that it happen by = value, but >>>>>>> its at least desirable. >>>>>>>=20 >>>>>>> James, it's perfectly clear that some blocks need to be repeated = For >>>>>>> example the block that says who provided the data. Others are = more >>>>>>> specialized. So generically, it's a requirement that at least = some >>>>>>> blocks are supplied by multiple enties. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>>>=20 >>>>>>> Actually, I think that the requirement is more whether a single >>>>>>> entity should be able to add multiple types if information. >>>>>>>=20 >>>>>>> Cheers >>>>>>> James >>>>>>>=20 >>>>>>> Sent from my iPhone >>>>>>>=20 >>>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>>>> <christer.holmberg@ericsson.com <javascript:;>> wrote: >>>>>>>=20 >>>>>>>> Hi Brian, >>>>>>>>=20 >>>>>>>>> Not sure pictures in ascii art would help, but more words = might. >>>>>>>>=20 >>>>>>>> I think some ascii art, showing the calling device (user or >>>>>>> sensor), some intermediary ("server") and the PSAP would help. >>>>>>>>=20 >>>>>>>>> My usual example is a medical sensor based device adds some, a >>>>>>> specialized service provider who services the device adds some = and a >>>>>>> communications service provider adds some. all of thise go in = the >>>>>>> SIP message. then the access network sends some in the PIDF. >>>>>>>>>=20 >>>>>>>>> With respect to multiple entities adding data, proxies can't = add >>>>>>> bodies, but B2BUAs can. >>>>>>>>=20 >>>>>>>> Well, that is protocol/solution talk - the question is whether >>>>>>> there is a REQUIREMENT that multiple entities should be able to = add >>>>>>> information :) >>>>>>>>=20 >>>>>>>> (If so, we then have to either mandate B2BUA functionality, or >>>>>>> use some other mechanism. For example, data that can be defined = as >>>>>>> capabilities could be indicated also using feature capability >>>>>>> indicators.) >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Christer >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> However, you have pointed out a problem that arose in the >>>>>>> evolution of the mechanism. Originally, there was an outer = envelope >>>>>>> wit the blocks inside it. That would let us know the source of = each >>>>>>> block because the data provider block is required. The current >>>>>>> mechanism doesn't have that. It's a problem. >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> The draft talks about all kind of different entities that might >>>>>>> add additional data to an emergency call. >>>>>>>>=20 >>>>>>>> First, I think it would be good to have some pictures showing a >>>>>>> few different scenarios. >>>>>>>>=20 >>>>>>>> Second, the draft doesn't seem to describe the case where >>>>>>> multiple entities are adding data - for the same call. Will = multiple >>>>>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, is = it >>>>>>> not allowed to begin with? >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Christer >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>>>> <http://www.nitrodesk.com>) >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org <javascript:;> >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>=20 >=20 From br@brianrosen.net Tue Oct 22 14:08:01 2013 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDF011E81CD for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 14:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.47 X-Spam-Level: X-Spam-Status: No, score=-103.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhINbZZQ7bq5 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 14:07:56 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC0511E8271 for <ecrit@ietf.org>; Tue, 22 Oct 2013 14:07:49 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 8so5164900qea.4 for <ecrit@ietf.org>; Tue, 22 Oct 2013 14:07:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=8T2lCmi6fG9nS7oetcdxwPHEj2899gI0XiSK8hTDX/s=; b=XR2ZgteQQZkvoUZXJ5I7xW+iPMso4UNW3vBiWb6f70XAsJePRUqhs9hxiNiZYwVC9z tSmp75bj1cRFc0rVNZkoAEhul3vYzoyz65NaeREeYAIm5VaU1LSzk66ysBONoRPv9H2M rMFsJ/jK7GW+iKAD6nnXPVjXxGjEX3+iAhxU0QrKTE+yPaFBZXDFtBntg5Nnj163JvPW +UKfyid/aWuCJ4dRDXBW/P9UAxaXsIHlhgVmDBotJd9uKPaZOl/USq9PUh9eg30PP3hZ HYs+mh3YO7d8pQKbTYLaQkc7yof7i3eODSGOLz3OcYWUo42d0qllwsAcnteMDCcQLpub xK9g== X-Gm-Message-State: ALoCoQnifOO0/i/3qkSPAzcmYoPoG16UtkKM23OTFb4MrbV3dE2mWYLsIjvSte6F5t+QH+lPbHtd X-Received: by 10.224.61.198 with SMTP id u6mr33256447qah.83.1382476067420; Tue, 22 Oct 2013 14:07:47 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id og1sm45944352qeb.3.2013.10.22.14.07.46 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 14:07:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Rosen <br@brianrosen.net> In-Reply-To: <74690D52-E081-419B-8615-DB04ED55B7D2@gmail.com> Date: Tue, 22 Oct 2013 17:07:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <27D665B2-BDB4-4C05-A859-78D7DFACD397@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> <74690D52-E081-419B-8615-DB04ED55B7D2@gmail.com> To: James Winterbottom <a.james.winterbottom@gmail.com> X-Mailer: Apple Mail (2.1510) Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 21:08:01 -0000 Because the provider info is itself a block. Repeating it does nothing. We would have to make the content of the provider block a component of = every other block. Brian On Oct 22, 2013, at 4:54 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: > I am not sure that I understand why it is such a problem to have = provider blocks repeated if a single provider provides more than one = block of information. This addresses the MIME issue and the requirement = to have some kind of chaining unique ID. >=20 > Cheers > James >=20 > On 23/10/2013, at 7:51 AM, Brian Rosen <br@brianrosen.net> wrote: >=20 >> By "fixing" the data structure to be a series of blocks, each with = it's own MIME type and schema, you can't really group them in useful = ways. >> When I did the original, a given set of data from one source was one = object, and you could have more than one such object in the body, or = more than one URI to an entire object in the Call-Info. When we split = it up into blocks, we lost the ability to group. >>=20 >> We could try doing something with mime/multipart hierarchy. I don't = know what is possible. I don't think requiring all blocks from the same = source to have a unique ID in them is brittle. >>=20 >> Brian >>=20 >> On Oct 22, 2013, at 4:17 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>=20 >>> I think that that is more brittle. >>> If the requirement is that the data provided be firmly linked to = source then tie them together more tightly. >>>=20 >>>=20 >>>=20 >>> Sent from my iPad >>>=20 >>> On 23/10/2013, at 6:21 AM, Brian Rosen <br@brianrosen.net> wrote: >>>=20 >>>> I would be inclined to have a "source" attribute in every block, = which could be matched. It could contain any globally unique string = (such as a domain name) that labels the source of each block. >>>>=20 >>>> Brian >>>>=20 >>>> On Oct 22, 2013, at 3:16 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>>>=20 >>>>> One way to do that is through schema structure and constraints. >>>>>=20 >>>>>=20 >>>>> Sent from my iPad >>>>>=20 >>>>> On 23/10/2013, at 5:30 AM, Brian Rosen <br@brianrosen.net> wrote: >>>>>=20 >>>>>> I don't think this is sufficient. I think there has to be a way = to know which data provider which block. >>>>>>=20 >>>>>> What you have is: >>>>>> SP A provided some info >>>>>> SP B provided some info >>>>>> Info X, don't know who provided it >>>>>> Info Y, don't know who provided it >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig = <Hannes.Tschofenig@gmx.net> wrote: >>>>>>=20 >>>>>>> Hi Christer, Brian, James, >>>>>>>=20 >>>>>>> I believe you guys raised a couple of issues, namely: >>>>>>>=20 >>>>>>> * Could we provide more and better examples? We have a number of = examples in the document but we do not illustrate more complex versions. >>>>>>>=20 >>>>>>> I am thinking about how to add a longer example. >>>>>>>=20 >>>>>>> * Did we double-check whether there are any constraints = regarding the number of blocks a single data provider can add and = whether there are problems when multiple data provider add information? >>>>>>>=20 >>>>>>> My suggestion is obvious: we have to double-check whether we = introduced a bug. >>>>>>>=20 >>>>>>> * Do we always have information about the source of the data = provider? Brian claimed that we have lost that feature over time. I = double-checked it and there is indeed some fuzziness in the text. Here = is the relevant part: >>>>>>>=20 >>>>>>> ------ >>>>>>>=20 >>>>>>> 3.1. Data Provider Information >>>>>>>=20 >>>>>>> This block is intended to be provided by any service provider in = the >>>>>>> path of the call or the access network provider. It includes >>>>>>> identification and contact information. This block SHOULD be >>>>>>> provided by every service provider in the call path, and by the >>>>>>> access network provider. Devices MAY use this block to provide >>>>>>> identifying information. The MIME subtype is "application/ >>>>>>> emergencyCall.ProviderInfo+xml". An access network provider = SHOULD >>>>>>> provide this block either by value or by reference in the = Provided-By >>>>>>> section of a PIDF-LO >>>>>>>=20 >>>>>>> ------ >>>>>>>=20 >>>>>>> I believe I hear Brian saying that he wants to have the data = provider block be added whenever data is added. I suggest the following = modification: >>>>>>>=20 >>>>>>> ------ >>>>>>>=20 >>>>>>> 3.1. Data Provider Information >>>>>>>=20 >>>>>>> This block MUST be provided by >>>>>>> * any service provider in the path of the call, >>>>>>> * the access network provider, and >>>>>>> * the device, >>>>>>> if these entities act as a source for additional data. The data = provider information block offers identification and contact information = of the data source >>>>>>>=20 >>>>>>> The MIME subtype is = "application/emergencyCall.ProviderInfo+xml". >>>>>>>=20 >>>>>>> ------ >>>>>>>=20 >>>>>>> What do you think? >>>>>>>=20 >>>>>>> Ciao >>>>>>> Hannes >>>>>>>=20 >>>>>>>=20 >>>>>>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>>>>>> There is a requirement for multiple entities to add = information. I >>>>>>>> don't think there needs to be a requirement that it happen by = value, but >>>>>>>> its at least desirable. >>>>>>>>=20 >>>>>>>> James, it's perfectly clear that some blocks need to be = repeated For >>>>>>>> example the block that says who provided the data. Others are = more >>>>>>>> specialized. So generically, it's a requirement that at least = some >>>>>>>> blocks are supplied by multiple enties. >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>>>>=20 >>>>>>>> Actually, I think that the requirement is more whether a single >>>>>>>> entity should be able to add multiple types if information. >>>>>>>>=20 >>>>>>>> Cheers >>>>>>>> James >>>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>>>>> <christer.holmberg@ericsson.com <javascript:;>> wrote: >>>>>>>>=20 >>>>>>>>> Hi Brian, >>>>>>>>>=20 >>>>>>>>>> Not sure pictures in ascii art would help, but more words = might. >>>>>>>>>=20 >>>>>>>>> I think some ascii art, showing the calling device (user or >>>>>>>> sensor), some intermediary ("server") and the PSAP would help. >>>>>>>>>=20 >>>>>>>>>> My usual example is a medical sensor based device adds some, = a >>>>>>>> specialized service provider who services the device adds some = and a >>>>>>>> communications service provider adds some. all of thise go in = the >>>>>>>> SIP message. then the access network sends some in the PIDF. >>>>>>>>>>=20 >>>>>>>>>> With respect to multiple entities adding data, proxies can't = add >>>>>>>> bodies, but B2BUAs can. >>>>>>>>>=20 >>>>>>>>> Well, that is protocol/solution talk - the question is whether >>>>>>>> there is a REQUIREMENT that multiple entities should be able to = add >>>>>>>> information :) >>>>>>>>>=20 >>>>>>>>> (If so, we then have to either mandate B2BUA functionality, or >>>>>>>> use some other mechanism. For example, data that can be defined = as >>>>>>>> capabilities could be indicated also using feature capability >>>>>>>> indicators.) >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Christer >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> However, you have pointed out a problem that arose in the >>>>>>>> evolution of the mechanism. Originally, there was an outer = envelope >>>>>>>> wit the blocks inside it. That would let us know the source of = each >>>>>>>> block because the data provider block is required. The = current >>>>>>>> mechanism doesn't have that. It's a problem. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> The draft talks about all kind of different entities that = might >>>>>>>> add additional data to an emergency call. >>>>>>>>>=20 >>>>>>>>> First, I think it would be good to have some pictures showing = a >>>>>>>> few different scenarios. >>>>>>>>>=20 >>>>>>>>> Second, the draft doesn't seem to describe the case where >>>>>>>> multiple entities are adding data - for the same call. Will = multiple >>>>>>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, is = it >>>>>>>> not allowed to begin with? >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>>=20 >>>>>>>>> Christer >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>>>>> <http://www.nitrodesk.com>) >>>>>>>>> _______________________________________________ >>>>>>>>> Ecrit mailing list >>>>>>>>> Ecrit@ietf.org <javascript:;> >>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>=20 >>>>=20 >>=20 >=20 From a.james.winterbottom@gmail.com Tue Oct 22 14:14:16 2013 Return-Path: <a.james.winterbottom@gmail.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C45B11E82E5 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 14:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TL-jpWwoRTx for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 14:14:15 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0DECC11E82B4 for <ecrit@ietf.org>; Tue, 22 Oct 2013 14:14:12 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so9189913pbc.21 for <ecrit@ietf.org>; Tue, 22 Oct 2013 14:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Tad8ZwjVUBD9Z+IkZ7kOFRbnhHEfwOpdaAA3LO56VLA=; b=GPONXgsk4z+DbvSwxR3radNKDs3ZpFzLtGDFNTb68wrlyXM9y43narbyVtryKpWISs JGmjuzCPss1e+yNhh+vVAFy3/MfQRTNQtDK9Xg9LEilCfIKGSilYMstkfmbviIPDbTcw 7Dphp7sZkKEyGyZ5rZRSgTyH73mVu40HrPR5qg4Uf0t+5eShk5uj+NwVxYXZ4br3Axm3 DMJlOAqWADFTxoVXVvjGRYhwNatwO1+AVDe3te+8xvVsrOzVMnmjGE1nxmrkeUtmBQIo EfkYW5NfpYfc2MOR8UFetVtF280qEvrcJzTQZPu+6Vuz2crad2PluLTzG4KSMv6MWpnA 9mYQ== X-Received: by 10.68.129.163 with SMTP id nx3mr24587846pbb.84.1382476452618; Tue, 22 Oct 2013 14:14:12 -0700 (PDT) Received: from [192.168.1.9] (124-149-67-181.dyn.iinet.net.au. [124.149.67.181]) by mx.google.com with ESMTPSA id v4sm29634966pbq.31.2013.10.22.14.14.09 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 14:14:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: James Winterbottom <a.james.winterbottom@gmail.com> In-Reply-To: <27D665B2-BDB4-4C05-A859-78D7DFACD397@brianrosen.net> Date: Wed, 23 Oct 2013 08:14:07 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <34694050-A1CE-492C-9F1C-00945C5E8FCD@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> <74690D52-E081-419B-8615-DB04ED55B7D2@gmail.com> <27D665B2-BDB4-4C05-A859-78D7DFACD397@brianrosen.net> To: Brian Rosen <br@brianrosen.net> X-Mailer: Apple Mail (2.1510) Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 21:14:16 -0000 Yes, and so? This is dead simple with schema and achieves the tie in a totally = unambiguous way. On 23/10/2013, at 8:07 AM, Brian Rosen <br@brianrosen.net> wrote: > Because the provider info is itself a block. Repeating it does = nothing. >=20 > We would have to make the content of the provider block a component of = every other block. >=20 > Brian >=20 > On Oct 22, 2013, at 4:54 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >=20 >> I am not sure that I understand why it is such a problem to have = provider blocks repeated if a single provider provides more than one = block of information. This addresses the MIME issue and the requirement = to have some kind of chaining unique ID. >>=20 >> Cheers >> James >>=20 >> On 23/10/2013, at 7:51 AM, Brian Rosen <br@brianrosen.net> wrote: >>=20 >>> By "fixing" the data structure to be a series of blocks, each with = it's own MIME type and schema, you can't really group them in useful = ways. >>> When I did the original, a given set of data from one source was one = object, and you could have more than one such object in the body, or = more than one URI to an entire object in the Call-Info. When we split = it up into blocks, we lost the ability to group. >>>=20 >>> We could try doing something with mime/multipart hierarchy. I don't = know what is possible. I don't think requiring all blocks from the same = source to have a unique ID in them is brittle. >>>=20 >>> Brian >>>=20 >>> On Oct 22, 2013, at 4:17 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>>=20 >>>> I think that that is more brittle. >>>> If the requirement is that the data provided be firmly linked to = source then tie them together more tightly. >>>>=20 >>>>=20 >>>>=20 >>>> Sent from my iPad >>>>=20 >>>> On 23/10/2013, at 6:21 AM, Brian Rosen <br@brianrosen.net> wrote: >>>>=20 >>>>> I would be inclined to have a "source" attribute in every block, = which could be matched. It could contain any globally unique string = (such as a domain name) that labels the source of each block. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 22, 2013, at 3:16 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>>>>=20 >>>>>> One way to do that is through schema structure and constraints. >>>>>>=20 >>>>>>=20 >>>>>> Sent from my iPad >>>>>>=20 >>>>>> On 23/10/2013, at 5:30 AM, Brian Rosen <br@brianrosen.net> wrote: >>>>>>=20 >>>>>>> I don't think this is sufficient. I think there has to be a way = to know which data provider which block. >>>>>>>=20 >>>>>>> What you have is: >>>>>>> SP A provided some info >>>>>>> SP B provided some info >>>>>>> Info X, don't know who provided it >>>>>>> Info Y, don't know who provided it >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig = <Hannes.Tschofenig@gmx.net> wrote: >>>>>>>=20 >>>>>>>> Hi Christer, Brian, James, >>>>>>>>=20 >>>>>>>> I believe you guys raised a couple of issues, namely: >>>>>>>>=20 >>>>>>>> * Could we provide more and better examples? We have a number = of examples in the document but we do not illustrate more complex = versions. >>>>>>>>=20 >>>>>>>> I am thinking about how to add a longer example. >>>>>>>>=20 >>>>>>>> * Did we double-check whether there are any constraints = regarding the number of blocks a single data provider can add and = whether there are problems when multiple data provider add information? >>>>>>>>=20 >>>>>>>> My suggestion is obvious: we have to double-check whether we = introduced a bug. >>>>>>>>=20 >>>>>>>> * Do we always have information about the source of the data = provider? Brian claimed that we have lost that feature over time. I = double-checked it and there is indeed some fuzziness in the text. Here = is the relevant part: >>>>>>>>=20 >>>>>>>> ------ >>>>>>>>=20 >>>>>>>> 3.1. Data Provider Information >>>>>>>>=20 >>>>>>>> This block is intended to be provided by any service provider = in the >>>>>>>> path of the call or the access network provider. It includes >>>>>>>> identification and contact information. This block SHOULD be >>>>>>>> provided by every service provider in the call path, and by the >>>>>>>> access network provider. Devices MAY use this block to provide >>>>>>>> identifying information. The MIME subtype is "application/ >>>>>>>> emergencyCall.ProviderInfo+xml". An access network provider = SHOULD >>>>>>>> provide this block either by value or by reference in the = Provided-By >>>>>>>> section of a PIDF-LO >>>>>>>>=20 >>>>>>>> ------ >>>>>>>>=20 >>>>>>>> I believe I hear Brian saying that he wants to have the data = provider block be added whenever data is added. I suggest the following = modification: >>>>>>>>=20 >>>>>>>> ------ >>>>>>>>=20 >>>>>>>> 3.1. Data Provider Information >>>>>>>>=20 >>>>>>>> This block MUST be provided by >>>>>>>> * any service provider in the path of the call, >>>>>>>> * the access network provider, and >>>>>>>> * the device, >>>>>>>> if these entities act as a source for additional data. The = data provider information block offers identification and contact = information of the data source >>>>>>>>=20 >>>>>>>> The MIME subtype is = "application/emergencyCall.ProviderInfo+xml". >>>>>>>>=20 >>>>>>>> ------ >>>>>>>>=20 >>>>>>>> What do you think? >>>>>>>>=20 >>>>>>>> Ciao >>>>>>>> Hannes >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>>>>>>> There is a requirement for multiple entities to add = information. I >>>>>>>>> don't think there needs to be a requirement that it happen by = value, but >>>>>>>>> its at least desirable. >>>>>>>>>=20 >>>>>>>>> James, it's perfectly clear that some blocks need to be = repeated For >>>>>>>>> example the block that says who provided the data. Others are = more >>>>>>>>> specialized. So generically, it's a requirement that at least = some >>>>>>>>> blocks are supplied by multiple enties. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>>>>>=20 >>>>>>>>> Actually, I think that the requirement is more whether a = single >>>>>>>>> entity should be able to add multiple types if information. >>>>>>>>>=20 >>>>>>>>> Cheers >>>>>>>>> James >>>>>>>>>=20 >>>>>>>>> Sent from my iPhone >>>>>>>>>=20 >>>>>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>>>>>> <christer.holmberg@ericsson.com <javascript:;>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Brian, >>>>>>>>>>=20 >>>>>>>>>>> Not sure pictures in ascii art would help, but more words = might. >>>>>>>>>>=20 >>>>>>>>>> I think some ascii art, showing the calling device (user or >>>>>>>>> sensor), some intermediary ("server") and the PSAP would help. >>>>>>>>>>=20 >>>>>>>>>>> My usual example is a medical sensor based device adds some, = a >>>>>>>>> specialized service provider who services the device adds some = and a >>>>>>>>> communications service provider adds some. all of thise go in = the >>>>>>>>> SIP message. then the access network sends some in the PIDF. >>>>>>>>>>>=20 >>>>>>>>>>> With respect to multiple entities adding data, proxies can't = add >>>>>>>>> bodies, but B2BUAs can. >>>>>>>>>>=20 >>>>>>>>>> Well, that is protocol/solution talk - the question is = whether >>>>>>>>> there is a REQUIREMENT that multiple entities should be able = to add >>>>>>>>> information :) >>>>>>>>>>=20 >>>>>>>>>> (If so, we then have to either mandate B2BUA functionality, = or >>>>>>>>> use some other mechanism. For example, data that can be = defined as >>>>>>>>> capabilities could be indicated also using feature capability >>>>>>>>> indicators.) >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Christer >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> However, you have pointed out a problem that arose in the >>>>>>>>> evolution of the mechanism. Originally, there was an outer = envelope >>>>>>>>> wit the blocks inside it. That would let us know the source = of each >>>>>>>>> block because the data provider block is required. The = current >>>>>>>>> mechanism doesn't have that. It's a problem. >>>>>>>>>>=20 >>>>>>>>>> Brian >>>>>>>>>>=20 >>>>>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> The draft talks about all kind of different entities that = might >>>>>>>>> add additional data to an emergency call. >>>>>>>>>>=20 >>>>>>>>>> First, I think it would be good to have some pictures showing = a >>>>>>>>> few different scenarios. >>>>>>>>>>=20 >>>>>>>>>> Second, the draft doesn't seem to describe the case where >>>>>>>>> multiple entities are adding data - for the same call. Will = multiple >>>>>>>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, is = it >>>>>>>>> not allowed to begin with? >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>>=20 >>>>>>>>>> Christer >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>>>>>> <http://www.nitrodesk.com>) >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing list >>>>>>>>>> Ecrit@ietf.org <javascript:;> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Ecrit mailing list >>>>>>>>> Ecrit@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>=20 >>>>>=20 >>>=20 >>=20 >=20 From br@brianrosen.net Tue Oct 22 14:21:04 2013 Return-Path: <br@brianrosen.net> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D7A11E8227 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 14:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.478 X-Spam-Level: X-Spam-Status: No, score=-103.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GILrAX0-0vUI for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 14:21:00 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3B011E81C8 for <ecrit@ietf.org>; Tue, 22 Oct 2013 14:21:00 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id cm18so35961qab.16 for <ecrit@ietf.org>; Tue, 22 Oct 2013 14:20:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=TsoHywy3i/lz2vtcw933ddkw4nz5ZHRoJqnZAkK7qII=; b=loTfNh3d7sQffgyPIlZzZ+sk455dmktMX3wwF5lFKsK6qDjbhBZqc3GwP93Ipmt19J 11NDxfmcSfjIIp4ZSmZcPqiL5p1LDhVw61YAGapt3buY/zDAWVgmifANTyie0cD6RLNl jTfgJLDO6W5p6aDxN6nEY50PvMXbn8tc5uML+W0HeJ7kwwnbJzthsGzAQmcb5PMg90RG o5+kdP5FYkukL5jl9e107cKxoyNnQOpSwz6XwGQtEJDq5OIkyly/USoebDpjxX3dv9Rr YAsRxuS92EiOel50GX53SkckC4Yr49nm/dxXqPP+rH4R1KoRwKXu/D7ZI5U9nylN19Xp hw0A== X-Gm-Message-State: ALoCoQl21ZZCJrIRWUcAAL0NsEPOW9H2SO0RIEPQE/T+2SqQGfeJ0TY6qUZXz4+ZzZ5v3J68uNNZ X-Received: by 10.224.72.81 with SMTP id l17mr33025100qaj.54.1382476858865; Tue, 22 Oct 2013 14:20:58 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id 4sm53871087qak.11.2013.10.22.14.20.57 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 14:20:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Rosen <br@brianrosen.net> In-Reply-To: <34694050-A1CE-492C-9F1C-00945C5E8FCD@gmail.com> Date: Tue, 22 Oct 2013 17:20:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2949DC42-3D5B-4237-9F6A-BABE65A9E42A@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> <74690D52-E081-419B-8615-DB04ED55B7D2@gmail.com> <27D665B2-BDB4-4C05-A859-78D7DFACD397@brianrosen.net> <34694050-A1CE-492C-9F1C-00945C5E8FCD@gmail.com> To: James Winterbottom <a.james.winterbottom@gmail.com> X-Mailer: Apple Mail (2.1510) Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 21:21:04 -0000 Because you also need it as a stand alone when that's all the provider = sends, and if you think, as I do, that the average report that is more = than just the provider block will have two or more blocks, it's = repetitive. You don't get anything out of repeating every element of = the provider block. You only want to know which provider sent it. Brian On Oct 22, 2013, at 5:14 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: > Yes, and so? > This is dead simple with schema and achieves the tie in a totally = unambiguous way. >=20 > On 23/10/2013, at 8:07 AM, Brian Rosen <br@brianrosen.net> wrote: >=20 >> Because the provider info is itself a block. Repeating it does = nothing. >>=20 >> We would have to make the content of the provider block a component = of every other block. >>=20 >> Brian >>=20 >> On Oct 22, 2013, at 4:54 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>=20 >>> I am not sure that I understand why it is such a problem to have = provider blocks repeated if a single provider provides more than one = block of information. This addresses the MIME issue and the requirement = to have some kind of chaining unique ID. >>>=20 >>> Cheers >>> James >>>=20 >>> On 23/10/2013, at 7:51 AM, Brian Rosen <br@brianrosen.net> wrote: >>>=20 >>>> By "fixing" the data structure to be a series of blocks, each with = it's own MIME type and schema, you can't really group them in useful = ways. >>>> When I did the original, a given set of data from one source was = one object, and you could have more than one such object in the body, or = more than one URI to an entire object in the Call-Info. When we split = it up into blocks, we lost the ability to group. >>>>=20 >>>> We could try doing something with mime/multipart hierarchy. I = don't know what is possible. I don't think requiring all blocks from = the same source to have a unique ID in them is brittle. >>>>=20 >>>> Brian >>>>=20 >>>> On Oct 22, 2013, at 4:17 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>>>=20 >>>>> I think that that is more brittle. >>>>> If the requirement is that the data provided be firmly linked to = source then tie them together more tightly. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Sent from my iPad >>>>>=20 >>>>> On 23/10/2013, at 6:21 AM, Brian Rosen <br@brianrosen.net> wrote: >>>>>=20 >>>>>> I would be inclined to have a "source" attribute in every block, = which could be matched. It could contain any globally unique string = (such as a domain name) that labels the source of each block. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Oct 22, 2013, at 3:16 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>>>>>=20 >>>>>>> One way to do that is through schema structure and constraints. >>>>>>>=20 >>>>>>>=20 >>>>>>> Sent from my iPad >>>>>>>=20 >>>>>>> On 23/10/2013, at 5:30 AM, Brian Rosen <br@brianrosen.net> = wrote: >>>>>>>=20 >>>>>>>> I don't think this is sufficient. I think there has to be a = way to know which data provider which block. >>>>>>>>=20 >>>>>>>> What you have is: >>>>>>>> SP A provided some info >>>>>>>> SP B provided some info >>>>>>>> Info X, don't know who provided it >>>>>>>> Info Y, don't know who provided it >>>>>>>>=20 >>>>>>>> Brian >>>>>>>>=20 >>>>>>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig = <Hannes.Tschofenig@gmx.net> wrote: >>>>>>>>=20 >>>>>>>>> Hi Christer, Brian, James, >>>>>>>>>=20 >>>>>>>>> I believe you guys raised a couple of issues, namely: >>>>>>>>>=20 >>>>>>>>> * Could we provide more and better examples? We have a number = of examples in the document but we do not illustrate more complex = versions. >>>>>>>>>=20 >>>>>>>>> I am thinking about how to add a longer example. >>>>>>>>>=20 >>>>>>>>> * Did we double-check whether there are any constraints = regarding the number of blocks a single data provider can add and = whether there are problems when multiple data provider add information? >>>>>>>>>=20 >>>>>>>>> My suggestion is obvious: we have to double-check whether we = introduced a bug. >>>>>>>>>=20 >>>>>>>>> * Do we always have information about the source of the data = provider? Brian claimed that we have lost that feature over time. I = double-checked it and there is indeed some fuzziness in the text. Here = is the relevant part: >>>>>>>>>=20 >>>>>>>>> ------ >>>>>>>>>=20 >>>>>>>>> 3.1. Data Provider Information >>>>>>>>>=20 >>>>>>>>> This block is intended to be provided by any service provider = in the >>>>>>>>> path of the call or the access network provider. It includes >>>>>>>>> identification and contact information. This block SHOULD be >>>>>>>>> provided by every service provider in the call path, and by = the >>>>>>>>> access network provider. Devices MAY use this block to = provide >>>>>>>>> identifying information. The MIME subtype is "application/ >>>>>>>>> emergencyCall.ProviderInfo+xml". An access network provider = SHOULD >>>>>>>>> provide this block either by value or by reference in the = Provided-By >>>>>>>>> section of a PIDF-LO >>>>>>>>>=20 >>>>>>>>> ------ >>>>>>>>>=20 >>>>>>>>> I believe I hear Brian saying that he wants to have the data = provider block be added whenever data is added. I suggest the following = modification: >>>>>>>>>=20 >>>>>>>>> ------ >>>>>>>>>=20 >>>>>>>>> 3.1. Data Provider Information >>>>>>>>>=20 >>>>>>>>> This block MUST be provided by >>>>>>>>> * any service provider in the path of the call, >>>>>>>>> * the access network provider, and >>>>>>>>> * the device, >>>>>>>>> if these entities act as a source for additional data. The = data provider information block offers identification and contact = information of the data source >>>>>>>>>=20 >>>>>>>>> The MIME subtype is = "application/emergencyCall.ProviderInfo+xml". >>>>>>>>>=20 >>>>>>>>> ------ >>>>>>>>>=20 >>>>>>>>> What do you think? >>>>>>>>>=20 >>>>>>>>> Ciao >>>>>>>>> Hannes >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>>>>>>>> There is a requirement for multiple entities to add = information. I >>>>>>>>>> don't think there needs to be a requirement that it happen by = value, but >>>>>>>>>> its at least desirable. >>>>>>>>>>=20 >>>>>>>>>> James, it's perfectly clear that some blocks need to be = repeated For >>>>>>>>>> example the block that says who provided the data. Others = are more >>>>>>>>>> specialized. So generically, it's a requirement that at = least some >>>>>>>>>> blocks are supplied by multiple enties. >>>>>>>>>>=20 >>>>>>>>>> Brian >>>>>>>>>>=20 >>>>>>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>>>>>>=20 >>>>>>>>>> Actually, I think that the requirement is more whether a = single >>>>>>>>>> entity should be able to add multiple types if information. >>>>>>>>>>=20 >>>>>>>>>> Cheers >>>>>>>>>> James >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPhone >>>>>>>>>>=20 >>>>>>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>>>>>>> <christer.holmberg@ericsson.com <javascript:;>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Brian, >>>>>>>>>>>=20 >>>>>>>>>>>> Not sure pictures in ascii art would help, but more words = might. >>>>>>>>>>>=20 >>>>>>>>>>> I think some ascii art, showing the calling device (user or >>>>>>>>>> sensor), some intermediary ("server") and the PSAP would = help. >>>>>>>>>>>=20 >>>>>>>>>>>> My usual example is a medical sensor based device adds = some, a >>>>>>>>>> specialized service provider who services the device adds = some and a >>>>>>>>>> communications service provider adds some. all of thise go = in the >>>>>>>>>> SIP message. then the access network sends some in the PIDF. >>>>>>>>>>>>=20 >>>>>>>>>>>> With respect to multiple entities adding data, proxies = can't add >>>>>>>>>> bodies, but B2BUAs can. >>>>>>>>>>>=20 >>>>>>>>>>> Well, that is protocol/solution talk - the question is = whether >>>>>>>>>> there is a REQUIREMENT that multiple entities should be able = to add >>>>>>>>>> information :) >>>>>>>>>>>=20 >>>>>>>>>>> (If so, we then have to either mandate B2BUA functionality, = or >>>>>>>>>> use some other mechanism. For example, data that can be = defined as >>>>>>>>>> capabilities could be indicated also using feature capability >>>>>>>>>> indicators.) >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>>=20 >>>>>>>>>>> Christer >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> However, you have pointed out a problem that arose in the >>>>>>>>>> evolution of the mechanism. Originally, there was an outer = envelope >>>>>>>>>> wit the blocks inside it. That would let us know the source = of each >>>>>>>>>> block because the data provider block is required. The = current >>>>>>>>>> mechanism doesn't have that. It's a problem. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>>>>>>> Hi, >>>>>>>>>>>=20 >>>>>>>>>>> The draft talks about all kind of different entities that = might >>>>>>>>>> add additional data to an emergency call. >>>>>>>>>>>=20 >>>>>>>>>>> First, I think it would be good to have some pictures = showing a >>>>>>>>>> few different scenarios. >>>>>>>>>>>=20 >>>>>>>>>>> Second, the draft doesn't seem to describe the case where >>>>>>>>>> multiple entities are adding data - for the same call. Will = multiple >>>>>>>>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, = is it >>>>>>>>>> not allowed to begin with? >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>>=20 >>>>>>>>>>> Christer >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>>>>>>> <http://www.nitrodesk.com>) >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Ecrit mailing list >>>>>>>>>>> Ecrit@ietf.org <javascript:;> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing list >>>>>>>>>> Ecrit@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>=20 >>>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From a.james.winterbottom@gmail.com Tue Oct 22 14:28:19 2013 Return-Path: <a.james.winterbottom@gmail.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BA811E80F1 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 14:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20Hz+mjNsWhR for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 14:28:18 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7F85E11E81FF for <ecrit@ietf.org>; Tue, 22 Oct 2013 14:28:16 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id q10so8399211pdj.28 for <ecrit@ietf.org>; Tue, 22 Oct 2013 14:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lmHjtIuXiPAkKFP9zCw6o56Ebsp23iYc2xOk5JTOB+A=; b=XheTKPwg6FwyVfotnYjdJWRyUJYuwq6JaIgrWTbhRIE1qMvU1TZNcyPgmSNnrx4dbM pn7f8d199Xqemb6OmwxKWpolOcEE0X+PY4U9GxhsJYwLnGBwyJj/9MMhDIUler5pXUj+ MyMnVrHQnwFFcRnj1cURWKP5uEr+c/c/DEoGB5SMvY9JQu+3smAd5ub3Z9NMRj81eBDO 87eF5tjL93fYJ17vrkpXU1vV7EBqxhWlB9ICTgaH+CyNUVZQ0BpPKkRc+iSiPMUY52HV EtCeWtD8hF4FS0gQS71L4/A2/T8YiLBk/z5jTTPnnl+y76O6fxyl8f5Ah0pKcqwBh/Ea 1szQ== X-Received: by 10.68.178.161 with SMTP id cz1mr10537137pbc.131.1382477296218; Tue, 22 Oct 2013 14:28:16 -0700 (PDT) Received: from [192.168.1.9] (124-149-67-181.dyn.iinet.net.au. [124.149.67.181]) by mx.google.com with ESMTPSA id j9sm35889038paj.18.2013.10.22.14.28.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 14:28:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: James Winterbottom <a.james.winterbottom@gmail.com> In-Reply-To: <2949DC42-3D5B-4237-9F6A-BABE65A9E42A@brianrosen.net> Date: Wed, 23 Oct 2013 08:28:10 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <BC28EA87-48A1-4A4F-98AC-818C3EA7413C@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <CAOPrzE37Lx-qxCCmRJ5RJX29t7EVyFZkESAEnAK5wCSySJDodw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <ADE693DC-F327-4093-B06E-D89F1FFCA9DD@gmail.com> <CAOPrzE2nvpbPmfi0BmY-+wo6vZStQKvdEz5uFqt+8vX306biZA@mail.gmail.com> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> <74690D52-E081-419B-8615-DB04ED55B7D2@gmail.com> <27D665B2-BDB4-4C05-A859-78D7DFACD397@brianrosen.net> <34694050-A1CE-492C-9F1C-00945C5E8FCD@gmail.com> <2949DC42-3D5B-4237-9F6A-BABE65A9E42A@brianrosen.net> To: Brian Rosen <br@brianrosen.net> X-Mailer: Apple Mail (2.1510) Cc: ecrit <ecrit@ietf.org> Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 22 Oct 2013 21:28:19 -0000 I think this clarifies my problem with the current structure.=20 The provider would only ever send this block by itself if it doesn't = have anything other to send. This implies that it doesn't know what kind = of provider it actually is which doesn't seem useful. On 23/10/2013, at 8:20 AM, Brian Rosen <br@brianrosen.net> wrote: > Because you also need it as a stand alone when that's all the provider = sends, and if you think, as I do, that the average report that is more = than just the provider block will have two or more blocks, it's = repetitive. You don't get anything out of repeating every element of = the provider block. You only want to know which provider sent it. >=20 > Brian > On Oct 22, 2013, at 5:14 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >=20 >> Yes, and so? >> This is dead simple with schema and achieves the tie in a totally = unambiguous way. >>=20 >> On 23/10/2013, at 8:07 AM, Brian Rosen <br@brianrosen.net> wrote: >>=20 >>> Because the provider info is itself a block. Repeating it does = nothing. >>>=20 >>> We would have to make the content of the provider block a component = of every other block. >>>=20 >>> Brian >>>=20 >>> On Oct 22, 2013, at 4:54 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>>=20 >>>> I am not sure that I understand why it is such a problem to have = provider blocks repeated if a single provider provides more than one = block of information. This addresses the MIME issue and the requirement = to have some kind of chaining unique ID. >>>>=20 >>>> Cheers >>>> James >>>>=20 >>>> On 23/10/2013, at 7:51 AM, Brian Rosen <br@brianrosen.net> wrote: >>>>=20 >>>>> By "fixing" the data structure to be a series of blocks, each with = it's own MIME type and schema, you can't really group them in useful = ways. >>>>> When I did the original, a given set of data from one source was = one object, and you could have more than one such object in the body, or = more than one URI to an entire object in the Call-Info. When we split = it up into blocks, we lost the ability to group. >>>>>=20 >>>>> We could try doing something with mime/multipart hierarchy. I = don't know what is possible. I don't think requiring all blocks from = the same source to have a unique ID in them is brittle. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 22, 2013, at 4:17 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>>>>=20 >>>>>> I think that that is more brittle. >>>>>> If the requirement is that the data provided be firmly linked to = source then tie them together more tightly. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Sent from my iPad >>>>>>=20 >>>>>> On 23/10/2013, at 6:21 AM, Brian Rosen <br@brianrosen.net> wrote: >>>>>>=20 >>>>>>> I would be inclined to have a "source" attribute in every block, = which could be matched. It could contain any globally unique string = (such as a domain name) that labels the source of each block. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Oct 22, 2013, at 3:16 PM, James Winterbottom = <a.james.winterbottom@gmail.com> wrote: >>>>>>>=20 >>>>>>>> One way to do that is through schema structure and constraints. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Sent from my iPad >>>>>>>>=20 >>>>>>>> On 23/10/2013, at 5:30 AM, Brian Rosen <br@brianrosen.net> = wrote: >>>>>>>>=20 >>>>>>>>> I don't think this is sufficient. I think there has to be a = way to know which data provider which block. >>>>>>>>>=20 >>>>>>>>> What you have is: >>>>>>>>> SP A provided some info >>>>>>>>> SP B provided some info >>>>>>>>> Info X, don't know who provided it >>>>>>>>> Info Y, don't know who provided it >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig = <Hannes.Tschofenig@gmx.net> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Christer, Brian, James, >>>>>>>>>>=20 >>>>>>>>>> I believe you guys raised a couple of issues, namely: >>>>>>>>>>=20 >>>>>>>>>> * Could we provide more and better examples? We have a number = of examples in the document but we do not illustrate more complex = versions. >>>>>>>>>>=20 >>>>>>>>>> I am thinking about how to add a longer example. >>>>>>>>>>=20 >>>>>>>>>> * Did we double-check whether there are any constraints = regarding the number of blocks a single data provider can add and = whether there are problems when multiple data provider add information? >>>>>>>>>>=20 >>>>>>>>>> My suggestion is obvious: we have to double-check whether we = introduced a bug. >>>>>>>>>>=20 >>>>>>>>>> * Do we always have information about the source of the data = provider? Brian claimed that we have lost that feature over time. I = double-checked it and there is indeed some fuzziness in the text. Here = is the relevant part: >>>>>>>>>>=20 >>>>>>>>>> ------ >>>>>>>>>>=20 >>>>>>>>>> 3.1. Data Provider Information >>>>>>>>>>=20 >>>>>>>>>> This block is intended to be provided by any service provider = in the >>>>>>>>>> path of the call or the access network provider. It includes >>>>>>>>>> identification and contact information. This block SHOULD be >>>>>>>>>> provided by every service provider in the call path, and by = the >>>>>>>>>> access network provider. Devices MAY use this block to = provide >>>>>>>>>> identifying information. The MIME subtype is "application/ >>>>>>>>>> emergencyCall.ProviderInfo+xml". An access network provider = SHOULD >>>>>>>>>> provide this block either by value or by reference in the = Provided-By >>>>>>>>>> section of a PIDF-LO >>>>>>>>>>=20 >>>>>>>>>> ------ >>>>>>>>>>=20 >>>>>>>>>> I believe I hear Brian saying that he wants to have the data = provider block be added whenever data is added. I suggest the following = modification: >>>>>>>>>>=20 >>>>>>>>>> ------ >>>>>>>>>>=20 >>>>>>>>>> 3.1. Data Provider Information >>>>>>>>>>=20 >>>>>>>>>> This block MUST be provided by >>>>>>>>>> * any service provider in the path of the call, >>>>>>>>>> * the access network provider, and >>>>>>>>>> * the device, >>>>>>>>>> if these entities act as a source for additional data. The = data provider information block offers identification and contact = information of the data source >>>>>>>>>>=20 >>>>>>>>>> The MIME subtype is = "application/emergencyCall.ProviderInfo+xml". >>>>>>>>>>=20 >>>>>>>>>> ------ >>>>>>>>>>=20 >>>>>>>>>> What do you think? >>>>>>>>>>=20 >>>>>>>>>> Ciao >>>>>>>>>> Hannes >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>>>>>>>>> There is a requirement for multiple entities to add = information. I >>>>>>>>>>> don't think there needs to be a requirement that it happen = by value, but >>>>>>>>>>> its at least desirable. >>>>>>>>>>>=20 >>>>>>>>>>> James, it's perfectly clear that some blocks need to be = repeated For >>>>>>>>>>> example the block that says who provided the data. Others = are more >>>>>>>>>>> specialized. So generically, it's a requirement that at = least some >>>>>>>>>>> blocks are supplied by multiple enties. >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Actually, I think that the requirement is more whether a = single >>>>>>>>>>> entity should be able to add multiple types if information. >>>>>>>>>>>=20 >>>>>>>>>>> Cheers >>>>>>>>>>> James >>>>>>>>>>>=20 >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>=20 >>>>>>>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>>>>>>>> <christer.holmberg@ericsson.com <javascript:;>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Hi Brian, >>>>>>>>>>>>=20 >>>>>>>>>>>>> Not sure pictures in ascii art would help, but more words = might. >>>>>>>>>>>>=20 >>>>>>>>>>>> I think some ascii art, showing the calling device (user or >>>>>>>>>>> sensor), some intermediary ("server") and the PSAP would = help. >>>>>>>>>>>>=20 >>>>>>>>>>>>> My usual example is a medical sensor based device adds = some, a >>>>>>>>>>> specialized service provider who services the device adds = some and a >>>>>>>>>>> communications service provider adds some. all of thise go = in the >>>>>>>>>>> SIP message. then the access network sends some in the = PIDF. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> With respect to multiple entities adding data, proxies = can't add >>>>>>>>>>> bodies, but B2BUAs can. >>>>>>>>>>>>=20 >>>>>>>>>>>> Well, that is protocol/solution talk - the question is = whether >>>>>>>>>>> there is a REQUIREMENT that multiple entities should be able = to add >>>>>>>>>>> information :) >>>>>>>>>>>>=20 >>>>>>>>>>>> (If so, we then have to either mandate B2BUA functionality, = or >>>>>>>>>>> use some other mechanism. For example, data that can be = defined as >>>>>>>>>>> capabilities could be indicated also using feature = capability >>>>>>>>>>> indicators.) >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>>=20 >>>>>>>>>>>> Christer >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> However, you have pointed out a problem that arose in the >>>>>>>>>>> evolution of the mechanism. Originally, there was an outer = envelope >>>>>>>>>>> wit the blocks inside it. That would let us know the source = of each >>>>>>>>>>> block because the data provider block is required. The = current >>>>>>>>>>> mechanism doesn't have that. It's a problem. >>>>>>>>>>>>=20 >>>>>>>>>>>> Brian >>>>>>>>>>>>=20 >>>>>>>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>>=20 >>>>>>>>>>>> The draft talks about all kind of different entities that = might >>>>>>>>>>> add additional data to an emergency call. >>>>>>>>>>>>=20 >>>>>>>>>>>> First, I think it would be good to have some pictures = showing a >>>>>>>>>>> few different scenarios. >>>>>>>>>>>>=20 >>>>>>>>>>>> Second, the draft doesn't seem to describe the case where >>>>>>>>>>> multiple entities are adding data - for the same call. Will = multiple >>>>>>>>>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, = is it >>>>>>>>>>> not allowed to begin with? >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards, >>>>>>>>>>>>=20 >>>>>>>>>>>> Christer >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>>>>>>>> <http://www.nitrodesk.com>) >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>> Ecrit@ietf.org <javascript:;> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Ecrit mailing list >>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>=20 >>>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From randy@qti.qualcomm.com Tue Oct 22 21:33:17 2013 Return-Path: <randy@qti.qualcomm.com> X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AF311E82C4 for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 21:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.639 X-Spam-Level: X-Spam-Status: No, score=-104.639 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qA97i6kE5Md for <ecrit@ietfa.amsl.com>; Tue, 22 Oct 2013 21:33:13 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3A09B11E82C3 for <ecrit@ietf.org>; Tue, 22 Oct 2013 21:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1382502790; x=1414038790; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=fKzikuPfSRFSocrHQ0tEo4obR+SY/a0s3x7vQ/J2kLI=; b=gN8ZigvwBO3yWNk+51J9cyXrwgWnxOKV4+ntO51BtaU5tDNTloLNn6LA iTuTqpErbCRbdoOGNmw9FJgU+fVadtheSt3Fa712b6UkFEFoZXDX7NIJE u3H4yhswFHEaBKSt5W5rL7SDSuTrFxL3JHiwDv4Rn959lANbBTsEZZYJD o=; X-IronPort-AV: E=McAfee;i="5400,1158,7236"; a="82318200" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 22 Oct 2013 21:33:09 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7236"; a="537382677" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 22 Oct 2013 21:33:09 -0700 Received: from [99.111.97.136] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 22 Oct 2013 21:33:09 -0700 Message-ID: <p06240609ce8d010aa7a7@[99.111.97.136]> In-Reply-To: <FBD5AAFFD0978846BF6D3FAB4C892ACC486660@SEA-EXMB-1.telecomsys.com> References: <FBD5AAFFD0978846BF6D3FAB4C892ACC45811B@SEA-EXMB-1.telecomsys.com> <525AC37C.8090708@gmx.net> <525ACC4D.1020500@omnitor.se>, <525ACF61.7080102@gmx.net> <527682A7144B254C856D43E2B3D9E9371EFB798F@nasanexd01b.na.qualcomm.com> <525B3258.2040402@omnitor.se> <FBD5AAFFD0978846BF6D3FAB4C892ACC486660@SEA-EXMB-1.telecomsys.com> X-Mailer: Eudora for Mac OS X Date: Tue, 22 Oct 2013 21:30:30 -0700 To: Roger Marshall <RMarshall@telecomsys.com>, "ecrit@ietf.org" <ecrit@ietf.org> From: Randall Gellens <randy@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: Re: [Ecrit] Charter & Milestones update - Comments sought X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <ecrit.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/ecrit> List-Post: <mailto:ecrit@ietf.org> List-Help: <mailto:ecrit-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Oct 2013 04:33:17 -0000 <!doctype html public "-//W3C//DTD W3 HTML//EN"> <html><head><style type="text/css"><!-- blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 } --></style><title>Re: [Ecrit] Charter & Milestones update - Comments sought
At 10:31 PM +0000 10/21/13, Roger Marshall wrote:

Also, dependent on the above text, Gunnar has suggested the addition of the
following milestone:
 
xxx 2014 - Submit a draft 'Policy based routing in Emergency Services'
 
to the IESG for consideration as a Standards Track RFC

I'd suggest we not include this milestone at this time.  Let's wait until we see a need for such a draft.  Given that NENA is addressing this, I'm not clear on what the IETF's role needs to be.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Those who can make you believe absurdities
can make you commit atrocities.
   --Voltaire
From a.james.winterbottom@gmail.com Tue Oct 22 21:54:23 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFFD11E82D4 for ; Tue, 22 Oct 2013 21:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDttIRT0+2Mf for ; Tue, 22 Oct 2013 21:54:23 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8765221E8085 for ; Tue, 22 Oct 2013 21:54:21 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id v10so337237pde.15 for ; Tue, 22 Oct 2013 21:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4sekhCIuGXtw+OpruWHot+892PU3s9tsN+toaarNoJE=; b=FG1t+4BKz4F76aDQaj2Dk6pCTsDN1AZpi+QFvHvVe0piJtrpxWDNjfwHt4U33Gv0Gr nqa2GBYTF+SkpW4NXAlvVyFc8X9qFBLfg7koyj2Eb/p6VdgFlpekv8Law+/e5UwxqWpt J2QlMoegsvn253sLPCCpsS5Za9doylXRUneOdChEfumQmNrlXBGj0l5mo2d90VGIBlcN VHI6BAO3TIAF2cc3ZIZzAQ90Osw0u9OlRnmBJqkWy8MoApIrHkDCRVYkz5dns43O/cQa A2NbDoHmxJdgL8QoEmvsao8jdNiNBZJooKsIErlloJPY9eesKYnVG9/k37gKhP8MbaRu XXZg== X-Received: by 10.66.218.166 with SMTP id ph6mr1391463pac.28.1382504061276; Tue, 22 Oct 2013 21:54:21 -0700 (PDT) Received: from [192.168.1.9] (124-149-67-181.dyn.iinet.net.au. [124.149.67.181]) by mx.google.com with ESMTPSA id xs1sm37875354pac.7.2013.10.22.21.54.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 21:54:20 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: James Winterbottom In-Reply-To: Date: Wed, 23 Oct 2013 15:54:18 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5210EC7A-65DD-40B9-925A-E070C9ABAA82@gmail.com> References: To: "Rosen, Brian" X-Mailer: Apple Mail (2.1510) Cc: ecrit Subject: Re: [Ecrit] Can I get some love for draft-marshall-similar-location? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 04:54:24 -0000 Hi Brian, I am ambivalent to this draft. I do't think it is essential but I don't = think that it hurts to have it either. I would prefer a more efficient way for a LIS to perform mass location = validation than post multiple LoST queries with the validation attribute = set and that the functionality in similar-location be provided in that = protocol/solution. I think that it is important to remember that a valid location in the = terms of this WG is one that will result in the call being routed to the = right PSAP, it doesn't require location to be accurate enough for = dispatch. Indeed we do not have a mechanism for requesting validation = for the latter case and this has caused some issues within other SDOs. = If the similar-location draft or something similar proceeds then adding = a means to request different levels of validation may also be a good = idea. Cheers James On 23/10/2013, at 6:03 AM, "Rosen, Brian" = wrote: > > I presented this draft in Berlin. There is some support for it, = mostly from the NENA guys. I think it's pretty helpful. It solves two = problems. >=20 > When you get a location that you want to put into a LIS, you should = validate it BEFORE you use it for an emergency call. So, you send a = LoST query and specify validation. >=20 > What is valid? >=20 > That's undoubtedly a national matter, but one way to look at it is = that it's a set of elements in the LI that describes a UNIQUE location = that responders can respond to. A really simple case is a residence = that is addressed by a house number, a street name, a city name, a = state/province, and a country. Provided that the combination of these = elements is the location of one house, it's probably valid. >=20 > But, let's say that there is also a county in the name. I give you = two scenarios. In both scenarios, there are two municipalities with the = same name in the state/province, but they are in different counties. >=20 > In one of the scenarios, the street name only occurs in one of the two = municipalities. In the other scenario, it's in both of them. >=20 > So, if I send LI that does not have a county, does have the street and = (duplicated) municipality, in scenario one, is it valid? It is UNIQUE, = you know where it is, because there is no Apple Street in Hooverville, = Baskin County, but there is an Apple Street in Hooverville, Robbins = County. >=20 > Now, it is a national matter whether the LoST server accepts the lack = of a county name for scenario 1. In most areas I am familiar with, = County is not required unless it's needed to differentiate as it is in = Scenario 2. >=20 > But, the LoST server does know what the County is, and even in = Scenario 1, it might be a really good idea to confirm with the user = entering the address that the address is in Robbins County. >=20 > In the current RFC5222 definition of LoST, there is no way for the = server to return the County name. In Scenario 2, it would return County = on the invalid list, indicating that County was missing, and needs to be = provided. But in Scenario 1, it could either do the same (always = require County, even if the address is unique without it), or just = return Country, State, Street and House Number as valid. >=20 > What the draft does is extend LoST to allow it to return LI to inform = the querier that this address is valid, and is in Robbins County. That = lets the LIS confirm with the user, and it also let's it populate the = LIS entry with the County, which is a good thing to do if it is = confirmed by the user. >=20 > The other problem it solves is how to help the user in Scenario 2. = The query presented has invalid LI, and the response will indicate that = County is invalid. But, the only thing the LIS can do is demand that = the user some how come up with the name of the County. >=20 > A better response would be that the LI given is invalid, but it could = be either 124 Apple St, Hooverville, Baskin County, NJ, US or it could = be 124 Apple St, Hooverville, Robbins County, NJ, US. That is, it could = offer one or more valid addresses as possible candidates for the LI that = was offered in the query. >=20 > The LoST server may not be able to return a small number of valid = locations the LI in the query suggests, but if it could, a response of = "not that, but could it be =85.?" is very useful. >=20 > This also requires that the LoST server return LI. >=20 > We'd really like to push this draft through ecrit. NENA does really = need it, and we think it's generally useful for many countries. >=20 > Can I get some love here? >=20 > > Brian > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Wed Oct 23 04:58:03 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2192011E8197 for ; Wed, 23 Oct 2013 04:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjN5X8dYVD4Z for ; Wed, 23 Oct 2013 04:57:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 61DEA11E83C0 for ; Wed, 23 Oct 2013 04:57:54 -0700 (PDT) Received: from [172.16.254.200] ([80.92.115.161]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MexlN-1VNieX3TjN-00Obft for ; Wed, 23 Oct 2013 13:57:53 +0200 Message-ID: <5267B9D9.2020102@gmx.net> Date: Wed, 23 Oct 2013 13:58:17 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: James Winterbottom , Brian Rosen References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> <74690D52-E081-419B-8615-DB04ED55B7D2@gmail.com> <27D665B2-BDB4-4C05-A859-78D7DFACD397@brianrosen.net> <34694050-A1CE-492C-9F1C-00945C5E8FCD@gmail.com> <2949DC42-3D5B-4237-9F6A-BABE65A9E42A@brianrosen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rTJ1/7isTpywihfTgEhDjJOVLvBPaZN1SkD3oAYjAM4+5nqMLEh iUidgAzZjo7ZfqeOcBdg3yJ9zozVk7xdoGTU1ZgDlFBnO+qstfN2vDrDkVqdkjFG0YYGqDm 8igJKDWKfnC1JHUkw/rPzDOqhVq9cVGeDSyF/3AV9r82//q/KbV3OKn5Wb9u+zkeYvikUx7 B08CvctkXHNA8DyF51MNw== Cc: ecrit Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 11:58:03 -0000 I just tried to create a longer example, as Christer requested, and the current structure indeed has some limitations (as discussed in this thread between James and Brian). There are two approaches to solve the problem: a) Introduce a hierarchical structure within the MIME bodies. b) Link the data provider block with other blocks. To me, it appears that option (b) is somewhat easier. All we have to do is the following: 1) Add a new element to the ProviderInfo block (let's call it ) 2) Add a new element to the other blocks (let's call it ) 3) Add a requirement that all blocks added by a data provider must have the same value in , which is then repeated in the element. Of course, we have an id already in the MIME structure (in the form of a Content-ID). This would allow us to avoid defining the in the structures but we would instead use the element to enumerate the content-ids. It does not exist in the XML. Is that a problem? For the provided-by structure, for example, we do not communite MIME structures but I suspect that the PIDF document would come from a single data provider anyway?! Ciao Hannes On 10/22/2013 11:28 PM, James Winterbottom wrote: > I think this clarifies my problem with the current structure. > The provider would only ever send this block by itself if it doesn't have anything other to send. This implies that it doesn't know what kind of provider it actually is which doesn't seem useful. > > > On 23/10/2013, at 8:20 AM, Brian Rosen wrote: > >> Because you also need it as a stand alone when that's all the provider sends, and if you think, as I do, that the average report that is more than just the provider block will have two or more blocks, it's repetitive. You don't get anything out of repeating every element of the provider block. You only want to know which provider sent it. >> >> Brian >> On Oct 22, 2013, at 5:14 PM, James Winterbottom wrote: >> >>> Yes, and so? >>> This is dead simple with schema and achieves the tie in a totally unambiguous way. >>> >>> On 23/10/2013, at 8:07 AM, Brian Rosen wrote: >>> >>>> Because the provider info is itself a block. Repeating it does nothing. >>>> >>>> We would have to make the content of the provider block a component of every other block. >>>> >>>> Brian >>>> >>>> On Oct 22, 2013, at 4:54 PM, James Winterbottom wrote: >>>> >>>>> I am not sure that I understand why it is such a problem to have provider blocks repeated if a single provider provides more than one block of information. This addresses the MIME issue and the requirement to have some kind of chaining unique ID. >>>>> >>>>> Cheers >>>>> James >>>>> >>>>> On 23/10/2013, at 7:51 AM, Brian Rosen wrote: >>>>> >>>>>> By "fixing" the data structure to be a series of blocks, each with it's own MIME type and schema, you can't really group them in useful ways. >>>>>> When I did the original, a given set of data from one source was one object, and you could have more than one such object in the body, or more than one URI to an entire object in the Call-Info. When we split it up into blocks, we lost the ability to group. >>>>>> >>>>>> We could try doing something with mime/multipart hierarchy. I don't know what is possible. I don't think requiring all blocks from the same source to have a unique ID in them is brittle. >>>>>> >>>>>> Brian >>>>>> >>>>>> On Oct 22, 2013, at 4:17 PM, James Winterbottom wrote: >>>>>> >>>>>>> I think that that is more brittle. >>>>>>> If the requirement is that the data provided be firmly linked to source then tie them together more tightly. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>> On 23/10/2013, at 6:21 AM, Brian Rosen wrote: >>>>>>> >>>>>>>> I would be inclined to have a "source" attribute in every block, which could be matched. It could contain any globally unique string (such as a domain name) that labels the source of each block. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> On Oct 22, 2013, at 3:16 PM, James Winterbottom wrote: >>>>>>>> >>>>>>>>> One way to do that is through schema structure and constraints. >>>>>>>>> >>>>>>>>> >>>>>>>>> Sent from my iPad >>>>>>>>> >>>>>>>>> On 23/10/2013, at 5:30 AM, Brian Rosen wrote: >>>>>>>>> >>>>>>>>>> I don't think this is sufficient. I think there has to be a way to know which data provider which block. >>>>>>>>>> >>>>>>>>>> What you have is: >>>>>>>>>> SP A provided some info >>>>>>>>>> SP B provided some info >>>>>>>>>> Info X, don't know who provided it >>>>>>>>>> Info Y, don't know who provided it >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig wrote: >>>>>>>>>> >>>>>>>>>>> Hi Christer, Brian, James, >>>>>>>>>>> >>>>>>>>>>> I believe you guys raised a couple of issues, namely: >>>>>>>>>>> >>>>>>>>>>> * Could we provide more and better examples? We have a number of examples in the document but we do not illustrate more complex versions. >>>>>>>>>>> >>>>>>>>>>> I am thinking about how to add a longer example. >>>>>>>>>>> >>>>>>>>>>> * Did we double-check whether there are any constraints regarding the number of blocks a single data provider can add and whether there are problems when multiple data provider add information? >>>>>>>>>>> >>>>>>>>>>> My suggestion is obvious: we have to double-check whether we introduced a bug. >>>>>>>>>>> >>>>>>>>>>> * Do we always have information about the source of the data provider? Brian claimed that we have lost that feature over time. I double-checked it and there is indeed some fuzziness in the text. Here is the relevant part: >>>>>>>>>>> >>>>>>>>>>> ------ >>>>>>>>>>> >>>>>>>>>>> 3.1. Data Provider Information >>>>>>>>>>> >>>>>>>>>>> This block is intended to be provided by any service provider in the >>>>>>>>>>> path of the call or the access network provider. It includes >>>>>>>>>>> identification and contact information. This block SHOULD be >>>>>>>>>>> provided by every service provider in the call path, and by the >>>>>>>>>>> access network provider. Devices MAY use this block to provide >>>>>>>>>>> identifying information. The MIME subtype is "application/ >>>>>>>>>>> emergencyCall.ProviderInfo+xml". An access network provider SHOULD >>>>>>>>>>> provide this block either by value or by reference in the Provided-By >>>>>>>>>>> section of a PIDF-LO >>>>>>>>>>> >>>>>>>>>>> ------ >>>>>>>>>>> >>>>>>>>>>> I believe I hear Brian saying that he wants to have the data provider block be added whenever data is added. I suggest the following modification: >>>>>>>>>>> >>>>>>>>>>> ------ >>>>>>>>>>> >>>>>>>>>>> 3.1. Data Provider Information >>>>>>>>>>> >>>>>>>>>>> This block MUST be provided by >>>>>>>>>>> * any service provider in the path of the call, >>>>>>>>>>> * the access network provider, and >>>>>>>>>>> * the device, >>>>>>>>>>> if these entities act as a source for additional data. The data provider information block offers identification and contact information of the data source >>>>>>>>>>> >>>>>>>>>>> The MIME subtype is "application/emergencyCall.ProviderInfo+xml". >>>>>>>>>>> >>>>>>>>>>> ------ >>>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> Ciao >>>>>>>>>>> Hannes >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>>>>>>>>>> There is a requirement for multiple entities to add information. I >>>>>>>>>>>> don't think there needs to be a requirement that it happen by value, but >>>>>>>>>>>> its at least desirable. >>>>>>>>>>>> >>>>>>>>>>>> James, it's perfectly clear that some blocks need to be repeated For >>>>>>>>>>>> example the block that says who provided the data. Others are more >>>>>>>>>>>> specialized. So generically, it's a requirement that at least some >>>>>>>>>>>> blocks are supplied by multiple enties. >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>>>>>>>> >>>>>>>>>>>> Actually, I think that the requirement is more whether a single >>>>>>>>>>>> entity should be able to add multiple types if information. >>>>>>>>>>>> >>>>>>>>>>>> Cheers >>>>>>>>>>>> James >>>>>>>>>>>> >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>> >>>>>>>>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Brian, >>>>>>>>>>>>> >>>>>>>>>>>>>> Not sure pictures in ascii art would help, but more words might. >>>>>>>>>>>>> >>>>>>>>>>>>> I think some ascii art, showing the calling device (user or >>>>>>>>>>>> sensor), some intermediary ("server") and the PSAP would help. >>>>>>>>>>>>> >>>>>>>>>>>>>> My usual example is a medical sensor based device adds some, a >>>>>>>>>>>> specialized service provider who services the device adds some and a >>>>>>>>>>>> communications service provider adds some. all of thise go in the >>>>>>>>>>>> SIP message. then the access network sends some in the PIDF. >>>>>>>>>>>>>> >>>>>>>>>>>>>> With respect to multiple entities adding data, proxies can't add >>>>>>>>>>>> bodies, but B2BUAs can. >>>>>>>>>>>>> >>>>>>>>>>>>> Well, that is protocol/solution talk - the question is whether >>>>>>>>>>>> there is a REQUIREMENT that multiple entities should be able to add >>>>>>>>>>>> information :) >>>>>>>>>>>>> >>>>>>>>>>>>> (If so, we then have to either mandate B2BUA functionality, or >>>>>>>>>>>> use some other mechanism. For example, data that can be defined as >>>>>>>>>>>> capabilities could be indicated also using feature capability >>>>>>>>>>>> indicators.) >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Christer >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> However, you have pointed out a problem that arose in the >>>>>>>>>>>> evolution of the mechanism. Originally, there was an outer envelope >>>>>>>>>>>> wit the blocks inside it. That would let us know the source of each >>>>>>>>>>>> block because the data provider block is required. The current >>>>>>>>>>>> mechanism doesn't have that. It's a problem. >>>>>>>>>>>>> >>>>>>>>>>>>> Brian >>>>>>>>>>>>> >>>>>>>>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> The draft talks about all kind of different entities that might >>>>>>>>>>>> add additional data to an emergency call. >>>>>>>>>>>>> >>>>>>>>>>>>> First, I think it would be good to have some pictures showing a >>>>>>>>>>>> few different scenarios. >>>>>>>>>>>>> >>>>>>>>>>>>> Second, the draft doesn't seem to describe the case where >>>>>>>>>>>> multiple entities are adding data - for the same call. Will multiple >>>>>>>>>>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, is it >>>>>>>>>>>> not allowed to begin with? >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Christer >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>>>>>>>>> ) >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From brian.rosen@neustar.biz Wed Oct 23 05:57:34 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08AE11E8370 for ; Wed, 23 Oct 2013 05:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.555 X-Spam-Level: X-Spam-Status: No, score=-5.555 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbOIFdQuLQMI for ; Wed, 23 Oct 2013 05:57:27 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6E86F11E81BB for ; Wed, 23 Oct 2013 05:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1382533000; x=1697876721; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=6obaenwW2w SlguG4ybvSYrkbN0nx2G1EhmkyVepb2/U=; b=NQS/2pkBJWqGZytND0k7C9PLvJ bwu3gVf7CVwmqD1QWAaWQqfzWxbXf5h6wgCltZPI2WSx+wthwh7KYIj07EoA== Received: from ([10.31.58.70]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.26484243; Wed, 23 Oct 2013 08:56:38 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 23 Oct 2013 08:57:17 -0400 From: "Rosen, Brian" To: James Winterbottom Thread-Topic: [Ecrit] Can I get some love for draft-marshall-similar-location? Thread-Index: AQHOz1lT9rNNkqG9OUaVMTviEPzK+A== Date: Wed, 23 Oct 2013 12:57:17 +0000 Message-ID: References: <5210EC7A-65DD-40B9-925A-E070C9ABAA82@gmail.com> In-Reply-To: <5210EC7A-65DD-40B9-925A-E070C9ABAA82@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.35] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: mZaF1cmjPDaJcifTvuOYHA== Content-Type: text/plain; charset="Windows-1252" Content-ID: <2FDFD43D430BE4409DADCB14510C740D@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ecrit Subject: Re: [Ecrit] Can I get some love for draft-marshall-similar-location? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 12:57:34 -0000 It is a national matter what "valid" means. In North America, and I believe in the EU, "valid" means dispatch valid, no= t just route valid. If all calls within a state route to the same URI, a l= ocation which has the state, but is otherwise not unique (in a dispatch sen= se) will be marked "invalid". This is EXACTLY the same as current practice= . In North America, MSAG validation is required to put a route in the SR D= B and ALI, and it is dispatch valid. I am not at all sure why batch validation makes any sense. While it might = have some small value when a LIS is initially loaded, in normal operation, = addresses are entered one at a time, and validation should be done at entry= (one at a time). Since there is no draft on batch validation, and so far, no requests, I thi= nk that this draft should proceed. If you care to write a draft that provi= des a batch validation service with multiple levels of validation, I'd be h= appy to read and comment on it. Brian On Oct 23, 2013, at 12:54 AM, James Winterbottom wrote: > Hi Brian, >=20 > I am ambivalent to this draft. I do't think it is essential but I don't t= hink that it hurts to have it either. > I would prefer a more efficient way for a LIS to perform mass location va= lidation than post multiple LoST queries with the validation attribute set = and that the functionality in similar-location be provided in that protocol= /solution. >=20 > I think that it is important to remember that a valid location in the ter= ms of this WG is one that will result in the call being routed to the right= PSAP, it doesn't require location to be accurate enough for dispatch. Inde= ed we do not have a mechanism for requesting validation for the latter case= and this has caused some issues within other SDOs. If the similar-location= draft or something similar proceeds then adding a means to request differe= nt levels of validation may also be a good idea. >=20 >=20 > Cheers > James >=20 >=20 > On 23/10/2013, at 6:03 AM, "Rosen, Brian" wrote= : >=20 >> >> I presented this draft in Berlin. There is some support for it, mostly = from the NENA guys. I think it's pretty helpful. It solves two problems. >>=20 >> When you get a location that you want to put into a LIS, you should vali= date it BEFORE you use it for an emergency call. So, you send a LoST query= and specify validation. >>=20 >> What is valid? >>=20 >> That's undoubtedly a national matter, but one way to look at it is that = it's a set of elements in the LI that describes a UNIQUE location that resp= onders can respond to. A really simple case is a residence that is address= ed by a house number, a street name, a city name, a state/province, and a c= ountry. Provided that the combination of these elements is the location of= one house, it's probably valid. >>=20 >> But, let's say that there is also a county in the name. I give you two = scenarios. In both scenarios, there are two municipalities with the same n= ame in the state/province, but they are in different counties. >>=20 >> In one of the scenarios, the street name only occurs in one of the two m= unicipalities. In the other scenario, it's in both of them. >>=20 >> So, if I send LI that does not have a county, does have the street and (= duplicated) municipality, in scenario one, is it valid? It is UNIQUE, you = know where it is, because there is no Apple Street in Hooverville, Baskin C= ounty, but there is an Apple Street in Hooverville, Robbins County. >>=20 >> Now, it is a national matter whether the LoST server accepts the lack of= a county name for scenario 1. In most areas I am familiar with, County is= not required unless it's needed to differentiate as it is in Scenario 2. >>=20 >> But, the LoST server does know what the County is, and even in Scenario = 1, it might be a really good idea to confirm with the user entering the add= ress that the address is in Robbins County. >>=20 >> In the current RFC5222 definition of LoST, there is no way for the serve= r to return the County name. In Scenario 2, it would return County on the = invalid list, indicating that County was missing, and needs to be provided.= But in Scenario 1, it could either do the same (always require County, ev= en if the address is unique without it), or just return Country, State, Str= eet and House Number as valid. >>=20 >> What the draft does is extend LoST to allow it to return LI to inform th= e querier that this address is valid, and is in Robbins County. That lets = the LIS confirm with the user, and it also let's it populate the LIS entry = with the County, which is a good thing to do if it is confirmed by the user= . >>=20 >> The other problem it solves is how to help the user in Scenario 2. The = query presented has invalid LI, and the response will indicate that County = is invalid. But, the only thing the LIS can do is demand that the user som= e how come up with the name of the County. >>=20 >> A better response would be that the LI given is invalid, but it could be= either 124 Apple St, Hooverville, Baskin County, NJ, US or it could be 124= Apple St, Hooverville, Robbins County, NJ, US. That is, it could offer on= e or more valid addresses as possible candidates for the LI that was offere= d in the query. >>=20 >> The LoST server may not be able to return a small number of valid locati= ons the LI in the query suggests, but if it could, a response of "not that,= but could it be =85.?" is very useful. >>=20 >> This also requires that the LoST server return LI. >>=20 >> We'd really like to push this draft through ecrit. NENA does really nee= d it, and we think it's generally useful for many countries. >>=20 >> Can I get some love here? >>=20 >> >> Brian >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Wed Oct 23 06:03:34 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9403B11E83FD for ; Wed, 23 Oct 2013 06:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.485 X-Spam-Level: X-Spam-Status: No, score=-103.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApH4pgZXx0y2 for ; Wed, 23 Oct 2013 06:03:30 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8882511E81A8 for ; Wed, 23 Oct 2013 06:03:25 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id s14so420668qeb.5 for ; Wed, 23 Oct 2013 06:03:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hmtJd6gHY7fs3rIVH2cmEQ9y+MOTTOiV8RujD0TBOIo=; b=cNdSR5oXQVgVLMPro4CQkqvWm5sABqShE5P9PQNT+ynTKnOVBFLtHE8V5U1MKz44By bQyBboPTvV2mv6sa9WqjymQt8cJffjm0BtkgNTRUhVG64PztVkkXS1JCLpo6t7yKeMjg NUnH+2OHDd/IbI6GTTd8bNdOj7JCLNbB9H+pDcJwum/IzY9j6DBdSFHOe2+RKyrb2thM sFVozOUhU5oUyxRj46xWCIf6ImAPy0hfCY4S8OlRVT/GjYG499PcwvgsgVmyF5iYQm0M gzmVj8ygy7aRIc87NkIZd5xW2NVizjeCT/vh0HKpEZRK1HUQ/Dzt6vx7dNt9Sbd1T3Zn wnAQ== X-Gm-Message-State: ALoCoQkIsJdeG0/luWKOQcuOyAG9XHNKV8W78JMstM2ijCw4DK4h7DjWVTS6xLo5SzD+Xj4rhGaQ X-Received: by 10.224.92.201 with SMTP id s9mr3649913qam.85.1382533404906; Wed, 23 Oct 2013 06:03:24 -0700 (PDT) Received: from [10.33.192.35] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id x1sm61181472qai.6.2013.10.23.06.03.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 06:03:24 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Rosen In-Reply-To: <5267B9D9.2020102@gmx.net> Date: Wed, 23 Oct 2013 09:03:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <29FF70A7-7D9D-4B5E-AC0E-D885D6343EA6@brianrosen.net> References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> <74690D52-E081-419B-8615-DB04ED55B7D2@gmail.com> <27D665B2-BDB4-4C05-A859-78D7DFACD397@brianrosen.net> <34694050-A1CE-492C-9F1C-00945C5E8FCD@gmail.com> <2949DC42-3D5B-4237-9F6A-BABE65A9E42A@brianrosen.net> <5267B9D9.2020102@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1510) Cc: ecrit Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 13:03:34 -0000 I was thinking you would put in all blocks (i.e. =3D).= Every element, including the ProviderInfo block, gets the same id. As I understand your proposal, every block except the ProviderId block = would have nothing added, and the ProviderId blocks would have multiple = entries, one per block beyond ProviderInfo that the provider included, = containing the MIME content-id. =20 While I think my original proposal is slightly better, because does not = depend on knowing info in the MIME wrappers, it would be okay with me to = use your idea Brian. On Oct 23, 2013, at 7:58 AM, Hannes Tschofenig = wrote: > I just tried to create a longer example, as Christer requested, and = the current structure indeed has some limitations (as discussed in this = thread between James and Brian). >=20 > There are two approaches to solve the problem: >=20 > a) Introduce a hierarchical structure within the MIME bodies. >=20 > b) Link the data provider block with other blocks. >=20 > To me, it appears that option (b) is somewhat easier. All we have to = do is the following: >=20 > 1) Add a new element to the ProviderInfo block (let's call it = ) > 2) Add a new element to the other blocks (let's call it ) > 3) Add a requirement that all blocks added by a data provider must = have the same value in , which is then repeated in the = element. >=20 > Of course, we have an id already in the MIME structure (in the form of = a Content-ID). This would allow us to avoid defining the in the = structures but we would instead use the element to enumerate = the content-ids. It does not exist in the XML. Is that a problem? For = the provided-by structure, for example, we do not communite MIME = structures but I suspect that the PIDF document would come from a single = data provider anyway?! >=20 > Ciao > Hannes >=20 > On 10/22/2013 11:28 PM, James Winterbottom wrote: >> I think this clarifies my problem with the current structure. >> The provider would only ever send this block by itself if it doesn't = have anything other to send. This implies that it doesn't know what kind = of provider it actually is which doesn't seem useful. >>=20 >>=20 >> On 23/10/2013, at 8:20 AM, Brian Rosen wrote: >>=20 >>> Because you also need it as a stand alone when that's all the = provider sends, and if you think, as I do, that the average report that = is more than just the provider block will have two or more blocks, it's = repetitive. You don't get anything out of repeating every element of = the provider block. You only want to know which provider sent it. >>>=20 >>> Brian >>> On Oct 22, 2013, at 5:14 PM, James Winterbottom = wrote: >>>=20 >>>> Yes, and so? >>>> This is dead simple with schema and achieves the tie in a totally = unambiguous way. >>>>=20 >>>> On 23/10/2013, at 8:07 AM, Brian Rosen wrote: >>>>=20 >>>>> Because the provider info is itself a block. Repeating it does = nothing. >>>>>=20 >>>>> We would have to make the content of the provider block a = component of every other block. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Oct 22, 2013, at 4:54 PM, James Winterbottom = wrote: >>>>>=20 >>>>>> I am not sure that I understand why it is such a problem to have = provider blocks repeated if a single provider provides more than one = block of information. This addresses the MIME issue and the requirement = to have some kind of chaining unique ID. >>>>>>=20 >>>>>> Cheers >>>>>> James >>>>>>=20 >>>>>> On 23/10/2013, at 7:51 AM, Brian Rosen wrote: >>>>>>=20 >>>>>>> By "fixing" the data structure to be a series of blocks, each = with it's own MIME type and schema, you can't really group them in = useful ways. >>>>>>> When I did the original, a given set of data from one source was = one object, and you could have more than one such object in the body, or = more than one URI to an entire object in the Call-Info. When we split = it up into blocks, we lost the ability to group. >>>>>>>=20 >>>>>>> We could try doing something with mime/multipart hierarchy. I = don't know what is possible. I don't think requiring all blocks from = the same source to have a unique ID in them is brittle. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Oct 22, 2013, at 4:17 PM, James Winterbottom = wrote: >>>>>>>=20 >>>>>>>> I think that that is more brittle. >>>>>>>> If the requirement is that the data provided be firmly linked = to source then tie them together more tightly. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Sent from my iPad >>>>>>>>=20 >>>>>>>> On 23/10/2013, at 6:21 AM, Brian Rosen = wrote: >>>>>>>>=20 >>>>>>>>> I would be inclined to have a "source" attribute in every = block, which could be matched. It could contain any globally unique = string (such as a domain name) that labels the source of each block. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>>=20 >>>>>>>>> On Oct 22, 2013, at 3:16 PM, James Winterbottom = wrote: >>>>>>>>>=20 >>>>>>>>>> One way to do that is through schema structure and = constraints. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPad >>>>>>>>>>=20 >>>>>>>>>> On 23/10/2013, at 5:30 AM, Brian Rosen = wrote: >>>>>>>>>>=20 >>>>>>>>>>> I don't think this is sufficient. I think there has to be a = way to know which data provider which block. >>>>>>>>>>>=20 >>>>>>>>>>> What you have is: >>>>>>>>>>> SP A provided some info >>>>>>>>>>> SP B provided some info >>>>>>>>>>> Info X, don't know who provided it >>>>>>>>>>> Info Y, don't know who provided it >>>>>>>>>>>=20 >>>>>>>>>>> Brian >>>>>>>>>>>=20 >>>>>>>>>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig = wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Hi Christer, Brian, James, >>>>>>>>>>>>=20 >>>>>>>>>>>> I believe you guys raised a couple of issues, namely: >>>>>>>>>>>>=20 >>>>>>>>>>>> * Could we provide more and better examples? We have a = number of examples in the document but we do not illustrate more complex = versions. >>>>>>>>>>>>=20 >>>>>>>>>>>> I am thinking about how to add a longer example. >>>>>>>>>>>>=20 >>>>>>>>>>>> * Did we double-check whether there are any constraints = regarding the number of blocks a single data provider can add and = whether there are problems when multiple data provider add information? >>>>>>>>>>>>=20 >>>>>>>>>>>> My suggestion is obvious: we have to double-check whether = we introduced a bug. >>>>>>>>>>>>=20 >>>>>>>>>>>> * Do we always have information about the source of the = data provider? Brian claimed that we have lost that feature over time. I = double-checked it and there is indeed some fuzziness in the text. Here = is the relevant part: >>>>>>>>>>>>=20 >>>>>>>>>>>> ------ >>>>>>>>>>>>=20 >>>>>>>>>>>> 3.1. Data Provider Information >>>>>>>>>>>>=20 >>>>>>>>>>>> This block is intended to be provided by any service = provider in the >>>>>>>>>>>> path of the call or the access network provider. It = includes >>>>>>>>>>>> identification and contact information. This block SHOULD = be >>>>>>>>>>>> provided by every service provider in the call path, and by = the >>>>>>>>>>>> access network provider. Devices MAY use this block to = provide >>>>>>>>>>>> identifying information. The MIME subtype is "application/ >>>>>>>>>>>> emergencyCall.ProviderInfo+xml". An access network = provider SHOULD >>>>>>>>>>>> provide this block either by value or by reference in the = Provided-By >>>>>>>>>>>> section of a PIDF-LO >>>>>>>>>>>>=20 >>>>>>>>>>>> ------ >>>>>>>>>>>>=20 >>>>>>>>>>>> I believe I hear Brian saying that he wants to have the = data provider block be added whenever data is added. I suggest the = following modification: >>>>>>>>>>>>=20 >>>>>>>>>>>> ------ >>>>>>>>>>>>=20 >>>>>>>>>>>> 3.1. Data Provider Information >>>>>>>>>>>>=20 >>>>>>>>>>>> This block MUST be provided by >>>>>>>>>>>> * any service provider in the path of the call, >>>>>>>>>>>> * the access network provider, and >>>>>>>>>>>> * the device, >>>>>>>>>>>> if these entities act as a source for additional data. The = data provider information block offers identification and contact = information of the data source >>>>>>>>>>>>=20 >>>>>>>>>>>> The MIME subtype is = "application/emergencyCall.ProviderInfo+xml". >>>>>>>>>>>>=20 >>>>>>>>>>>> ------ >>>>>>>>>>>>=20 >>>>>>>>>>>> What do you think? >>>>>>>>>>>>=20 >>>>>>>>>>>> Ciao >>>>>>>>>>>> Hannes >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>>>>>>>>>>> There is a requirement for multiple entities to add = information. I >>>>>>>>>>>>> don't think there needs to be a requirement that it happen = by value, but >>>>>>>>>>>>> its at least desirable. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> James, it's perfectly clear that some blocks need to be = repeated For >>>>>>>>>>>>> example the block that says who provided the data. Others = are more >>>>>>>>>>>>> specialized. So generically, it's a requirement that at = least some >>>>>>>>>>>>> blocks are supplied by multiple enties. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Brian >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Actually, I think that the requirement is more whether a = single >>>>>>>>>>>>> entity should be able to add multiple types if = information. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Cheers >>>>>>>>>>>>> James >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi Brian, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Not sure pictures in ascii art would help, but more = words might. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I think some ascii art, showing the calling device (user = or >>>>>>>>>>>>> sensor), some intermediary ("server") and the PSAP would = help. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> My usual example is a medical sensor based device adds = some, a >>>>>>>>>>>>> specialized service provider who services the device adds = some and a >>>>>>>>>>>>> communications service provider adds some. all of thise = go in the >>>>>>>>>>>>> SIP message. then the access network sends some in the = PIDF. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> With respect to multiple entities adding data, proxies = can't add >>>>>>>>>>>>> bodies, but B2BUAs can. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Well, that is protocol/solution talk - the question is = whether >>>>>>>>>>>>> there is a REQUIREMENT that multiple entities should be = able to add >>>>>>>>>>>>> information :) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> (If so, we then have to either mandate B2BUA = functionality, or >>>>>>>>>>>>> use some other mechanism. For example, data that can be = defined as >>>>>>>>>>>>> capabilities could be indicated also using feature = capability >>>>>>>>>>>>> indicators.) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Christer >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> However, you have pointed out a problem that arose in the >>>>>>>>>>>>> evolution of the mechanism. Originally, there was an = outer envelope >>>>>>>>>>>>> wit the blocks inside it. That would let us know the = source of each >>>>>>>>>>>>> block because the data provider block is required. The = current >>>>>>>>>>>>> mechanism doesn't have that. It's a problem. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The draft talks about all kind of different entities that = might >>>>>>>>>>>>> add additional data to an emergency call. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> First, I think it would be good to have some pictures = showing a >>>>>>>>>>>>> few different scenarios. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Second, the draft doesn't seem to describe the case where >>>>>>>>>>>>> multiple entities are adding data - for the same call. = Will multiple >>>>>>>>>>>>> MIMEs etc be used, are there restrictions, etc etc etc? = OR, is it >>>>>>>>>>>>> not allowed to begin with? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Christer >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>>>>>>>>>> ) >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From hannes.tschofenig@gmx.net Wed Oct 23 06:24:12 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213A211E818E for ; Wed, 23 Oct 2013 06:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPzzoc0XBZWW for ; Wed, 23 Oct 2013 06:24:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6D36C11E8196 for ; Wed, 23 Oct 2013 06:24:04 -0700 (PDT) Received: from [172.16.254.200] ([80.92.115.161]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MgHHO-1VK4QP0eZy-00Nero for ; Wed, 23 Oct 2013 15:24:03 +0200 Message-ID: <5267CE0C.9000604@gmx.net> Date: Wed, 23 Oct 2013 15:24:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Brian Rosen References: <7594FB04B1934943A5C02806D1A2204B1C41F05A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41F8B4@ESESSMB209.ericsson.se> <52669FC8.4060009@gmx.net> <6B55C801-3DB1-44C2-9F26-40420BD8B6B3@brianrosen.net> <638896AF-51FC-4AC9-B55F-A2A59C49DEC8@gmail.com> <835DBA5E-F02B-435E-AE67-04E157272254@brianrosen.net> <0B5A3BCE-B92A-477B-9A7D-922F3B13265B@gmail.com> <58E93B5A-495E-4BB3-9231-944E04460C77@brianrosen.net> <74690D52-E081-419B-8615-DB04ED55B7D2@gmail.com> <27D665B2-BDB4-4C05-A859-78D7DFACD397@brianrosen.net> <34694050-A1CE-492C-9F1C-00945C5E8FCD@gmail.com> <2949DC42-3D5B-4237-9F6A-BABE65A9E42A@brianrosen.net> <5267B9D9.2020102@gmx.net> <29FF70A7-7D9D-4B5E-AC0E-D885D6343EA6@brianrosen.net> In-Reply-To: <29FF70A7-7D9D-4B5E-AC0E-D885D6343EA6@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:5XIuYmVpzaHM90q+cxpcgO5+OGH0x0a9/14wUf6n9/yXSESjRzF I7+R3InzbhZYYAbZJcccucqLSBLJGQOAoykBQIV7dS5heFiQ5o0PcYNdfhRu3Ofx3An9sYr T68fg1amRjUneMJ/nQcAkevaG5OK0HPASfC1uHpbetTPX5nBsQZOiix/cxM8zH+hK+yyPBk JTkyHXPtbex5ju8zfkaig== Cc: ecrit Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-11: multiple entities adding data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 13:24:12 -0000 I am fine with your proposal. In any case, we definitely have to add the functionality. On 10/23/2013 03:03 PM, Brian Rosen wrote: > I was thinking you would put in all blocks (i.e. =). Every element, including the ProviderInfo block, gets the same id. > > As I understand your proposal, every block except the ProviderId block would have nothing added, and the ProviderId blocks would have multiple entries, one per block beyond ProviderInfo that the provider included, containing the MIME content-id. > > While I think my original proposal is slightly better, because does not depend on knowing info in the MIME wrappers, it would be okay with me to use your idea > > Brian. > > > On Oct 23, 2013, at 7:58 AM, Hannes Tschofenig wrote: > >> I just tried to create a longer example, as Christer requested, and the current structure indeed has some limitations (as discussed in this thread between James and Brian). >> >> There are two approaches to solve the problem: >> >> a) Introduce a hierarchical structure within the MIME bodies. >> >> b) Link the data provider block with other blocks. >> >> To me, it appears that option (b) is somewhat easier. All we have to do is the following: >> >> 1) Add a new element to the ProviderInfo block (let's call it ) >> 2) Add a new element to the other blocks (let's call it ) >> 3) Add a requirement that all blocks added by a data provider must have the same value in , which is then repeated in the element. >> >> Of course, we have an id already in the MIME structure (in the form of a Content-ID). This would allow us to avoid defining the in the structures but we would instead use the element to enumerate the content-ids. It does not exist in the XML. Is that a problem? For the provided-by structure, for example, we do not communite MIME structures but I suspect that the PIDF document would come from a single data provider anyway?! >> >> Ciao >> Hannes >> >> On 10/22/2013 11:28 PM, James Winterbottom wrote: >>> I think this clarifies my problem with the current structure. >>> The provider would only ever send this block by itself if it doesn't have anything other to send. This implies that it doesn't know what kind of provider it actually is which doesn't seem useful. >>> >>> >>> On 23/10/2013, at 8:20 AM, Brian Rosen wrote: >>> >>>> Because you also need it as a stand alone when that's all the provider sends, and if you think, as I do, that the average report that is more than just the provider block will have two or more blocks, it's repetitive. You don't get anything out of repeating every element of the provider block. You only want to know which provider sent it. >>>> >>>> Brian >>>> On Oct 22, 2013, at 5:14 PM, James Winterbottom wrote: >>>> >>>>> Yes, and so? >>>>> This is dead simple with schema and achieves the tie in a totally unambiguous way. >>>>> >>>>> On 23/10/2013, at 8:07 AM, Brian Rosen wrote: >>>>> >>>>>> Because the provider info is itself a block. Repeating it does nothing. >>>>>> >>>>>> We would have to make the content of the provider block a component of every other block. >>>>>> >>>>>> Brian >>>>>> >>>>>> On Oct 22, 2013, at 4:54 PM, James Winterbottom wrote: >>>>>> >>>>>>> I am not sure that I understand why it is such a problem to have provider blocks repeated if a single provider provides more than one block of information. This addresses the MIME issue and the requirement to have some kind of chaining unique ID. >>>>>>> >>>>>>> Cheers >>>>>>> James >>>>>>> >>>>>>> On 23/10/2013, at 7:51 AM, Brian Rosen wrote: >>>>>>> >>>>>>>> By "fixing" the data structure to be a series of blocks, each with it's own MIME type and schema, you can't really group them in useful ways. >>>>>>>> When I did the original, a given set of data from one source was one object, and you could have more than one such object in the body, or more than one URI to an entire object in the Call-Info. When we split it up into blocks, we lost the ability to group. >>>>>>>> >>>>>>>> We could try doing something with mime/multipart hierarchy. I don't know what is possible. I don't think requiring all blocks from the same source to have a unique ID in them is brittle. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> On Oct 22, 2013, at 4:17 PM, James Winterbottom wrote: >>>>>>>> >>>>>>>>> I think that that is more brittle. >>>>>>>>> If the requirement is that the data provided be firmly linked to source then tie them together more tightly. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sent from my iPad >>>>>>>>> >>>>>>>>> On 23/10/2013, at 6:21 AM, Brian Rosen wrote: >>>>>>>>> >>>>>>>>>> I would be inclined to have a "source" attribute in every block, which could be matched. It could contain any globally unique string (such as a domain name) that labels the source of each block. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> On Oct 22, 2013, at 3:16 PM, James Winterbottom wrote: >>>>>>>>>> >>>>>>>>>>> One way to do that is through schema structure and constraints. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sent from my iPad >>>>>>>>>>> >>>>>>>>>>> On 23/10/2013, at 5:30 AM, Brian Rosen wrote: >>>>>>>>>>> >>>>>>>>>>>> I don't think this is sufficient. I think there has to be a way to know which data provider which block. >>>>>>>>>>>> >>>>>>>>>>>> What you have is: >>>>>>>>>>>> SP A provided some info >>>>>>>>>>>> SP B provided some info >>>>>>>>>>>> Info X, don't know who provided it >>>>>>>>>>>> Info Y, don't know who provided it >>>>>>>>>>>> >>>>>>>>>>>> Brian >>>>>>>>>>>> >>>>>>>>>>>> On Oct 22, 2013, at 11:54 AM, Hannes Tschofenig wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Christer, Brian, James, >>>>>>>>>>>>> >>>>>>>>>>>>> I believe you guys raised a couple of issues, namely: >>>>>>>>>>>>> >>>>>>>>>>>>> * Could we provide more and better examples? We have a number of examples in the document but we do not illustrate more complex versions. >>>>>>>>>>>>> >>>>>>>>>>>>> I am thinking about how to add a longer example. >>>>>>>>>>>>> >>>>>>>>>>>>> * Did we double-check whether there are any constraints regarding the number of blocks a single data provider can add and whether there are problems when multiple data provider add information? >>>>>>>>>>>>> >>>>>>>>>>>>> My suggestion is obvious: we have to double-check whether we introduced a bug. >>>>>>>>>>>>> >>>>>>>>>>>>> * Do we always have information about the source of the data provider? Brian claimed that we have lost that feature over time. I double-checked it and there is indeed some fuzziness in the text. Here is the relevant part: >>>>>>>>>>>>> >>>>>>>>>>>>> ------ >>>>>>>>>>>>> >>>>>>>>>>>>> 3.1. Data Provider Information >>>>>>>>>>>>> >>>>>>>>>>>>> This block is intended to be provided by any service provider in the >>>>>>>>>>>>> path of the call or the access network provider. It includes >>>>>>>>>>>>> identification and contact information. This block SHOULD be >>>>>>>>>>>>> provided by every service provider in the call path, and by the >>>>>>>>>>>>> access network provider. Devices MAY use this block to provide >>>>>>>>>>>>> identifying information. The MIME subtype is "application/ >>>>>>>>>>>>> emergencyCall.ProviderInfo+xml". An access network provider SHOULD >>>>>>>>>>>>> provide this block either by value or by reference in the Provided-By >>>>>>>>>>>>> section of a PIDF-LO >>>>>>>>>>>>> >>>>>>>>>>>>> ------ >>>>>>>>>>>>> >>>>>>>>>>>>> I believe I hear Brian saying that he wants to have the data provider block be added whenever data is added. I suggest the following modification: >>>>>>>>>>>>> >>>>>>>>>>>>> ------ >>>>>>>>>>>>> >>>>>>>>>>>>> 3.1. Data Provider Information >>>>>>>>>>>>> >>>>>>>>>>>>> This block MUST be provided by >>>>>>>>>>>>> * any service provider in the path of the call, >>>>>>>>>>>>> * the access network provider, and >>>>>>>>>>>>> * the device, >>>>>>>>>>>>> if these entities act as a source for additional data. The data provider information block offers identification and contact information of the data source >>>>>>>>>>>>> >>>>>>>>>>>>> The MIME subtype is "application/emergencyCall.ProviderInfo+xml". >>>>>>>>>>>>> >>>>>>>>>>>>> ------ >>>>>>>>>>>>> >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> Ciao >>>>>>>>>>>>> Hannes >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/07/2013 02:52 PM, Brian Rosen wrote: >>>>>>>>>>>>>> There is a requirement for multiple entities to add information. I >>>>>>>>>>>>>> don't think there needs to be a requirement that it happen by value, but >>>>>>>>>>>>>> its at least desirable. >>>>>>>>>>>>>> >>>>>>>>>>>>>> James, it's perfectly clear that some blocks need to be repeated For >>>>>>>>>>>>>> example the block that says who provided the data. Others are more >>>>>>>>>>>>>> specialized. So generically, it's a requirement that at least some >>>>>>>>>>>>>> blocks are supplied by multiple enties. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Brian >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wednesday, August 7, 2013, James Winterbottom wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Actually, I think that the requirement is more whether a single >>>>>>>>>>>>>> entity should be able to add multiple types if information. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers >>>>>>>>>>>>>> James >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 07/08/2013, at 4:32 PM, Christer Holmberg >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Brian, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Not sure pictures in ascii art would help, but more words might. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think some ascii art, showing the calling device (user or >>>>>>>>>>>>>> sensor), some intermediary ("server") and the PSAP would help. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My usual example is a medical sensor based device adds some, a >>>>>>>>>>>>>> specialized service provider who services the device adds some and a >>>>>>>>>>>>>> communications service provider adds some. all of thise go in the >>>>>>>>>>>>>> SIP message. then the access network sends some in the PIDF. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> With respect to multiple entities adding data, proxies can't add >>>>>>>>>>>>>> bodies, but B2BUAs can. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Well, that is protocol/solution talk - the question is whether >>>>>>>>>>>>>> there is a REQUIREMENT that multiple entities should be able to add >>>>>>>>>>>>>> information :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (If so, we then have to either mandate B2BUA functionality, or >>>>>>>>>>>>>> use some other mechanism. For example, data that can be defined as >>>>>>>>>>>>>> capabilities could be indicated also using feature capability >>>>>>>>>>>>>> indicators.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Christer >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, you have pointed out a problem that arose in the >>>>>>>>>>>>>> evolution of the mechanism. Originally, there was an outer envelope >>>>>>>>>>>>>> wit the blocks inside it. That would let us know the source of each >>>>>>>>>>>>>> block because the data provider block is required. The current >>>>>>>>>>>>>> mechanism doesn't have that. It's a problem. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Brian >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tuesday, August 6, 2013, Christer Holmberg wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The draft talks about all kind of different entities that might >>>>>>>>>>>>>> add additional data to an emergency call. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> First, I think it would be good to have some pictures showing a >>>>>>>>>>>>>> few different scenarios. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Second, the draft doesn't seem to describe the case where >>>>>>>>>>>>>> multiple entities are adding data - for the same call. Will multiple >>>>>>>>>>>>>> MIMEs etc be used, are there restrictions, etc etc etc? OR, is it >>>>>>>>>>>>>> not allowed to begin with? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Christer >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sent from Windows using TouchDown (www.nitrodesk.com >>>>>>>>>>>>>> ) >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Ecrit mailing list >>>>>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mserra@ravemobilesafety.com Wed Oct 23 08:34:21 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8474811E81A0 for ; Wed, 23 Oct 2013 08:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dumIwYiIXeRd for ; Wed, 23 Oct 2013 08:34:15 -0700 (PDT) Received: from server505.appriver.com (server505d.appriver.com [98.129.35.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF3D11E80E7 for ; Wed, 23 Oct 2013 08:34:15 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/23/2013 10:34:10 AM X-Policy: GLOBAL - ravemobilesafety.com X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-138/SG:2 10/23/2013 10:33:44 AM X-GBUdb-Analysis: 0, 98.129.35.1, Ugly c=1 p=-0.961755 Source White X-Signature-Violations: 0-0-0-3754-c X-Note-419: 0 ms. Fail:0 Chk:1349 of 1349 total X-Note: SCH-CT/SI:0-1349/SG:1 10/23/2013 10:34:10 AM X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G325 G326 G327 G328 G332 G333 G443 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.8) with ESMTPS id 124059580 for ecrit@ietf.org; Wed, 23 Oct 2013 10:34:09 -0500 Received: from MBX05.exg5.exghost.com ([169.254.1.144]) by HT09-e5.exg5.exghost.com ([98.129.23.242]) with mapi; Wed, 23 Oct 2013 10:34:09 -0500 From: Matt Serra To: "ecrit@ietf.org" Date: Wed, 23 Oct 2013 10:33:48 -0500 Thread-Topic: draft-ietf-ecrit-additional-data-14: Naming consistency of various parameters / namespaces Thread-Index: Ac7QBUTiVhzR/3bvSKe2lUoM/XI4VA== Message-ID: <6B92B1E73D1E7B468E5C97CAE569CBA12156F6E283@MBX05.exg5.exghost.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] draft-ietf-ecrit-additional-data-14: Naming consistency of various parameters / namespaces X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:34:21 -0000 In reviewing the latest additional data draft (v14) - I noticed that there = are a few inconsistencies that should be addressed. Issues and thoughts ar= e below. =20 I ask that whatever is decided recognize that other forms of additional dat= a will be defined (Additional Caller and Additional Location data), so we s= hould pick names that don't limit our options when those are introduced. 1) Section 9.2 - The purpose parameter in the table should read as 'emergen= cyCallData' per the section title. 2) Section 9.4 - We may want to reconsider renaming the MIME registrations = to match the purpose parameter name. Section 9.4 calls for a pattern of 'e= mergencyCallData.+xml' 3) Section 9.5: the various URN Sub-Namespace registrations are named incon= sistently. We should iron this out: - urn:ietf:params:xml:ns:emergencyCallAddlData - urn:ietf:params:xml:ns:emergencyCallProviderInfo - urn:ietf:params:xml:ns:emergencyCall.SvcInfo - urn:ietf:params:xml:ns:emergencyCall.DevInfo - urn:ietf:params:xml:ns:emergencyCall.SubInfo - urn:ietf:params:xml:ns:emergencyCall.Comment 4) The schema registries in section 9.6 are different still from section 9.= 5. These should agree, no? Thanks, Matthew A. Serra, ENP Sr. Director, Product Management=20 Rave Mobile Safety | Smart911 Mobile:=A0=A0201.245.1557 mserra@ravemobilesafety.com From rg+ietf@qualcomm.com Wed Oct 23 10:40:21 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FE011E8478 for ; Wed, 23 Oct 2013 10:40:21 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drtOMYquf1Qk for ; Wed, 23 Oct 2013 10:40:16 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7BE11E8447 for ; Wed, 23 Oct 2013 10:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1382549970; x=1414085970; h=x-ojodefuego:message-id:x-mailer:date:to:from:subject:cc: content-type; bh=qpI0uy2OUERU831ICp2gmTAUc6FAyhCBjXnrEUi7CN8=; b=d27ELohlKb8Qlo7tk4oORLeZam2VxXgeKVD49IWZcr9BMhBfKIOJaFlx VUE7riXJo3Isq/BnWPchLCcc1EyIeMsca6niWx/9lDYwSSP+SUs6lcNvY xskEDpUsegZInLPTLAc368t37TxLfZIjUNl4OXaeI1dwimQjxmKJhhT/h 8=; X-IronPort-AV: E=McAfee;i="5400,1158,7236"; a="82743580" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 23 Oct 2013 10:39:14 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7236"; a="142151692" Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2013 10:39:13 -0700 Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id r9NHdDBJ016288; Wed, 23 Oct 2013 10:39:13 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7236"; a="562179054" X-ojodefuego: yes Received: from myvpn-r-02506.ras.qualcomm.com (HELO [99.111.97.136]) ([10.64.6.130]) by Ironmsg03-L.qualcomm.com with ESMTP; 23 Oct 2013 10:39:12 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Wed, 23 Oct 2013 10:36:25 -0700 To: ecrit@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Cc: Brian Rosen , "Hannes \(NSN - FI/Espoo\) Tschofenig" Subject: [Ecrit] New draft: Internet Protocol-based In-Vehicle Emergency Calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 17:40:21 -0000 Hi everyone, Here is the draft, discussed in Berlin, focusing on emergency calls placed by in-vehicle systems: ** Internet Protocol-based In-Vehicle Emergency Calls ** https://raw.github.com/hannestschofenig/tschofenig-ids/master/eCall/draft-gellens-ecrit-car-crash-00.txt -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Coding is "90% finished" for half of the total coding time. Debugging is "99% complete" most of the time. --Fred Brooks From rg+ietf@qualcomm.com Wed Oct 23 10:40:21 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBDA11E8447 for ; Wed, 23 Oct 2013 10:40:21 -0700 (PDT) X-Quarantine-ID: <7WPgs3HJfDgc> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -105.855 X-Spam-Level: X-Spam-Status: No, score=-105.855 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WPgs3HJfDgc for ; Wed, 23 Oct 2013 10:40:16 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA4711E847E for ; Wed, 23 Oct 2013 10:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1382549970; x=1414085970; h=x-ojodefuego:message-id:x-mailer:date:to:from:subject:cc: content-type; bh=pYOUmlC7cRBw/ZwSlHBZxOlWA++p8rJHfkPerO8Qfw8=; b=fFzRKwRI628N4031P/mSOzs9uB8a8Kuz2m38wRDJWVPfX+ElktLN7mty NVMkNIsV0dzD5PVbT2qeTO3T8XG46UfdI+LcdIYXERk9ecXQWj/LW90hS 182eu8W7qDsDJoOyXAt/m4ukBOQIAB00vrrLuAV0XrgidmHck4gfsZYB1 0=; X-IronPort-AV: E=McAfee;i="5400,1158,7236"; a="82743582" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 23 Oct 2013 10:39:14 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7236"; a="142151710" Received: from plus.qualcomm.com ([10.52.255.8]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Oct 2013 10:39:14 -0700 Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id r9NHdDBK016288; Wed, 23 Oct 2013 10:39:14 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7236"; a="562179113" X-ojodefuego: yes Received: from myvpn-r-02506.ras.qualcomm.com (HELO [99.111.97.136]) ([10.64.6.130]) by Ironmsg03-L.qualcomm.com with ESMTP; 23 Oct 2013 10:39:13 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Wed, 23 Oct 2013 10:36:47 -0700 To: ecrit@ietf.org From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Cc: "Hannes \(NSN - FI/Espoo\) Tschofenig" Subject: [Ecrit] Next-Generation Pan-European eCall X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 17:40:21 -0000 Hi Everyone, Here is the draft, discussed in Berlin, that focuses on supporting eCall within SIP emergency calling: ** Next-Generation Pan-European eCall ** https://raw.github.com/hannestschofenig/tschofenig-ids/master/eCall/draft-gellens-ecrit-ecall-00.txt -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Men never do evil so completely and cheerfully as when they do it from religious conviction. --Blaise Pascal, 17th-century French mathematician and religious philosopher From hannes.tschofenig@gmx.net Fri Oct 25 05:02:49 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4C211E83D2 for ; Fri, 25 Oct 2013 05:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YupIabZ7JIiy for ; Fri, 25 Oct 2013 05:02:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id E4AE411E83D1 for ; Fri, 25 Oct 2013 05:02:40 -0700 (PDT) Received: from [172.16.254.200] ([80.92.115.161]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MZU7V-1VHAfq3wQn-00LDkM for ; Fri, 25 Oct 2013 14:02:40 +0200 Message-ID: <526A5DF7.2050201@gmx.net> Date: Fri, 25 Oct 2013 14:03:03 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Matt Serra , "ecrit@ietf.org" References: <6B92B1E73D1E7B468E5C97CAE569CBA12156F6E283@MBX05.exg5.exghost.com> In-Reply-To: <6B92B1E73D1E7B468E5C97CAE569CBA12156F6E283@MBX05.exg5.exghost.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:m5kaaCn8NHY+p6wOQEC2+Bby4qzqCaLfGvE0n784aMVPOKg3G+8 serEO0PiLmR5VrHm8pIOlW5MDztXCtYKXuaXnyBVlnwj1rRpG69pxbX7TyWcHsBeo0ekr6P q13iMgEVORzI0tqK3v4k6852U+Zdohf5R58ER4vwYqrdIhyy3ADBGf/Abof8vHjcWnC1ACM i/5O8U1hsTC3u2Nql8soQ== Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-14: Naming consistency of various parameters / namespaces X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 12:02:50 -0000 Hi Matt, thanks for the detailed review and for spotting these inconsistencies. On 10/23/2013 05:33 PM, Matt Serra wrote: > In reviewing the latest additional data draft (v14) - I noticed that > there are a few inconsistencies that should be addressed. Issues and > thoughts are below. > > I ask that whatever is decided recognize that other forms of > additional data will be defined (Additional Caller and Additional > Location data), so we should pick names that don't limit our options > when those are introduced. > > 1) Section 9.2 - The purpose parameter in the table should read as > 'emergencyCallData' per the section title. > Fixed. > 2) Section 9.4 - We may want to reconsider renaming the MIME > registrations to match the purpose parameter name. Section 9.4 calls > for a pattern of 'emergencyCallData.+xml' Makes sense. > > 3) Section 9.5: the various URN Sub-Namespace registrations are named > inconsistently. We should iron this out: > > - urn:ietf:params:xml:ns:emergencyCallAddlData - > urn:ietf:params:xml:ns:emergencyCallProviderInfo - > urn:ietf:params:xml:ns:emergencyCall.SvcInfo - > urn:ietf:params:xml:ns:emergencyCall.DevInfo - > urn:ietf:params:xml:ns:emergencyCall.SubInfo - > urn:ietf:params:xml:ns:emergencyCall.Comment I changed it to urn:ietf:params:xml:ns:emergencycalldata: > > 4) The schema registries in section 9.6 are different still from > section 9.5. These should agree, no? They should be aligned for better readability. Thanks a lot for the review. I am working on the updated version and will post a link to the new document to the list. Might take a little while since I have to fix examples and schemas as well. Ciao Hannes > > Thanks, > > Matthew A. Serra, ENP Sr. Director, Product Management Rave Mobile > Safety | Smart911 Mobile: 201.245.1557 mserra@ravemobilesafety.com > > > _______________________________________________ Ecrit mailing list > Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit > From hannes.tschofenig@gmx.net Sat Oct 26 03:38:10 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4616F11E817C for ; Sat, 26 Oct 2013 03:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.621 X-Spam-Level: X-Spam-Status: No, score=-102.621 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW8pd1KXFVRQ for ; Sat, 26 Oct 2013 03:38:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6C39321F9EFB for ; Sat, 26 Oct 2013 03:38:00 -0700 (PDT) Received: from [172.16.254.200] ([80.92.115.161]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lu7ty-1VjKuR3Dmg-011OBd for ; Sat, 26 Oct 2013 12:37:58 +0200 Message-ID: <526B9B9D.3090707@gmx.net> Date: Sat, 26 Oct 2013 12:38:21 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "ecrit@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Kht/U2R7O5bC+WMmMRSX+/mUexKYn+hQUNIHlc4MsKqbjjed74T tpzLUBWPUkivpHZp0j2dSVlJM8+w3bj3iRDyTEnMC/DGGSm1ZVTUlo/6wsfQPZdAsWgtgSq Ntx+ACdWzeGxqpMRAztvnbVZ+9K/cljzdKN7a2xPsNQFGG9yZc8fE85BJiOwHuqGcxQdEn3 amHpXv9PJBibuzq08NJXA== Subject: [Ecrit] draft-ietf-ecrit-additional-data-15 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 10:38:11 -0000 Hi all, I am working on version -15 of the additional data document and here is the current snapshot: https://github.com/hannestschofenig/tschofenig-ids/blob/master/additional-data/draft-ietf-ecrit-additional-data-15.txt The changes include: * Changes to the URNs and MIME types, as noted by Matt. * Changes to XML schemas and examples caused by the URN / MIME type changes. * Replaced examples from Section 5 with a long example, as requested by Christer. * Added the concept raised by Brian (although not yet added to the XML schema) * Added a missing 'service environment' registry Since there are changes in the entire document I am sure I have messed something up. It would be helpful if someone could look at the document, and particularly at the example! Ciao Hannes From iesg-secretary@ietf.org Mon Oct 28 14:43:40 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166AE11E82A5; Mon, 28 Oct 2013 14:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnRyfoqJ5wSm; Mon, 28 Oct 2013 14:43:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC0911E82AF; Mon, 28 Oct 2013 14:43:34 -0700 (PDT) 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: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131028214334.3354.42785.idtracker@ietfa.amsl.com> Date: Mon, 28 Oct 2013 14:43:34 -0700 Cc: ecrit chair , ecrit mailing list , RFC Editor Subject: [Ecrit] Protocol Action: 'Public Safety Answering Point (PSAP) Callback' to Proposed Standard (draft-ietf-ecrit-psap-callback-13.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 21:43:40 -0000 The IESG has approved the following document: - 'Public Safety Answering Point (PSAP) Callback' (draft-ietf-ecrit-psap-callback-13.txt) as Proposed Standard This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Richard Barnes and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/ Technical Summary After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current situation of a wounded person. A call taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. A solution based on a new header field value, called "psap-callback", for the SIP Priority header field is specified to accomplish the PSAP callback marking. Working Group Summary This document represents strong work group consensus and group participation in having worked out the details of the mechanism described. There were no significant controversies that were not overcome during the development stage. A successful document development history is documented in the email list archive. Document Quality No existing implementations are known to exist. Several vendors have shown interest, and have also been involved in the development and review of the document. Personnel Document shepherd: Roger Marshall (ECRIT co-chair) Responsible Area Director: Richard Barnes (RAI AD) From RMarshall@telecomsys.com Wed Oct 30 08:48:17 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F4F21F9CE9 for ; Wed, 30 Oct 2013 08:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7syQ2kQS-AZo for ; Wed, 30 Oct 2013 08:48:01 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71B2E11E8250 for ; Wed, 30 Oct 2013 08:47:51 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.5/8.14.5) with ESMTP id r9UFlhRg004928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 30 Oct 2013 08:47:43 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.31]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Wed, 30 Oct 2013 08:47:43 -0700 From: Roger Marshall To: "ecrit_ietf.org" Thread-Topic: meeting agenda, charter & milestone changes Thread-Index: Ac7Vg4it0ljI2Tb8S8KccPW7TGX+gA== Date: Wed, 30 Oct 2013 15:47:42 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC497054SEAEXMB1telecomsy_" MIME-Version: 1.0 Cc: "ecrit-chairs@tools.ietf.org" Subject: [Ecrit] meeting agenda, charter & milestone changes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 15:48:18 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC497054SEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see the agenda posted in the Meeting Materials Manager (and included= below), http://www.ietf.org/proceedings/88/agenda/agenda-88-ecrit Note that the Milestones have been updated, while the Charter updates are u= nder review by the ISB & IESG (revised version included at end). -roger marshall. *** ECRIT Agenda - 09:00-11:30, Monday, November 4, 2013 Vancouver 10 min * Agenda Bashing, Draft Status Update (Chairs) 20 min * Additional Data related to an Emergency Call (Hannes) http://www.ietf.org/id/draft-ietf-ecrit-additional-data-14.txt 15 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 15 min * Updating Additional Data related to an Emergency Call using Subscr= ibe/Notify (Brian) http://www.ietf.org/id/draft-rosen-ecrit-addldata-subnot-00.txt 10 min * A LoST extension to support return of complete and similar locatio= n info (Brian) http://www.ietf.org/id/draft-marshall-ecrit-similar-location-02.txt 20 min * Internet Protocol-based In-Vehicle Emergency Calls (Randy) 20 min * Next-Generation Pan-European eCall (Randy) Discussion *** Updated (as proposed) ECRIT Charter Description of Working Group: In a number of areas, the public switched telephone network (PSTN) has been configured to recognize an explicitly specified number (usually one that is short and easily memorized) as a request for emergency services. These numbers (e.g., 911, 112) are related to an emergency service context and depend on a broad, regional configuration of service contact methods and a geographically-constrained approach for service delivery. These calls are intended to be delivered to special call centers equipped to manage emergency response. Successful delivery of an emergency service call within those systems requires an association of both the physical location of the originating device along with appropriate call routing to an emergency service center. Calls placed using Internet technologies do not use the same systems Mentioned above to achieve those same goals, and the common use of overlay networks and tunnels (either as VPNs or for mobility) makes meeting these goals even more challenging. There are, however, Internet technologies available to manage location and to perform call routing. This working group will describe where and how these mechanis= ms may be used. The group will show how the availability of location data and call routing information at different steps in the call session setup would enable communication between a user and a relevant emergency response center. Though the term "call routing" is used, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Beyond human initiated emergency call request mechanisms, this group wi= ll develop new methods to request emergency assistance, such as sensor initiated emergency requests, and additional processes specified that address topics such as authentication of location, service URN definiti= on and use, augmented information that could assist emergency call takers = or responders. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. This group is considering emergency services calls which might be made by any user of the Internet, as opposed to government or military services that may impose very different authentication and routing requirements. While this group anticipates a close working relationship with groups such as NENA, EENA, 3GPP, and ETSI , any solution presented must be general enough to be potentially useful in or across multiple regions or jurisdictions, and it must be possible to use without requiring a single, central authority. Further, it must be possible for multiple delegations within a jurisdiction to be handled independently, things such as call routing for specific emergency types, media types, language contents, etc., may be routed differently depending on established policies and availability. This working group cares about privacy and security concerns, and will address them within its documents. 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_FBD5AAFFD0978846BF6D3FAB4C892ACC497054SEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see the agenda = posted in the Meeting Materials Manager (and included below),

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

 

Note that the Milestones have been updated, while th= e Charter updates are under review by the ISB & IESG (revised version i= ncluded at end).

 

-roger marshall.

 

***

 

ECRIT Agenda - 09:00-11:30, Monday, November 4, 2013 Vanco= uver

 

 

10 min * Agenda Bashing, Draft Status Update (Chairs)=

 

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

http://www.ietf.org/id/draft-ietf-ecrit-additional-data-14= .txt

 

15 min * Common Alerting Protocol (CAP) based Data-Only Em= ergency Alerts using the Session Initiation Protocol (Brian)

http://www.ietf.org/id/draft-ietf-ecrit-data-only-ea-06.tx= t

 

15 min * Updating Additional Data related to an Emergency = Call using Subscribe/Notify (Brian)

http://www.ietf.org/id/draft-rosen-ecrit-addldata-subnot-0= 0.txt

 

10 min * A LoST extension to support return of complete an= d similar location info (Brian)

http://www.ietf.org/id/draft-marshall-ecrit-similar-locati= on-02.txt

 

20 min * Internet Protocol-based In-Vehicle Emergency Call= s (Randy)

 

20 min * Next-Generation Pan-European eCall (Randy)

 

Discussion

 

***

 

Updated (as proposed) ECRIT Charter

 

Description of Working Group:

 

    In a number of areas, the public switch= ed telephone network (PSTN) has

    been configured to recognize an explici= tly specified number (usually

    one that is short and easily memorized)= as a request for emergency

    services.  These numbers (e.g., 91= 1, 112) are related to an emergency

    service context and depend on a broad, = regional configuration of

    service contact methods and a geographi= cally-constrained approach for

    service delivery.  These calls are= intended to be delivered to special

    call centers equipped to manage emergen= cy response. Successful

    delivery of an emergency service call w= ithin those systems requires

    an association of both the physical loc= ation of the originating device

    along with appropriate call routin= g to an emergency service center.

 

    Calls placed using Internet technologie= s do not use the same systems

    Mentioned above to achieve those same g= oals, and the common use of

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

    meeting these goals even more chal= lenging.  There are, however,

    Internet technologies available to= manage location and to perform call

    routing.  This working group = will describe where and how these mechanisms

    may be used. The group will show h= ow the availability of location data

    and call routing information at di= fferent steps in the call session

    setup would enable communication b= etween a user and a relevant emergency

    response center. Though the term &= quot;call routing" is used,

    it should be understood that some = of the mechanisms which will be

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

 

    Beyond human initiated emergency call r= equest mechanisms, this group will

    develop new methods to request eme= rgency assistance, such as sensor

    initiated emergency requests, and = additional processes specified that

    address topics such as authenticat= ion of location, service URN definition

    and use, augmented information tha= t could assist emergency call takers or

    responders.

 

    Explicitly outside the scope of th= is group is the question of

    pre-emption or prioritization of emerge= ncy services traffic. This

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

    any user of the Internet, as opposed to= government or military

    services that may impose very different= authentication and routing

    requirements.

 

    While this group anticipates a close wo= rking relationship with groups

    such as NENA, EENA, 3GPP, and ETSI , an= y solution presented must be

    general enough to be potentially u= seful in or across multiple regions

    or jurisdictions, and it must be p= ossible to use without requiring a

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

    delegations within a jurisdiction = to be handled independently, things

    such as call routing for specific = emergency types, media types, language

    contents, etc.,  may be route= d differently depending on established

    policies and availability.<= o:p>

 

    This working group cares about privacy = and security concerns, and will

    address them within its documents.

 

 

 

 

 

 

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_FBD5AAFFD0978846BF6D3FAB4C892ACC497054SEAEXMB1telecomsy_-- From brian.rosen@neustar.biz Wed Oct 30 14:29:46 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67BD11E8269 for ; Wed, 30 Oct 2013 14:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHpqAKlWdO2e for ; Wed, 30 Oct 2013 14:29:42 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFDA11E81BE for ; Wed, 30 Oct 2013 14:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1383168744; x=1698526204; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=ATwjQspWqa cwSHB1FFXCelJH4YeHKaEoVVC286yZxBo=; b=duM27Nn0FSIaQ8UW6AADpNKzOu r6Ii8mOEgorJwGSYnKBYXUqBRSRcdDVi+c0b9jcpQWe3avhw+bnx5jv9NdYQ== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.32967389; Wed, 30 Oct 2013 17:32:23 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.60]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 30 Oct 2013 17:29:33 -0400 From: "Rosen, Brian" To: ecrit Thread-Topic: Dealing with Planned Changes in a LoST server Thread-Index: AQHO1bcfHHP8UKXGIkmlxbpCpFK0TA== Date: Wed, 30 Oct 2013 21:29:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.192.35] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: JpgbwbcW1bWeet+oAOWHlA== Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Dealing with Planned Changes in a LoST server X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 21:29:46 -0000 Although we usually think of the data that drives routing and validation st= ored in a LoST server as relatively static, it=92s not completely static. = Things change, slowly, over time. A good example is =93annexation=94, whi= ch might be known by a different term in countries outside of North America= . Annexation is a process where a municipality =93annexes=94 a portion of = the County it is located in, which typically was not part of any other muni= cipality prior to annexation (we would call an area that is not part of a m= unicipality =93unincorporated=94). When that happens, the A3 element (Municipality/City name) changes. Other = changes may also occur. Routing changes also occur, and locations that ha= ve the old address could route incorrectly after the annexation if they ar= e not updated in the LIS. Annexation is a planned event. It happens at some time decided upon in adv= ance, and well publicized. Re-addressing is done, but isn=92t effective un= til the annexation date/time. What matters to ecrit is that if a location was validated and stored in a L= IS with the old A3 (if there even was an A3), the value in the LIS becomes = incorrect as of the annexation date. It needs to be updated, and further, = it needs to be updated to a validated content. The change to the LIS needs= to happen coincident with the annexation. Of course, we have no mechanism to support this in LoST. The best we can d= o is recommend to LIS operators that they periodically revalidate the entir= e content of the LIS. The frequency of this re-validation is critical, too= short and it puts a huge load on the LoST server, too long and bad data pe= rsists in the LIS for too long. And, note that even if the LIS knew the ch= ange was coming, it can=92t validate the new content until after the annexa= tion. NENA is very concerned about this issue. 30 day revalidation is a = long time to go before discovering a change like an annexation, and yet wit= h 30 days, the load on the server for revalidation is orders of magnitude m= ore than for regular emergency call service. I have written a draft which addresses this problem by extending LoST in 3 = ways: 1. A new element added to request. This element, , has two attributes, a uri and an asOf date. The uri is stored by the= LoST server against the location in the request. If the location becomes = (or, really, will become) invalid, the server will use the uri to push a no= tification of that invalidation. The asOf attribute is a date/time value t= hat asks the server to validate as of the date in the attribute, which allo= ws the client to do the validation ahead of the planned change. 2. a object that contains an asOf attribute. This ob= ject is pushed to the uri stored by the server in the case of a planned cha= nge. The asOf attribute specifies when the change becomes effective. 3. A notStored warning that is used by the LoST server to inform the client= that although it supplied a uri, the server was unable to store it. This = may occur because of policy in the server, or exceeding a storage limit, or= some other condition where the server is unable to store the uri. The storage happens only on a valid location. The window is currently closed on submitting drafts, but you can find this = at: https://www.dropbox.com/s/wq9c4t8yn0nhnws/draft-rosen-ecrit-lost-planned-ch= anges-00.txt=