From nobody Sun Apr 5 19:22:46 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17001AD1C3; Sun, 5 Apr 2015 19:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdq1lu-gjC8H; Sun, 5 Apr 2015 19:22:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3901AD17F; Sun, 5 Apr 2015 19:22:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150406022241.21381.49449.idtracker@ietfa.amsl.com> Date: Sun, 05 Apr 2015 19:22:41 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-held-routing-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 02:22:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : A Routing Request Extension for the HELD Protocol Authors : James Winterbottom Hannes Tschofenig Laura Liess Filename : draft-ietf-ecrit-held-routing-02.txt Pages : 13 Date : 2015-04-05 Abstract: In many circumstances public LoST servers or a distributed network of forest guides linking public LoST servers is not available. The general ECRIT calling models breakdown without publically accessible LoST servers. Sometimes location servers may have access to emergency routing information. This document defines an extension to the HELD protocol so a location request can include a request for routing information and allowing the subsequent location response to include routing information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-held-routing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-held-routing-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 5 19:29:05 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC78A1AD2B2 for ; Sun, 5 Apr 2015 19:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTtnofEtRI9G for ; Sun, 5 Apr 2015 19:29:01 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7FF1A6FF9 for ; Sun, 5 Apr 2015 19:29:01 -0700 (PDT) Received: by pdbni2 with SMTP id ni2so30249785pdb.1 for ; Sun, 05 Apr 2015 19:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=gaRPz0c28DqzpkM9dOm5UXxdvUglGyjTWAztUhUlMoE=; b=OX/EYr7zA0+P1jtaAVg6/OR+wpL9neUGL790wLjAfVsxDm8Q0LieI2StIYK7GsVs54 UyYcpP5XkGjSDjdI7YpcCxaDbHV2YCwqN32HgnWGY4HXm3CH6KHY47IOTqLsfaRdOSFL fHnWunIi1vk04OUVpfaESMgkInWc4eb4INZXCDbOPQQiX+VZ4sRRnnfY9ybklVRreyKF IEh+OEh3e54GgdvZprBt42/1ATTJ17AZK2XbWpv55/O9VJFg7Le0i3NrR4kbdGj0buYM xjboCNNNXjmu4oRsnPo2oZEEgg+C04cI6c1b1kYuHqttIT8oigKynObIGuCzW9GUpaD+ FwVA== X-Received: by 10.70.138.70 with SMTP id qo6mr21787034pdb.163.1428287341527; Sun, 05 Apr 2015 19:29:01 -0700 (PDT) Received: from [192.168.1.100] ([123.208.225.214]) by mx.google.com with ESMTPSA id c15sm2760053pbu.81.2015.04.05.19.28.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Apr 2015 19:29:00 -0700 (PDT) From: James Winterbottom Content-Type: multipart/alternative; boundary="Apple-Mail=_360C9C80-6F95-403C-880A-D1BDB5E48864" Date: Mon, 6 Apr 2015 12:28:56 +1000 References: <20150406022241.21381.81915.idtracker@ietfa.amsl.com> To: "ecrit_ietf.org" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Ecrit] Fwd: New Version Notification for draft-ietf-ecrit-held-routing-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 02:29:04 -0000 --Apple-Mail=_360C9C80-6F95-403C-880A-D1BDB5E48864 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi All, This update to HELD routing includes the only level agreement that we = have been able to reach on the list, namely the inclusion of an = extension point to the service element, which probably should have been = there anyway. So far there are 4 people against adding anything extra into the draft = and only one person asking for more stuff to be added. Cheers James > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: "Laura Liess" , "James Winterbottom" = , "Hannes Tschofenig" = , "Laura Liess" , "Hannes = Tschofenig" , "James Winterbottom" = > Subject: New Version Notification for = draft-ietf-ecrit-held-routing-02.txt > Date: 6 April 2015 12:22:41 pm AEST >=20 >=20 > A new version of I-D, draft-ietf-ecrit-held-routing-02.txt > has been successfully submitted by James Winterbottom and posted to = the > IETF repository. >=20 > Name: draft-ietf-ecrit-held-routing > Revision: 02 > Title: A Routing Request Extension for the HELD = Protocol > Document date: 2015-04-05 > Group: ecrit > Pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-ecrit-held-routing-02.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-ecrit-held-routing/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-held-routing-02 >=20 > Abstract: > In many circumstances public LoST servers or a distributed network = of > forest guides linking public LoST servers is not available. The > general ECRIT calling models breakdown without publically accessible > LoST servers. Sometimes location servers may have access to > emergency routing information. This document defines an extension = to > the HELD protocol so a location request can include a request for > routing information and allowing the subsequent location response to > include routing information. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_360C9C80-6F95-403C-880A-D1BDB5E48864 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi All,

This update to HELD routing includes the only level agreement = that we have been able to reach on the list, namely the inclusion of an = extension point to the service element, which probably should have been = there anyway.
So far there are 4 people against = adding anything extra into the draft and only one person asking for more = stuff to be added.

Cheers
James


Begin forwarded message:

From: = internet-drafts@ietf.org
To: "Laura Liess" <L.Liess@telekom.de>, = "James Winterbottom" <a.james.winterbottom@gmail.com>, "Hannes Tschofenig" = <hannes.tschofenig@gmx.net>, "Laura Liess" <l.liess@telekom.de>, = "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, "James Winterbottom" = <a.james.winterbottom@gmail.com>
Subject: = New Version = Notification for draft-ietf-ecrit-held-routing-02.txt
Date: = 6 April 2015 12:22:41 pm = AEST


A new version of I-D, draft-ietf-ecrit-held-routing-02.txt
has been successfully submitted by James Winterbottom and = posted to the
IETF repository.

Name: = = draft-ietf-ecrit-held-routing
Revision: 02
Title:= = A Routing Request Extension for the HELD Protocol
Document date: 2015-04-05
Group:= = ecrit
Pages: 13
URL: =            http://www.ietf.org/internet-drafts/draft-ietf-ecrit-held-routi= ng-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-ecrit-held-routing/=
Htmlized:       http://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02=
Diff: =           http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-held-routin= g-02

Abstract:
=   In many circumstances public LoST servers or a distributed = network of
  forest guides linking public LoST = servers is not available.  The
  general = ECRIT calling models breakdown without publically accessible
  LoST servers.  Sometimes location servers = may have access to
  emergency routing = information.  This document defines an extension to
=   the HELD protocol so a location request can include a = request for
  routing information and allowing = the subsequent location response to
  include = routing information.




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.

The IETF = Secretariat


= --Apple-Mail=_360C9C80-6F95-403C-880A-D1BDB5E48864-- From nobody Thu Apr 9 10:33:37 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982D61B2FAD for ; Thu, 9 Apr 2015 10:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIDzRlwLkv9z for ; Thu, 9 Apr 2015 10:33:34 -0700 (PDT) Received: from server907.appriver.com (server907a.appriver.com [204.232.250.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC41E1A88A8 for ; Thu, 9 Apr 2015 10:33:33 -0700 (PDT) X-Note-AR-ScanTimeLocal: 4/9/2015 1:33:31 PM X-Note-AR-Scan: None - PIPE Received: by server907.appriver.com (CommuniGate Pro PIPE 6.0.8) with PIPE id 4162943; Thu, 09 Apr 2015 13:33:31 -0400 Received: from [10.246.0.39] (HELO smtp.us.exg7.exghost.com) by server907.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 4162933 for ecrit@ietf.org; Thu, 09 Apr 2015 13:33:29 -0400 Received: from DAGN04A-S1E7.exg7.exghost.local (192.168.244.53) by DAGN04B-S1E7.exg7.exghost.local (192.168.244.51) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 9 Apr 2015 13:33:28 -0400 Received: from DAGN04A-S1E7.exg7.exghost.local ([fe80::d165:924f:d3c0:8385]) by DAGN04A-S1E7.exg7.exghost.local ([fe80::d165:924f:d3c0:8385%22]) with mapi id 15.00.1076.000; Thu, 9 Apr 2015 13:33:28 -0400 From: Matt Serra To: "ecrit@ietf.org" Thread-Topic: Thoughts on draft-ietf-ecrit-additional-data v29 Thread-Index: AdBy3SFubx37tzDBRKSbvKpqnIhM9w== Date: Thu, 9 Apr 2015 17:33:28 +0000 Message-ID: <722c8dad4f264f72b686fb1edb238e2a@DAGN04A-S1E7.exg7.exghost.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.244.1] x-exclaimer-md-config: 952e3d35-ca29-4b9e-94e1-a56fe70f6560 x-rerouted-by-exchange: Content-Type: multipart/related; boundary="_004_722c8dad4f264f72b686fb1edb238e2aDAGN04AS1E7exg7exghostl_"; type="multipart/alternative" MIME-Version: 1.0 X-Note-AR-ScanTimeLocal: 4/9/2015 1:33:29 PM X-Policy: GLOBAL - UNKNOWN X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 4/8/2015 10:02:13 PM UTC X-Virus-Scan: V- X-Note: ICH-CT/SI:0-692/SG:1 4/9/2015 1:33:12 PM X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-720/SG:8 4/9/2015 1:33:12 PM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=1 p=-0.981501 Source White X-Signature-Violations: 0-0-0-24279-c X-Note-419: 15.6265 ms. Fail:0 Chk:1321 of 1321 total X-Note: SCH-CT/SI:0-1321/SG:1 4/9/2015 1:33:20 PM X-Note: Spam Tests Failed: X-Country-Path: ->->PRIVATE-> X-Note-Sending-IP: 10.246.0.39 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G22 G272 G273 G274 G275 G279 G280 G394 G406 G411 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID Archived-At: Subject: [Ecrit] Thoughts on draft-ietf-ecrit-additional-data v29 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 17:33:36 -0000 --_004_722c8dad4f264f72b686fb1edb238e2aDAGN04AS1E7exg7exghostl_ Content-Type: multipart/alternative; boundary="_000_722c8dad4f264f72b686fb1edb238e2aDAGN04AS1E7exg7exghostl_" --_000_722c8dad4f264f72b686fb1edb238e2aDAGN04AS1E7exg7exghostl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All - It's been a while since I've read the doc front to back and I have a few ob= servations / questions I'd like to submit to the group. 4. Data Provider Information and deriving "intent"/"context": - In theory, a given data provider can provide any combination of = the defined structures - As I understand, this mechanism will be expanded to carry more t= han call-describing information (as is the focus of the current document). = For example, information about the caller (medical info), and perhaps thei= r emergency contacts. - Arguably, the only mechanism provided to distinguish the "intent= " or "context" of the provided data to infer it which blocks transmitted by= the data provider. As some of the blocks will likely be reused across sce= narios (e.g. data provider and comments), some ambiguity could be introduce= d. - Recipients of this data may want an easier way to audit the data= accompanying a call, so they can filter out the data relevant to the busin= ess function the receiving system performs. - Options: o Add a field to the Provider-Info block where the Data Provider could id= entify the intent of the set of data being passed over o Extend the valid values in the "TypeOfProvider". I'm open to this, but= it could mean a given provider would appear with different TypeOfProvider = values if they source multiple kinds of data. It is also possible that thi= s field could become overloaded. o Do nothing. Assume a given data-set will contain a small number of blo= cks, and that the blocks are self-describing. - Thoughts? 4.1 Data Provider information. I believe a Data Provider could also supply= this block. There are and will be entities that are neither a service pro= vider or an access network provider. This may also suggest we extend the v= alid values in 4.1.4 Thanks, Matt [rave_email_signature] Matthew A. Serra, ENP Sr. Director, Product Management Mobile: 201.245.1557 mserra@ravemobilesafety.com --_000_722c8dad4f264f72b686fb1edb238e2aDAGN04AS1E7exg7exghostl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All –

 

It’s been a while since I’ve read the do= c front to back and I have a few observations / questions I’d like to= submit to the group.

 

4. Data Provider Information and deriving “int= ent”/”context”:

-     &= nbsp;    In theory, a given data provider can provide any co= mbination of the defined structures

-     &= nbsp;    As I understand, this mechanism will be expanded to= carry more than call-describing information (as is the focus of the curren= t document).  For example, information about the caller (medical info)= , and perhaps their emergency contacts.

-     &= nbsp;    Arguably, the only mechanism provided to distinguis= h the “intent” or “context” of the provided data to= infer it which blocks transmitted by the data provider.  As some of t= he blocks will likely be reused across scenarios (e.g. data provider and comments), some ambiguity could be introduced.

-     &= nbsp;    Recipients of this data may want an easier way to a= udit the data accompanying a call, so they can filter out the data relevant= to the business function the receiving system  performs.

-     &= nbsp;    Options:

o   Add a field to the Provider-Info block where= the Data Provider could identify the intent of the set of data being passe= d over

o   Extend the valid values in the “TypeOf= Provider”.  I’m open to this, but it could mean a given pr= ovider would appear with different TypeOfProvider values if they source mul= tiple kinds of data.  It is also possible that this field could become overloaded. 

o   Do nothing.  Assume a given data-set wi= ll contain a small number of blocks, and that the blocks are self-describin= g.

-     &= nbsp;    Thoughts?

 =

4.1 Data Provider information.  I believe a Dat= a Provider could also supply this block.  There are and will be entiti= es that are neither a service provider or an access network provider. = This may also suggest we extend the valid values in 4.1.4

 

Thanks,

 

Matt

 

3D"rave_email_signature"

&nbs= p; Matthew A. Serra, ENP
  Sr. Director, P= roduct Management
  Mobile:  201.245.1557
  mserra@ravemobilesafety.com

 

 

--_000_722c8dad4f264f72b686fb1edb238e2aDAGN04AS1E7exg7exghostl_-- --_004_722c8dad4f264f72b686fb1edb238e2aDAGN04AS1E7exg7exghostl_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3039; creation-date="Thu, 09 Apr 2015 17:33:28 GMT"; modification-date="Thu, 09 Apr 2015 17:33:28 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAKoAAAA4CAYAAABt2GPKAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAAAyJpVFh0WE1MOmNvbS5hZG9iZS54bXAAAAAAADw/eHBhY2tldCBiZWdp bj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+IDx4OnhtcG1ldGEgeG1sbnM6 eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuMC1jMDYwIDYxLjEz NDc3NywgMjAxMC8wMi8xMi0xNzozMjowMCAgICAgICAgIj4gPHJkZjpSREYgeG1sbnM6cmRmPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4gPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIgeG1sbnM6eG1wPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv IiB4bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RS ZWY9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtcDpD cmVhdG9yVG9vbD0iQWRvYmUgUGhvdG9zaG9wIENTNSBNYWNpbnRvc2giIHhtcE1NOkluc3RhbmNl SUQ9InhtcC5paWQ6RTRDQ0FBRDE4ODI2MTFFMzkwNzRCNERGRkY0MDc3Q0YiIHhtcE1NOkRvY3Vt ZW50SUQ9InhtcC5kaWQ6RTRDQ0FBRDI4ODI2MTFFMzkwNzRCNERGRkY0MDc3Q0YiPiA8eG1wTU06 RGVyaXZlZEZyb20gc3RSZWY6aW5zdGFuY2VJRD0ieG1wLmlpZDpFNENDQUFDRjg4MjYxMUUzOTA3 NEI0REZGRjQwNzdDRiIgc3RSZWY6ZG9jdW1lbnRJRD0ieG1wLmRpZDpFNENDQUFEMDg4MjYxMUUz OTA3NEI0REZGRjQwNzdDRiIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRGPiA8L3g6eG1w bWV0YT4gPD94cGFja2V0IGVuZD0iciI/PlzaqucAAAhTSURBVHja7F1bbttGFB0H+Y8W0ALsd9HG XoGlFVj+LVqIXoGsFchegaUVmAKK/kZZgekVhEXRb7NA/6uuwJ3r3gkmjETeMxyKD88FFCUK533m 3MfckU6en59VkCBdl7f0x7c//tIGWnf6lenXo35t//7j1+yYjX/zw88j/fakXyNhkVT3cSKo91S/ fQK68p2uN/c8tgf9NhY+nuj2r6yyVO6hYzidvGmx8RFP5pIWVk/Qk35dM4COIdcASEnGvIilwhsu BeqNPYM0AkBKsu4Do77pUF9ogu8YtOMmG+LNMHcouhQ+twHqnHse3hJ4Nj22JhsCUG3APmgwxQ22 gbIpyqqJfpOq85GvsfIGnA6NTbsKVCP3TYC1Bps2yaozT8OLgQ2Y6w21DUD1B9bTjrApxKpaVmCd PsaJbMDesOlnrx+QHGQKW85BI98I2a0TH4P1wKY2q6YV6n+n20sAZ4n6dVVjbFM2myRCEZdk0EDV C3BTEyjXoMFPbBN5CuHUZdMvWFX3qcq7XwNAneo6FwRwxz4h5kNSox1bbuvgobOqnyaHB3YJFp3W bdsjm4ptVfaopV71SDmGqjgkNUgnqlUblY34FCjigwWlbCoFltRWRUDhupGQclvfBwxDd6Yej9UQ yKYLWkyPrJqwTSiRiG1NdGwIE/eOTfvg9R/b00/Z7pQuZhOsioaqpoDGyQR2dQBqDXE+PQHZdM0s mAJtShxDxMOess3ZhNrvJZu2DdQL4Nk6LCBl02IA3Bursk2Y+AYftyuNv+7YDOmlvG2jUT5xkk6w cygFZNPbom2pyxNbSthtJthMG8CWjNlW9mkmNMGm53qObhqESmIcv7dHBigaR90VAdQgmyYHFvdO Aiw9ttsyb5rMCf1MJtygL+f/ZQzI5gHiRK0aWNKxcjvEQTSpE1Ajxx30jhcIHdSVayilDpsWbMul EOz0XNXJEgH/HlD/SQXrIsy0Uz0WGKgKO1VyFQLnZc0UNCmb0gJuD7AgHYOuhWOWsCqZE3fCfp3S +X/JHLwKJ6qrXr9R9Wd1QIp6+hVsgzggS8+gmZfY+MjNhCwA1Z9kDNAbD2oKYdOVR489FoSWEODH B248tO1EvWqgkg1L11HuwThiHTaV2m6IQ7f0CPyvbFFOB5Ta+r3KOfVpox5DaGEo6D1xVFlIhpSI bQhcuj+pECCVtqrCQlXzAut3yTZNlHvap1TLOgE1Bzv2nkETKXmupOIydB3lDPH6QTbNGVSI/Yyw 6lUJ8ClUlQvn5OX8n5gRPNc/Rs7pX8c6kj1aPiqrrDkw0SMO5SBJ0wibNhnBkLDqrZKHqmYcmYiB PvQ+JNWKjUpqnO+PI1ns4isaDeSb1pWqTbAFWNqc/7+qkFSrzhSftiAqSZr25it73yerRiXzgKrm D4D51Muc0y56/YgXfd5DNpWyKsJ6yOW/QbFpa0Dl3S716CUs0jU2lbJqruRJ2ogfkQ4NqG2Gp6QJ GpFHNt2pGrmtBUdPynBVOQBr5eFOmKO2CkCVhDY81YOw6cJHTiZvjn98RADAUFXlRuxzzmlXgZqq muEhNG7qaxEd7+wvKljw3kPXjm2bLjlnt3Gs9OIqSkkGPcKmvk9QEBUbV3xLIRKqKpNBsmmbXr+q a/A72KYrz/3PlfyKjEkYP8jQHkCWDC0k1QmggjKuyabrhk5pEFadV7BqXbW9VgOWtoEq9cDf12DT xlQieFu1ilVz5R6qGkTOaZeBKlWdxSvECJs2rRKhROiGWHWjBi5tAxWZ4PuCF92EenZhVWJr6Uao YtUUqMt7NKPTEn4VJUhg1CBBPMlLwP/fn74fh6kI0nmgqu79rlCQIHuBOglTESQ4U0GCBGcqyGty poyNevvutz9T85/6c4pdRvq10Z8nZRXpZ02M0GTk51xfXtUJq31lld3YfTlQLlb/X3xb6Gezquf0 M2ITR5ehfNN9X5BWORdAGzfWfO14vjJhWZrri+KaOYynau72+i9lc3mojJZMl1tUzMXn8ejPCHuE wcww6phfM6sgPRTz55Fg7qhzSwYZDZySgT/xBFVJsQ0q+8B9KJOIy46EzyEyEtZdB6QmRS7jtiRj NrIsrllD46Eyrr+BFQFtJtyOfbBzx+U/FvNRCSAmGz0GJj3mRmh3rvgzOnX6xBMq+RUUYqobqz7D 5rlqVxYSxnKQc5uZ9JjpNw0+SMasnzVfh079ivW/qY+7BseTIdrIGpPZjJVtkubVz798IR2XSxmP CZW1gUoJEVMCCau2GU+YZIdfcGMrq+FM12UaEy0cd9DU5+vaSF2ZFeLMicScEQgBc6zrfuK5f9T1 nkj7xGuzYDKgjb1yGE8uNGMia21I0iY2LxGVbofWfm5hYGGHp0h+Z1a80A9nDNCVKjmbLqiVvTsR ULnRnr9HHQBrUbOkPlieF2XHC0JzfM3/PivbCGwa0OZfMRnk6uuv/ZGOJ1WyzLJIfX0bI21ovhds RhIWr4ymKKr+DXdox6+PQqDmZhILkzxW8sx1W/WbO0m1fnbRk0yaYA+j3kgL8Xhjtsno/UYAtGt2 qEx9Y2E/XcaTIqq/5gZOWROPbbZ/s8egNZOBeLYmC+qOJ922W11S107V8IU24T1vbsTMmfGzE35d Wp8POzxVMGjNNeaN1EPkXXDLbDxlFWaMfalKIiPaVi875TlrXdf/XOi3xCYkT7wJdlmww/hkzVfp lRR2oqKic8JrNgWdKsjzd5w770CdWHYX7dCI7Z9R4f+qbK6t5TyRpyjNWJ/sA78wpJEK2ChxsKky tf9o2QsQSK1ZzuaI53hbATTTp+J4LwVO76Gy8NoAIl2ffZv4C5I8CUeoQfog4Qg1SC/kPwEGAAO+ sOGPE+6YAAAAAElFTkSuQmCC --_004_722c8dad4f264f72b686fb1edb238e2aDAGN04AS1E7exg7exghostl_-- From nobody Thu Apr 9 20:10:34 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851881A92EE for ; Thu, 9 Apr 2015 20:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.011 X-Spam-Level: X-Spam-Status: No, score=-107.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSoqijn2dWHA for ; Thu, 9 Apr 2015 20:10:31 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F341A92EC for ; Thu, 9 Apr 2015 20:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1428635431; x=1460171431; h=message-id:in-reply-to:references:date:subject:from:to: cc:reply-to:user-agent:mime-version:content-type: content-transfer-encoding:x-priority:importance; bh=O5iOfo7TEJEA7WoYmjEWVF2fnEKU2+05T74jJGDkitQ=; b=cUQgTclkYixPrwAQ9VuQ0umuC85kZ545PtmSzeIy9EDaymOfxZySr6Nz mRCErtvwAMBsS0aTdaIFTWtyxZHp5oCmxKOc9oUQvkmLUW7FRpboAzFTu d+nfIDbfJtJDkFkICrg5GsZWrypBDcjrlSGzBbaoeOAo60IEC5dMKActY 0=; X-IronPort-AV: E=McAfee;i="5700,7163,7766"; a="204869564" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Apr 2015 20:10:30 -0700 X-IronPort-AV: E=Sophos;i="5.11,554,1422950400"; d="scan'208";a="858556364" Received: from ocean.qualcomm.com ([10.53.76.71]) by Ironmsg04-L.qualcomm.com with ESMTP; 09 Apr 2015 20:10:30 -0700 Received: from 10.64.226.1 (SquirrelMail authenticated user randy) by ocean.qualcomm.com with HTTP; Thu, 9 Apr 2015 20:10:30 -0700 Message-ID: <7b4ef2f2a696c98635e1dad2c4519796.squirrel@ocean.qualcomm.com> In-Reply-To: <722c8dad4f264f72b686fb1edb238e2a@DAGN04A-S1E7.exg7.exghost.local> References: <722c8dad4f264f72b686fb1edb238e2a@DAGN04A-S1E7.exg7.exghost.local> Date: Thu, 9 Apr 2015 20:10:30 -0700 From: "Randall Gellens" To: "Matt Serra" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Thoughts on draft-ietf-ecrit-additional-data v29 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randall Gellens List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 03:10:33 -0000 Hi Matt, Thanks for the review and thoughts. Please see in-line. > It's been a while since I've read the doc front to back and I have a few > observations / questions I'd like to submit to the group. > > 4. Data Provider Information and deriving "intent"/"context": > > - In theory, a given data provider can provide any combination of > the defined structures > > - As I understand, this mechanism will be expanded to carry more > than call-describing information (as is the focus of the current > document). For example, information about the caller (medical info), and > perhaps their emergency contacts. > > - Arguably, the only mechanism provided to distinguish the > "intent" or "context" of the provided data to infer it which blocks > transmitted by the data provider. As some of the blocks will likely be > reused across scenarios (e.g. data provider and comments), some ambiguity > could be introduced. The idea is that the definition of each block includes the type of data and its intended use. Some blocks, especially those describing the data provider, will be added by multiple data providers, but I don't see this as introducing any ambiguity. Furthermore, when a data provider adds a set of blocks, these are linked together by an identifying string. The intent is that each entity processing the call and its data will have a policy as to which blocks it will access. For example, a PSAP may decide to access blocks with the caller's contact information, but choose to not access blocks containing medical data. Blocks not accessed by one entity are still available to other entities. A responder might have a policy to access blocks containing medical data. > - Recipients of this data may want an easier way to audit the > data accompanying a call, so they can filter out the data relevant to the > business function the receiving system performs. I am not sure what you mean by "audit" but there is clearly an intent to enable each entity to decide which blocks it chooses to access. There are important reasons why an entity may choose to not access certain blocks (e.g., medical data). > - Options: > > o Add a field to the Provider-Info block where the Data Provider could > identify the intent of the set of data being passed over This is supposed to be clear from the block definition. > o Extend the valid values in the "TypeOfProvider". I'm open to this, > but it could mean a given provider would appear with different > TypeOfProvider values if they source multiple kinds of data. It is also > possible that this field could become overloaded. This field is an IANA registry and so can be expanded as needed. > o Do nothing. Assume a given data-set will contain a small number of > blocks, and that the blocks are self-describing. The definition of each block should indicate the type of data and the expected use. > - Thoughts? > > > 4.1 Data Provider information. I believe a Data Provider could also > supply this block. I'm not sure what you mean. This block is supposed to be added by each data provider. > There are and will be entities that are neither a > service provider or an access network provider. This may also suggest we > extend the valid values in 4.1.4 This is an IANA registry and so can be expanded as needed. If you feel additional values are needed at the onset, please suggest them and why. From nobody Fri Apr 10 08:45:42 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F6A1A3BA4 for ; Fri, 10 Apr 2015 08:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwKp7-HYX13V for ; Fri, 10 Apr 2015 08:45:39 -0700 (PDT) Received: from server907.appriver.com (server907a.appriver.com [204.232.250.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79671A1BF2 for ; Fri, 10 Apr 2015 08:45:38 -0700 (PDT) X-Note-AR-ScanTimeLocal: 4/10/2015 11:45:35 AM X-Policy: GLOBAL - UNKNOWN X-Policy: GLOBAL - UNKNOWN X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 4/8/2015 10:02:13 PM UTC X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-250/SG:2 4/10/2015 11:45:07 AM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=1 p=-0.981936 Source White X-Signature-Violations: 0-0-0-11394-c X-Note-419: 46.8009 ms. Fail:0 Chk:1321 of 1321 total X-Note: SCH-CT/SI:0-1321/SG:1 4/10/2015 11:45:27 AM X-Note: Spam Tests Failed: X-Country-Path: ->->PRIVATE-> X-Note-Sending-IP: 10.246.0.39 X-Note-Reverse-DNS: X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G254 G255 G256 G257 G261 G262 G376 G393 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [10.246.0.39] (HELO smtp.us.exg7.exghost.com) by server907.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 4346168; Fri, 10 Apr 2015 11:45:35 -0400 Received: from DAGN04A-S1E7.exg7.exghost.local (192.168.244.53) by DAGN04B-S1E7.exg7.exghost.local (192.168.244.51) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 10 Apr 2015 11:45:35 -0400 Received: from DAGN04A-S1E7.exg7.exghost.local ([fe80::d165:924f:d3c0:8385]) by DAGN04A-S1E7.exg7.exghost.local ([fe80::d165:924f:d3c0:8385%22]) with mapi id 15.00.1076.000; Fri, 10 Apr 2015 11:45:35 -0400 From: Matt Serra To: Randall Gellens Thread-Topic: [Ecrit] Thoughts on draft-ietf-ecrit-additional-data v29 Thread-Index: AdBy3SFubx37tzDBRKSbvKpqnIhM9wAgEwQAABFVtpA= Date: Fri, 10 Apr 2015 15:45:35 +0000 Message-ID: <1db2f98f84da463eb2ea7134baedc1fd@DAGN04A-S1E7.exg7.exghost.local> References: <722c8dad4f264f72b686fb1edb238e2a@DAGN04A-S1E7.exg7.exghost.local> <7b4ef2f2a696c98635e1dad2c4519796.squirrel@ocean.qualcomm.com> In-Reply-To: <7b4ef2f2a696c98635e1dad2c4519796.squirrel@ocean.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.244.1] x-exclaimer-md-config: 952e3d35-ca29-4b9e-94e1-a56fe70f6560 x-rerouted-by-exchange: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Thoughts on draft-ietf-ecrit-additional-data v29 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 15:45:41 -0000 Randy - I think that makes sense. =20 The only other question I have is related to what happens when a single dat= a provider provides multiple forms of data? For example, providing Service= Information and associated Comment, as well as a TBD "caller" and/or "loca= tion" block that are also accompanied by other general-purpose blocks, such= as Comments or Emergency Contacts? Would there be a way to distinguish which "reusable" block goes with a part= icular form of data provided by the same Data Provider? The only way I see this working with the current layout, would be for the D= ataProvider to provide multiple separate sets of blocks, grouped by the for= m of data being described (call, caller or location), where each of these g= roups have a nearly identical Data Provider block, varying only by a unique= DataProviderReference which would be used by the receiving system to colla= te the blocks properly. I hope I'm being clear - - I could sketch something up if not. And yes, by "audit" I was referring to a process where the system consuming= the data inspects the various blocks for the purpose of deciding what, if = anything, to do with each set of data based on the rules built into the dat= a-consuming system. Thanks, Matt. -----Original Message----- From: Randall Gellens [mailto:rg+ietf@qualcomm.com]=20 Sent: Thursday, April 9, 2015 11:11 PM To: Matt Serra Cc: ecrit@ietf.org Subject: Re: [Ecrit] Thoughts on draft-ietf-ecrit-additional-data v29 Hi Matt, Thanks for the review and thoughts. Please see in-line. > It's been a while since I've read the doc front to back and I have a=20 > few observations / questions I'd like to submit to the group. > > 4. Data Provider Information and deriving "intent"/"context": > > - In theory, a given data provider can provide any combination o= f > the defined structures > > - As I understand, this mechanism will be expanded to carry more > than call-describing information (as is the focus of the current=20 > document). For example, information about the caller (medical info),=20 > and perhaps their emergency contacts. > > - Arguably, the only mechanism provided to distinguish the > "intent" or "context" of the provided data to infer it which blocks=20 > transmitted by the data provider. As some of the blocks will likely=20 > be reused across scenarios (e.g. data provider and comments), some=20 > ambiguity could be introduced. The idea is that the definition of each block includes the type of data and= its intended use. Some blocks, especially those describing the data provi= der, will be added by multiple data providers, but I don't see this as intr= oducing any ambiguity. Furthermore, when a data provider adds a set of blo= cks, these are linked together by an identifying string. The intent is that each entity processing the call and its data will have a= policy as to which blocks it will access. For example, a PSAP may decide = to access blocks with the caller's contact information, but choose to not a= ccess blocks containing medical data. Blocks not accessed by one entity ar= e still available to other entities. A responder might have a policy to ac= cess blocks containing medical data. > - Recipients of this data may want an easier way to audit the > data accompanying a call, so they can filter out the data relevant to=20 > the business function the receiving system performs. I am not sure what you mean by "audit" but there is clearly an intent to en= able each entity to decide which blocks it chooses to access. There are im= portant reasons why an entity may choose to not access certain blocks (e.g.= , medical data). > - Options: > > o Add a field to the Provider-Info block where the Data Provider could > identify the intent of the set of data being passed over This is supposed to be clear from the block definition. > o Extend the valid values in the "TypeOfProvider". I'm open to this, > but it could mean a given provider would appear with different=20 > TypeOfProvider values if they source multiple kinds of data. It is=20 > also possible that this field could become overloaded. This field is an IANA registry and so can be expanded as needed. > o Do nothing. Assume a given data-set will contain a small number of > blocks, and that the blocks are self-describing. The definition of each block should indicate the type of data and the expec= ted use. > - Thoughts? > > > 4.1 Data Provider information. I believe a Data Provider could also=20 > supply this block. I'm not sure what you mean. This block is supposed to be added by each dat= a provider. > There are and will be entities that are neither a service provider or=20 > an access network provider. This may also suggest we extend the valid=20 > values in 4.1.4 This is an IANA registry and so can be expanded as needed. If you feel add= itional values are needed at the onset, please suggest them and why. From nobody Sat Apr 11 18:40:22 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541BB1A910A for ; Sat, 11 Apr 2015 18:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.311 X-Spam-Level: X-Spam-Status: No, score=-104.311 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ic9Q3eCS8HFa for ; Sat, 11 Apr 2015 18:40:19 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA071A9109 for ; Sat, 11 Apr 2015 18:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1428802819; x=1460338819; h=message-id:in-reply-to:references:date:subject:from:to: cc:reply-to:user-agent:mime-version:content-type: content-transfer-encoding:x-priority:importance; bh=ZLRk0dpdilYpEWfSTrgNFtUR4xwNx3jN/GFsB2R+Qyo=; b=CNR+zvpu2r6qksUKIFrsSsnMYrcaMi92jWjFQzYpKzP2Kh+ARd+tP5LE vTHXUkJ0wee9snYZTkx2Jy8hGIL6XMPvh6wPF1GibggfzVuo5MvqRCqEc oyxGwA0RTQYAEbRGerNTMvNFhXY/33S1H+NWRWHbi5C13+mO6xHDeeGSc k=; X-IronPort-AV: E=McAfee;i="5700,7163,7768"; a="112881926" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2015 18:40:18 -0700 X-IronPort-AV: E=Sophos;i="5.11,563,1422950400"; d="scan'208";a="885018357" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2015 18:40:18 -0700 Received: from Ironmsg04-L.qualcomm.com (ironmsg04-L.qualcomm.com [172.30.48.19]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t3C1eGZY032062; Sat, 11 Apr 2015 18:40:18 -0700 X-IronPort-AV: E=Sophos;i="5.11,563,1422950400"; d="scan'208";a="859914964" Received: from ocean.qualcomm.com ([10.53.76.71]) by Ironmsg04-L.qualcomm.com with ESMTP; 11 Apr 2015 18:40:11 -0700 Received: from 10.64.195.56 (SquirrelMail authenticated user randy) by ocean.qualcomm.com with HTTP; Sat, 11 Apr 2015 18:40:12 -0700 Message-ID: <9bc31609f81c6bff44174903891443a6.squirrel@ocean.qualcomm.com> In-Reply-To: <1db2f98f84da463eb2ea7134baedc1fd@DAGN04A-S1E7.exg7.exghost.local> References: <722c8dad4f264f72b686fb1edb238e2a@DAGN04A-S1E7.exg7.exghost.local> <7b4ef2f2a696c98635e1dad2c4519796.squirrel@ocean.qualcomm.com> <1db2f98f84da463eb2ea7134baedc1fd@DAGN04A-S1E7.exg7.exghost.local> Date: Sat, 11 Apr 2015 18:40:12 -0700 From: "Randall Gellens" To: "Matt Serra" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Randall Gellens , "ecrit@ietf.org" Subject: Re: [Ecrit] Thoughts on draft-ietf-ecrit-additional-data v29 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randall Gellens List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 01:40:21 -0000 Hi Matt, > The only other question I have is related to what happens when a single > data provider provides multiple forms of data? For example, providing > Service Information and associated Comment, as well as a TBD "caller" > and/or "location" block that are also accompanied by other general-purpose > blocks, such as Comments or Emergency Contacts? > > Would there be a way to distinguish which "reusable" block goes with a > particular form of data provided by the same Data Provider? > > The only way I see this working with the current layout, would be for the > DataProvider to provide multiple separate sets of blocks, grouped by the > form of data being described (call, caller or location), where each of > these groups have a nearly identical Data Provider block, varying only by > a unique DataProviderReference which would be used by the receiving system > to collate the blocks properly. I'm not sure why the service provider would need to include separate Data Provider blocks. What would be the problem with a service provider including as many blocks as it can? E.g., provider info, service info, device info, future location info, future caller info, etc. If there was a need for a single service provider to include multiple blocks of the same type (duplicates if you will), hypothetically, maybe a call transited a service provider multiple times, then yes, each set of blocks would have a unique DataProviderReference. There is text in the draft saying so. But I'm not sure how realistic this scenario is. > And yes, by "audit" I was referring to a process where the system > consuming the data inspects the various blocks for the purpose of deciding > what, if anything, to do with each set of data based on the rules built > into the data-consuming system. To be very clear, the system would inspect the block metadata (i.e., the block type) to decide if it wants to access the block data. This allows a system to avoid ever accessing data it wants to avoid (such as medical data). Having the block metadata in the header makes this easier. From nobody Mon Apr 13 00:47:24 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF141A6FFB for ; Mon, 13 Apr 2015 00:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.011 X-Spam-Level: X-Spam-Status: No, score=-107.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww219fPo5315 for ; Mon, 13 Apr 2015 00:47:12 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2191A1EED for ; Mon, 13 Apr 2015 00:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1428911232; x=1460447232; h=message-id:date:subject:from:to:cc:reply-to:user-agent: mime-version:content-type:content-transfer-encoding: x-priority:importance; bh=dZlHdCWMLl0S2JI/p01EepbumOTmBuR+dTJ8Ee7gZXI=; b=pNBtb9noBSS+wOKsB49b83oi/YnD3mU6NnSpuEqsYwH3voqEvgOlnKvU TU/6xylKcHBwnuYUekPKpUwEXOqWPklGh0BPGlrzFhYRmhghMogZwrXXv QSZ35IBypL+akN+xUL6Gpr0vBQ8NPO2rwDcI+STXgAhjiMmJpbhA4sRqP 0=; X-IronPort-AV: E=McAfee;i="5700,7163,7769"; a="205247016" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2015 00:47:12 -0700 X-IronPort-AV: E=Sophos;i="5.11,568,1422950400"; d="scan'208";a="885735884" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2015 00:47:12 -0700 Received: from ironmsg02-L.qualcomm.com (ironmsg02-L.qualcomm.com [172.30.48.16]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t3D7lBT3007434; Mon, 13 Apr 2015 00:47:11 -0700 X-IronPort-AV: E=Sophos;i="5.11,568,1422950400"; d="scan'208";a="440103032" Received: from ocean.qualcomm.com ([10.53.76.71]) by ironmsg02-L.qualcomm.com with ESMTP; 13 Apr 2015 00:47:11 -0700 Received: from 10.64.195.186 (SquirrelMail authenticated user randy) by ocean.qualcomm.com with HTTP; Mon, 13 Apr 2015 00:47:11 -0700 Message-ID: <385fee84e7fc4876db03e86bf9b641f8.squirrel@ocean.qualcomm.com> Date: Mon, 13 Apr 2015 00:47:11 -0700 From: "Randall Gellens" To: marc.linsner@cisco.com, rmarshall@telecomsys.com User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: Randall Gellens , ecrit@ietf.org Subject: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randall Gellens List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 07:47:15 -0000 Hi Marc, Roger, and ECRITers, During the discussion in Dallas, it was suggested that the group send a liaison to 3GPP regarding the eCall draft, and I agreed to draft it. Here is a link to the draft in PDF format: https://www.dropbox.com/s/u33z1avtlpnclko/Liaison%20Statement%20from%20IETF%20ECRIT%20WG%20to%203GPP.pdf?dl=0 From nobody Mon Apr 13 14:31:03 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F7B1A8848 for ; Mon, 13 Apr 2015 14:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1CW4Wmw31qe for ; Mon, 13 Apr 2015 14:31:00 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2C51A883F for ; Mon, 13 Apr 2015 14:30:59 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-7d-552c3591d6d8 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 10.93.28347.1953C255; Mon, 13 Apr 2015 23:30:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Mon, 13 Apr 2015 23:30:56 +0200 From: Christer Holmberg To: Randall Gellens , "marc.linsner@cisco.com" , "rmarshall@telecomsys.com" Thread-Topic: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP Thread-Index: AQHQdb4Ww3YNXd2TrUuIpOZCQWUwaJ1LdsQb Date: Mon, 13 Apr 2015 21:30:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7978B1@ESESSMB209.ericsson.se> References: <385fee84e7fc4876db03e86bf9b641f8.squirrel@ocean.qualcomm.com> In-Reply-To: <385fee84e7fc4876db03e86bf9b641f8.squirrel@ocean.qualcomm.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D7978B1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RneiqU6oQc9DNYvGRU9ZLTac+sZi 8eVwB6vF4atLmRxYPKb83sjqsWTJTyaPTR+6WT02bD3FHMASxWWTkpqTWZZapG+XwJUx5dAh 9oKlihVrv2o3MN6R7WLk5JAQMJF4dW0fO4QtJnHh3nq2LkYuDiGBo4wSh+Z9hHKWMEqsbzkB VMXBwSZgIdH9TxskLiIwg1Hi/Z3DLCDdzAKqEucaH4PZwgKOEp+uH2cGqRcRcJI4f10aJCwi YCRxcNFDsBIWoPIpDRfYQGxeAV+JH9/bmUFsIQEviRO3zoIdxCngLdEzbwFYDSPQcd9PrWGC WCUu0fRlJSvE0QISS/acZ4awRSVePv7HClGTL7H6wD9GiPmCEidnPmGZwCgyC0n7LCRls5CU QcQNJL68vw1la0ssW/iaGcLWl+h+f5oJWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJN jMDoO7jlt8EOxpfPHQ8xCnAwKvHwPnilFSrEmlhWXJl7iFGag0VJnNfO+FCIkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBkZPvZl2Er03Gzbc7Vt/60OSx3f3KjaWvQEXnkYplch5slesa9si NL/dzt77W5CacpAih+fSK5Fs596cPhkV8VN79aMivWcLnU0nv3IQ+TTtm2EGi7yQ1a7bi2zW Sx24/VTL5OLGD9tc9n/KdfGrSAzYd/ZE3UFeXhEu34/MX3xbo5eaT97wYqESS3FGoqEWc1Fx IgBAvBg1nwIAAA== Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 21:31:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D7978B1ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, This week there are a number of 3gpp meetings ongoing, so please give some = time for people to read and comment. Thanks! Regards, Christer Sent from my Windows Phone ________________________________ From: Randall Gellens Sent: =FD13/=FD04/=FD2015 10:47 To: marc.linsner@cisco.com; rmarshall@teleco= msys.com Cc: Randall Gellens; ecrit@ietf.org Subject: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP Hi Marc, Roger, and ECRITers, During the discussion in Dallas, it was suggested that the group send a liaison to 3GPP regarding the eCall draft, and I agreed to draft it. Here is a link to the draft in PDF format: https://www.dropbox.com/s/u33z1avtlpnclko/Liaison%20Statement%20from%20IETF= %20ECRIT%20WG%20to%203GPP.pdf?dl=3D0 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_7594FB04B1934943A5C02806D1A2204B1D7978B1ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

This week there are a number of 3gpp meetings ongoing, so please give some = time for people to read and comment.

Thanks!

Regards,

Christer

Sent from my Windows Phone
From: Randall Gellens
Sent: =FD13= /=FD04/=FD2015 10:47
To: marc.linsner@cisco.com; rmarshall@telecomsys.com
Cc: Randall Gellens; ecrit@ietf.org
Subject: [Ecri= t] Liaison Statement from IETF ECRIT WG to 3GPP

Hi Marc, Roger, and ECRITers,

During the discussion in Dallas, it was suggested that the group send a
liaison to 3GPP regarding the eCall draft, and I agreed to draft it.  = Here
is a link to the draft in PDF format:
https://www.dropbox.com/s/= u33z1avtlpnclko/Liaison%20Statement%20from%20IETF%20ECRIT%20WG%20to%203GPP.= pdf?dl=3D0

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.or= g/mailman/listinfo/ecrit
 --_000_7594FB04B1934943A5C02806D1A2204B1D7978B1ESESSMB209erics_-- From nobody Wed Apr 29 05:24:11 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8311B2C59 for ; Wed, 29 Apr 2015 05:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdSvroRKJyzt for ; Wed, 29 Apr 2015 05:24:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F791A8A54 for ; Wed, 29 Apr 2015 05:24:08 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-d1-5540cd66d49e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 92.49.04401.66DC0455; Wed, 29 Apr 2015 14:24:06 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.223]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0210.002; Wed, 29 Apr 2015 14:24:05 +0200 From: Ivo Sedlacek To: Randall Gellens , "marc.linsner@cisco.com" , "rmarshall@telecomsys.com" Thread-Topic: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP Thread-Index: AQHQdb4WqOtDnMuFHUCi7aoEoh4lF51kArVA Date: Wed, 29 Apr 2015 12:24:05 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101128891C0@ESESSMB301.ericsson.se> References: <385fee84e7fc4876db03e86bf9b641f8.squirrel@ocean.qualcomm.com> In-Reply-To: <385fee84e7fc4876db03e86bf9b641f8.squirrel@ocean.qualcomm.com> Accept-Language: en-US, cs-CZ 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+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3RjftrEOowYE2OYvGRU9ZLTac+sZi 8eVwB6vF4atLmRxYPKb83sjqsWTJTyaPTR+6WT02bD3FHMASxWWTkpqTWZZapG+XwJXR/XQS S8F/9opTJ/6wNjDeZeti5OSQEDCRWDz7KZQtJnHh3nogm4tDSOAoo8TLP7dZQBJCAksYJbqu mYLYbAJ6EhO3HGEFKRIRmMEo8f7OYbAiZgFViXONj8FsYQFHiU/XjzN3MXIAFTlJnL8uDRIW ETCSaOndBLaMBah84eefTCA2r4CvxPvNd1ghdnlJnLh1lh3E5hTwluiZtwCsnlFAVuLqn15G iFXiEreezGeCOFpAYsme88wQtqjEy8f/WEHWSggoSizvl4Mo15FYsPsTG4StLbFs4WtmiLWC EidnPmGZwCg2C8nUWUhaZiFpmYWkZQEjyypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwCg7 uOW36g7Gy28cDzEKcDAq8fAqWDuECrEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qB0Um5dtLi9dd+nT5meFtlgsrLgJkbm5yYnrLvV/oq3KTKs6bjjouQoYjo vi/vbLvkuXxrj304mmIyj7MioPG26Dtj+SS5TnM5rR89U5tdf7Ha/+SauTvz1aJvTjrGz/jn 6170/SLwsMjs1v1zcvX3FAJ2zUryzT7jvSL2l9aRC84rQlTXtz88osRSnJFoqMVcVJwIAPOT VUmTAgAA Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 12:24:10 -0000 Hello, has the LS been already sent? Or, can it still be commented and changed? Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: 13. dubna 2015 9:47 To: marc.linsner@cisco.com; rmarshall@telecomsys.com Cc: Randall Gellens; ecrit@ietf.org Subject: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP Hi Marc, Roger, and ECRITers, During the discussion in Dallas, it was suggested that the group send a lia= ison to 3GPP regarding the eCall draft, and I agreed to draft it. Here is = a link to the draft in PDF format: https://www.dropbox.com/s/u33z1avtlpnclko/Liaison%20Statement%20from%20IETF= %20ECRIT%20WG%20to%203GPP.pdf?dl=3D0 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Apr 29 10:23:53 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325991ACD78 for ; Wed, 29 Apr 2015 10:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrSPDlj-eUtr for ; Wed, 29 Apr 2015 10:23:48 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA1B1ACD7F for ; Wed, 29 Apr 2015 10:23:48 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id t3THNecg012471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Apr 2015 10:23:40 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.28]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0195.001; Wed, 29 Apr 2015 10:23:40 -0700 From: Roger Marshall To: Ivo Sedlacek , Randall Gellens , "marc.linsner@cisco.com" Thread-Topic: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP Thread-Index: AQHQdb4QvfNNkUoLJUSWPwVJUcPl9Z1keKCA///d7fA= Date: Wed, 29 Apr 2015 17:23:38 +0000 Message-ID: References: <385fee84e7fc4876db03e86bf9b641f8.squirrel@ocean.qualcomm.com> <39B5E4D390E9BD4890E2B31079006101128891C0@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101128891C0@ESESSMB301.ericsson.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 17:23:50 -0000 The liaison has not been sent, but is planned to be sent before tomorrow, u= nless there are changes. -roger. -----Original Message----- From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]=20 Sent: Wednesday, April 29, 2015 5:24 AM To: Randall Gellens; marc.linsner@cisco.com; Roger Marshall Cc: ecrit@ietf.org Subject: RE: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP Hello, has the LS been already sent? Or, can it still be commented and changed? Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens Sent: 13. dubna 2015 9:47 To: marc.linsner@cisco.com; rmarshall@telecomsys.com Cc: Randall Gellens; ecrit@ietf.org Subject: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP Hi Marc, Roger, and ECRITers, During the discussion in Dallas, it was suggested that the group send a lia= ison to 3GPP regarding the eCall draft, and I agreed to draft it. Here is = a link to the draft in PDF format: https://www.dropbox.com/s/u33z1avtlpnclko/Liaison%20Statement%20from%20IETF= %20ECRIT%20WG%20to%203GPP.pdf?dl=3D0 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From nobody Wed Apr 29 19:44:55 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2D41A90B9 for ; Wed, 29 Apr 2015 19:44:54 -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: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vynC-o84WTzI for ; Wed, 29 Apr 2015 19:44:52 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEEEF1A1A9F for ; Wed, 29 Apr 2015 19:44:51 -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=1430361892; x=1461897892; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=qiHKA5A05WM5Sb73qG/EL4jSube4mmG9Jg31MY21mBA=; b=iT6FO15GpHutgGhG8fRSPEx32xqSfNK+TWSCHBULjRitYs3Kxlmv0sbg mFaMaOtUbhH5AkIpwhmgE4U6D/Ta5pMenmJGrWU8jE1pJHq3nqm2MO0Tw NH7DGvXrNy9RIE4hJSd9FHMOVJNcLGy5d6UWgqhy4JVgrdJjfUmWNKEw+ 0=; X-IronPort-AV: E=McAfee;i="5700,7163,7786"; a="115919667" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2015 19:44:52 -0700 X-IronPort-AV: E=Sophos;i="5.11,674,1422950400"; d="scan'208";a="906291908" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2015 19:44:50 -0700 Received: from Ironmsg04-R.qualcomm.com (ironmsg04-R.qualcomm.com [172.30.46.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t3U2ioAu012196; Wed, 29 Apr 2015 19:44:50 -0700 X-IronPort-AV: E=Sophos;i="5.11,674,1422950400"; d="scan'208";a="959951647" X-ojodefuego: yes Received: from unknown (HELO [192.168.29.31]) ([10.64.209.207]) by Ironmsg04-R.qualcomm.com with ESMTP; 29 Apr 2015 19:44:49 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <385fee84e7fc4876db03e86bf9b641f8.squirrel@ocean.qualcomm.com> <39B5E4D390E9BD4890E2B31079006101128891C0@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Wed, 29 Apr 2015 19:44:47 -0700 To: Roger Marshall , Ivo Sedlacek , "marc.linsner@cisco.com" 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 X-Random-Sig-Tag: 1.0b28 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 02:44:54 -0000 I believe the liaison is ready to go. There have not been any changes suggested, nor any comments sent suggesting a need for changes. At 5:23 PM +0000 4/29/15, Roger Marshall wrote: > The liaison has not been sent, but is planned to be sent before > tomorrow, unless there are changes. > > -roger. > > -----Original Message----- > From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > Sent: Wednesday, April 29, 2015 5:24 AM > To: Randall Gellens; marc.linsner@cisco.com; Roger Marshall > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP > > Hello, > > has the LS been already sent? Or, can it still be commented and changed? > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email > on the basis of the terms set out at > www.ericsson.com/email_disclaimer > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Randall Gellens > Sent: 13. dubna 2015 9:47 > To: marc.linsner@cisco.com; rmarshall@telecomsys.com > Cc: Randall Gellens; ecrit@ietf.org > Subject: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP > > Hi Marc, Roger, and ECRITers, > > During the discussion in Dallas, it was suggested that the group > send a liaison to 3GPP regarding the eCall draft, and I agreed to > draft it. Here is a link to the draft in PDF format: > > https://www.dropbox.com/s/u33z1avtlpnclko/Liaison%20Statement%20from%20IETF%20ECRIT%20WG%20to%203GPP.pdf?dl=0 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > 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: --------------- If you attack stupidity you attack an entrenched interest with friends in government and every walk of public life, and you will make small progress against it. --Samuel Marchbanks From nobody Thu Apr 30 01:05:23 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0A31ACEEE for ; Thu, 30 Apr 2015 01:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGiTyHiykIhK for ; Thu, 30 Apr 2015 01:05:11 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF981ACEE8 for ; Thu, 30 Apr 2015 01:05:02 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-fb-5541e22b2c2b Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BD.59.04401.B22E1455; Thu, 30 Apr 2015 10:05:00 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.223]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Thu, 30 Apr 2015 10:04:59 +0200 From: Ivo Sedlacek To: Roger Marshall , Randall Gellens , "marc.linsner@cisco.com" Thread-Topic: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP Thread-Index: AQHQdb4QvfNNkUoLJUSWPwVJUcPl9Z1keKCA///d7fCAAOAA0A== Date: Thu, 30 Apr 2015 08:04:57 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112889CB0@ESESSMB301.ericsson.se> References: <385fee84e7fc4876db03e86bf9b641f8.squirrel@ocean.qualcomm.com> <39B5E4D390E9BD4890E2B31079006101128891C0@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ 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_39B5E4D390E9BD4890E2B3107900610112889CB0ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM+Jvja7OI8dQg83/uS0aFz1ltdhw6huL xZfDHawWh68uZXJg8ZjyeyOrx5IlP5k8Nn3oZvXYsPUUcwBLFJdNSmpOZllqkb5dAlfGq4tX WAtm6lT8X7KTsYHxt2oXIweHhICJxMFrnl2MnECmmMSFe+vZuhi5OIQEjjJKnJq+iBEkISSw hFHi18coEJtNQE9i4pYjrCBFIgJdjBJn7sxiB0kwC6hKnGt8zAJiCws4Sny6fpwZZIGIgJPE +evSIGEQs2XlLlYQmwWofNnXg0wgJbwCvhLvtvJD7L3JKPFgw0lmkBpOgUCJPTsnM4HYjAKy Elf/9DJCrBKXuPVkPhPE0QISS/acZ4awRSVePv7HCvGXksS0rWkQ5fkSzR/vga3lFRCUODnz CcsERtFZSCbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UoWpxanJSbbmSs l1qUmVxcnJ+nl5dasokRGJMHt/xW3cF4+Y3jIUYBDkYlHt4FPY6hQqyJZcWVuYcYpTlYlMR5 7YwPhQgJpCeWpGanphakFsUXleakFh9iZOLglGpgNDer3Cv6KfuRgmNeQYvu+Wzuel3xdbq7 e0K+aha8crg4v8JS8NT7KXf8I5+z2TX2fJOc+dDEwd7jTdprKZOTh0KLbjDnrxBz2LJmhoGU i+IEN5UQ7/i1ATMUFQ9v0fJ2/TH94uu4SSyBnUyz8/Z9MK3ZXvZIPEDhwMWCvyt/bdj+5rgh u/YbJZbijERDLeai4kQAmVzcC6oCAAA= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 08:05:21 -0000 --_000_39B5E4D390E9BD4890E2B3107900610112889CB0ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, the following sentence of the LS is misleading. IETF ECRIT intends the eventual RFC to define the necessary= SIP protocol convensions and mechanisms that will be needed to support any= end-to-end solution (e.g. such as a solution defined later by 3GPP) in which bo= th ends (IVS adn PSAP) are IP capable or in which one end is IP capable wit= h interworking being used. RFC will specify solely SIP based eCall between two SIP UAs. RFC will not specify interworking of the SIP based eCall to the existing ci= rcuit switched based eCall. Thus, I propose to modify the statement as follows: IETF ECRIT intends the eventual RFC to define the necessary= SIP protocol convensions and mechanisms that will be needed to support any= solution (e.g. such as a solution defined later by 3GPP) in which bo= th ends are IP and SIP capable. Other than the above, I think the LS tooks OK. Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B3107900610112889CB0ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

the following sentence of the LS is misleading.

 

       &nbs= p;        IETF ECRIT intends the eventua= l RFC to define the necessary SIP protocol convensions and mechanisms that = will be needed to support any end-to-end solution

       &nbs= p;        (e.g. such as a solution = defined later by 3GPP) in which both ends (IVS adn PSAP) are IP capable or = in which one end is IP capable with interworking being used.=

 

RFC will specify solely SIP based eCall between t= wo SIP UAs.

RFC will not specify interworking of the SIP base= d eCall to the existing circuit switched based eCall.

 

Thus, I propose to modify the statement as follow= s:

 

       &nbs= p;        IETF ECRIT intends the eventua= l RFC to define the necessary SIP protocol convensions and mechanisms that = will be needed to support any solution

       &nbs= p;        (e.g. such as a solution = defined later by 3GPP) in which both ends are IP and SIP capable.

 

Other than the above, I think the LS tooks OK.

 

Kind regards

 

Ivo Sedlacek

 

--_000_39B5E4D390E9BD4890E2B3107900610112889CB0ESESSMB301erics_-- From nobody Thu Apr 30 15:56:42 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E5F1AD0C4 for ; Thu, 30 Apr 2015 15:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLtULZuRoBb1 for ; Thu, 30 Apr 2015 15:56:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518451A882A for ; Thu, 30 Apr 2015 15:56:38 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 46F2A20C5B for ; Thu, 30 Apr 2015 18:56:36 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 30 Apr 2015 18:56:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=icH WwB7MbxxMlCtSpkW7WM/GEeU=; b=Xn9+Xg75RYjBu4jSXyDQM1oH021V0EbBnmF lx1kCwDEaP1EevzsLAUFnY7Lx2qstS/K/GF3zrE7dMX+bNr7hKxhDvIrkNbZUmhn dt2vDbDMau8yn7RO9PEZ+9vu433slTaxQa0TgniyBE5npSjtnjLB+GwgN9P+ZWTO d5BQsg0E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=icHWwB7MbxxMlCtSpkW7WM/GEeU=; b=uHv+L E8Ni2WH1/wnAY8KELQs86ZyZhTxDhYi7R7r9C15ZM49SVFJPXsNJfqnRHdELALQ0 vbK2BqTjdwT9CC+yl7aPRbKVScGiz3YArDjLIIaoZSBVlmRj1YP8BaXyK3uPhoYu 4AuRtKkMIzSA78KB57Ppqu6qni7w4t4uAqI6Aw= X-Sasl-enc: F0QsrT6cYuV8GQdiQXbKfDxqGg++Sb/+JXplNL5TTenf 1430434596 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.183]) by mail.messagingengine.com (Postfix) with ESMTPA id 5B509C00013 for ; Thu, 30 Apr 2015 18:56:36 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> Date: Thu, 30 Apr 2015 15:56:44 -0700 To: ecrit@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 22:56:41 -0000 I have reviewed draft-ietf-ecrit-additional-data-29 in preparation for = IETF last call. There are a number of issues that need to be resolved = before the IETF LC can be issued, which I=92ve included below as = substantive comments and questions. There is a list of nits at the end = that also need to be fixed. Substantive comments and questions: General: I've asked the shepherd to validate all of the XML in the document and = am waiting to hear back on that. Section 1: I would suggest adding this text from Section 9 or something like it at = the end of the introduction: "Much of the information supplied by service providers and devices is private and confidential; service providers and devices generally go to lengths to protect this information; disclosing it in the context of an emergency call is a trade-off to protect the greater interest of the customer in an emergency." Section 4.1: I am a little confused about how this section applies when the data is = being provided by the device. First, this text seems to consider the = device to be a "service provider": "This block is intended to be supplied 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 supplied by every service provider in the call path, and by the access network provider. Devices MAY use this block to provide identifying information." I think this would be clearer if the first sentence said "any service = provider in the path of the call, the access network provider, or the = device."=20 Then later in the section Data Provider ID, Data Provider ID Series, and = Type of Data Provider are defined. None of these seem to apply when the = data is provided by the device, and yet they are all listed as required. = What are these elements supposed to contain when the data is provided by = the device? I see in the example in Section 6 that only Type of Data = Provider is included, and is listed as =93Other,=94 which seems less = specific than it ideally could be. Section 4.1.2: Is there an EENA equivalent of the NENA company ID? If so, it should be = mentioned here.=20 Is it the case that where a jurisdiction-specific ID exists, it is = preferred over an FQDN? If so, that should be stated explicitly. Section 4.1.5: "If the call is from a device, this SHOULD be the contact information of the owner of the device." What are the exception cases for this SHOULD? What should this element = be if it is not the owner's contact info? Section 4.1.6: By saying the other language tags are independent of this language = element, does that mean they should be ignored? If so, that should be = stated explicitly. Section 4.1.9: "This element is required if the Data Provider type is set to "Subcontractor"." Subcontractor is not listed as a data provider type in section 4.1.4, so = this doesn't quite make sense. Section 4.2.1: Shouldn't "use" be listed as conditional? Section 4.2.3: s/MUST NOT/ought not to/ Section 4.3.4: I'm curious about the kinds of "investigations" that PSAPs do and how = they have used unique device IDs in those investigations -- could you = explain? At first blush this seems to require over-sharing of sensitive = data. Section 4.4.1: Are there any jurisdiction-specific rules you can point to that would = indicate that having a single boolean "privacy" value will actually be = interpretable and of use by any PSAP? I find it a little hard to believe = that PSAPs will know what actions this value is supposed to apply to = (e.g., display, logging, display and logging, etc.) and what data fields = it is supposed to apply to. Without further definition (or some = compelling evidence that PSAPs in at least some places have = well-specified rules for what to do when they receive this value), this = indicator seems pretty hand-wavy. Section 4.4.2: Are there any xCard fields you would recommend not sending for lack of = relevance (e.g., anniversary)? Depending on what the answer is to my question in 4.1.6 about = interaction between Data Provider Language(s) and language tags, there = might need to be text in this section as well about expected behavior = when both are present and when the data provider is the device. Section 5.1: The last paragraph here makes it sound as though additional data is = required to be sent on every emergency call (i.e., every call with an = emergency service URN in the route header). Is that the intention? If = so, that needs to be made more clear and should be explained earlier in = the document, preferably in the introduction. If not, the normative = language in the last paragraph here needs to be fixed. Section 6: The owner/subscriber of this laptop is Hannes Tschofenig. His contact = tel URI is in North America but his work and home are in Finland. He is = using a VoIP provider that provides its NENA ProviderID, which I assume = indicates that the service is being provided in North America? The VoIP = provider contact person is located in the UK, however. And then when the = access network provides the location, it is in Australia. The last bit just seems wrong to me, for a plausible emergency call. The = other bits seem to amount to a possible (but not likely?) example = scenario but the details require more narrative explanation in the text. = Alternatively, a simpler or more plausible example might help readers = out more. Section 8: "Mechanisms that protect against eavesdropping (such as Transport Layer Security (TLS)) SHOULD be preferentially used whenever feasible." This needs a sentence about the existing deployed base of clear text SIP = to explain why this requirement is not a MUST.=20 s/HTTPS is specified/HTTPS is REQUIRED/ "Data provided by devices by reference have similar credential validation issues as for service providers, and the solutions are the same." Maybe the solutions are the same, but aren't the challenges of doing = this for every device much more significant? That seems worth mention. s/Service providers SHOULD choose the latter/Service providers ought to = choose the latter/ (otherwise this reads like a normative requirement on IMS functionality) Section 10.1.1: "Private entities issuing and using internally-generated IDs are encouraged to register and use a unique identifier." What is meant by "use a unique identifier"? Section 10.1.8: It might be useful to give the experts some additional criteria around = weighing privacy vs. utility trade-offs. E.g., if someone wants to = register the biometric fingerprint used to authenticate a device as a = device ID and few or no PSAPs can actually make use of it, that may = argue against registering it. Section 12.2: I think RFC 3966 should be a normative reference. Nits: General: Why are some of the registry tables in the main sections of the document = and others are in the IANA Considerations section? Seems like they = should all be one or the other. Section 2: Citations for vCard and xCard should be added to the last paragraph. Section 4.1.7: This sentence seems redundant: "For encoding of the xCard this specification uses the XML-based encoding specified in [RFC6351], referred to in this document as "xCard"." =20 Section 4.2.1: s/therefore this is/this is/ s/Figure 22/Section 10.1.2/ Section 4.2.2: s/Figure 3/Section 10.1.3/ Section 4.2.3: s/Figure 23/Section 10.1.4/ Section 4.3.6: A reference to the IEEE 1512 spec should be included. Section 4.3.7: s/which allow/that allow/ "Some standards being developed by other organizations" -- would be good = to provide citations. Section 4.4.2: Given that 4.4 says the location provided here is the contact address = and not necessarily the location of the caller, it seems like this = section needs to explain a little more why a call taker would use the = location provided here. Section 5.1: OLD A Call-info header with a purpose value starting with 'EmergencyCallData' MUST only be sent on an emergency call NEW A Call-info header with a purpose value starting with 'EmergencyCallData' MUST NOT be sent unless the call is an emergency = call =20 Section 9: s/The functionality defined in this document, however/The functionality = defined in this document/ Section 10.1.2: s/A s[RFC4119]hort/A short/ Section 10.1.5: Seems like this section and Figure 1 should both use "Token" rather than = "Tokenproviderid."=