From nobody Fri May 1 04:45:33 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 630AB1AD0CE for ; Fri, 1 May 2015 04:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 OSWzo9n5n2Vc for ; Fri, 1 May 2015 04:45:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54B11AD0CD for ; Fri, 1 May 2015 04:45:28 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 87894504C1FC3; Fri, 1 May 2015 11:45:22 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t41BjOSa030183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 May 2015 13:45:24 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 1 May 2015 13:45:24 +0200 From: "DRAGE, Keith (Keith)" To: Alissa Cooper , "ecrit@ietf.org" Thread-Topic: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29 Thread-Index: AQHQg5jxNuQ6KAjCPka9n+5YkmHU7Z1m9Ocw Date: Fri, 1 May 2015 11:45:24 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B6970D7F0@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> In-Reply-To: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [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: Fri, 01 May 2015 11:45:32 -0000 This part of Alissa's review caught my eye because I think the original int= ent is wrong, and therefore so is the rewrite: > Section 5.1: > OLD > A Call-info header with a purpose value starting with > 'EmergencyCallData' MUST only be sent on an emergency call=20 > NEW A Call-info header with a purpose value starting with > 'EmergencyCallData' MUST NOT be sent unless the call is an=20 > emergency call >=20 Unless this document updates RFC 3261, which it does not, it cannot preclud= e any string being sent in the purpose value. This is nothing in the original text that is to do with interoperability, a= fter all the recipient knows from other information that this is an emergen= cy call, or not an emergency call. There is therefore no need to protect fo= r wrong usage outside an emergency call. So I believe that there is no need for any normative language here and rath= er what is meant is: NEW TEXT A Call-info header with a purpose value starting with 'EmergencyCallData' only has meaning in the context of an emergency call= , which can be ascertained by the presence of an emergency service urn in a Route header of a SIP message. It has no meaning outside the context of an eme= rgency call." As a result of opening the document again I also noted the following that w= ould be worthy of comment. Section 4.2.3: OLD TEXT ---------- The URI, when dereferenced, MUST yield a data structure defined by the Device/service specific additional data type value. =20 The normative requirement here is nothing to do with the dereferencing. It = appears this is a requirement to keep the link between the URI and the data= for a period of time; the period of time is not specified, but from the su= bsequent text would appear to be for the duration a responder might be invo= lved in the emergency call. What is the real requirement here, does it apply to something within the sc= ope of this document, and can it be tested. Section 5 ----------- OLD TEXT Every block must be one of the types in the registry. As specified this can be confused with a normative requirement. The registr= y is transient data and therefore cannot be tested against. It is also uncl= ear what is meant by "type" as multiple types exist in the document. I assu= me "service type". I would suggest. "All service types used in blocks are expected to be registered" But it is dubious whether we need any sentence at all rather than the impli= cit one that says "If a registry is provided for an element then all values= are expected to be registered". Section 9 ---------- OLD TEXT Local regulations may govern what data must be provided in emergency calls, but in general, the emergency call system is aided by the information described in this document.=20 /must be/is/ Section 10.1.9 -------------- OLD TEXT This document creates a new sub-registry called 'Device/Service Data Type Registry'. As defined in [RFC5226], this registry operates under "Expert Review" and "Specification Required" rules. Expert review and Specification required are two distinct categories of IAN= A policy. As written it might be assumed that either can be used. It is suf= ficient to say "Specification required" and then go into details about what= the implicit expert review associated with this policy requires. Similar comments apply elsewhere e.g. 10.1.10 Like Alissa I would prefer that all the material that IANA has to deal with= is within the IANA considerations sections, and not referenced back to oth= er parts of the document (even if that means duplication of text). Section 10.2 ------------ TEXT Note that 'EmergencyCallData' is a compound value; when used as a value of the 'purpose' parameter of the Call-Info header, 'EmergencyCallData' is immediately followed by a dot ('.') and a value from the 'Emergency Call Data Types' registry Section 10.1.10. This text would appear to be nothing to do with the registry or the values = placed in the registry. Other comment ------------- RFC 3261 contains the statement in section 16.6. The proxy MUST NOT add to, modify, or remove the message body. As this document does not update RFC 3261, I assume any intermediate SIP en= tity acting as a proxy can only alter the Call-Info header and not add to t= he body. In order to add to the body it must be a B2BUA. This should be ide= ntified somewhere in the document. =20 Regards Keith > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Alissa Cooper > Sent: 30 April 2015 23:57 > To: ecrit@ietf.org > Subject: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29 >=20 > I have reviewed draft-ietf-ecrit-additional-data-29 in=20 > preparation for IETF last call. There are a number of issues=20 > that need to be resolved before the IETF LC can be issued,=20 > which I've included below as substantive comments and=20 > questions. There is a list of nits at the end that also need=20 > to be fixed. >=20 > Substantive comments and questions: >=20 > General: > I've asked the shepherd to validate all of the XML in the=20 > document and am waiting to hear back on that. >=20 > Section 1: > I would suggest adding this text from Section 9 or something=20 > like it at the end of the introduction: >=20 > "Much of the information supplied by service providers and devices is > private and confidential; service providers and devices=20 > generally go > to lengths to protect this information; disclosing it in=20 > the context > of an emergency call is a trade-off to protect the greater interest > of the customer in an emergency." >=20 > Section 4.1: > I am a little confused about how this section applies when=20 > the data is being provided by the device. First, this text=20 > seems to consider the device to be a "service provider": >=20 > "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." >=20 > I think this would be clearer if the first sentence said "any=20 > service provider in the path of the call, the access network=20 > provider, or the device."=20 >=20 > Then later in the section Data Provider ID, Data Provider ID=20 > Series, and Type of Data Provider are defined. None of these=20 > seem to apply when the data is provided by the device, and=20 > yet they are all listed as required. What are these elements=20 > supposed to contain when the data is provided by the device?=20 > I see in the example in Section 6 that only Type of Data=20 > Provider is included, and is listed as "Other," which seems=20 > less specific than it ideally could be. >=20 > Section 4.1.2: > Is there an EENA equivalent of the NENA company ID? If so, it=20 > should be mentioned here.=20 >=20 > Is it the case that where a jurisdiction-specific ID exists,=20 > it is preferred over an FQDN? If so, that should be stated explicitly. >=20 > Section 4.1.5: > "If the call is from a device, this SHOULD be the contact > information of the owner of the device." >=20 > What are the exception cases for this SHOULD? What should=20 > this element be if it is not the owner's contact info? >=20 > Section 4.1.6: > By saying the other language tags are independent of this=20 > language element, does that mean they should be ignored? If=20 > so, that should be stated explicitly. >=20 > Section 4.1.9: > "This element is required if the Data Provider > type is set to "Subcontractor"." >=20 > Subcontractor is not listed as a data provider type in=20 > section 4.1.4, so this doesn't quite make sense. >=20 > Section 4.2.1: > Shouldn't "use" be listed as conditional? >=20 > Section 4.2.3: > s/MUST NOT/ought not to/ >=20 > Section 4.3.4: > I'm curious about the kinds of "investigations" that PSAPs do=20 > and how they have used unique device IDs in those=20 > investigations -- could you explain? At first blush this=20 > seems to require over-sharing of sensitive data. >=20 > Section 4.4.1: > Are there any jurisdiction-specific rules you can point to=20 > that would indicate that having a single boolean "privacy"=20 > value will actually be interpretable and of use by any PSAP?=20 > I find it a little hard to believe that PSAPs will know what=20 > actions this value is supposed to apply to (e.g., display,=20 > logging, display and logging, etc.) and what data fields it=20 > is supposed to apply to. Without further definition (or some=20 > compelling evidence that PSAPs in at least some places have=20 > well-specified rules for what to do when they receive this=20 > value), this indicator seems pretty hand-wavy. >=20 > Section 4.4.2: > Are there any xCard fields you would recommend not sending=20 > for lack of relevance (e.g., anniversary)? >=20 > Depending on what the answer is to my question in 4.1.6 about=20 > interaction between Data Provider Language(s) and language=20 > tags, there might need to be text in this section as well=20 > about expected behavior when both are present and when the=20 > data provider is the device. >=20 > Section 5.1: > The last paragraph here makes it sound as though additional=20 > data is required to be sent on every emergency call (i.e.,=20 > every call with an emergency service URN in the route=20 > header). Is that the intention? If so, that needs to be made=20 > more clear and should be explained earlier in the document,=20 > preferably in the introduction. If not, the normative=20 > language in the last paragraph here needs to be fixed. >=20 > Section 6: > The owner/subscriber of this laptop is Hannes Tschofenig. His=20 > contact tel URI is in North America but his work and home are=20 > in Finland. He is using a VoIP provider that provides its=20 > NENA ProviderID, which I assume indicates that the service is=20 > being provided in North America? The VoIP provider contact=20 > person is located in the UK, however. And then when the=20 > access network provides the location, it is in Australia. >=20 > The last bit just seems wrong to me, for a plausible=20 > emergency call. The other bits seem to amount to a possible=20 > (but not likely?) example scenario but the details require=20 > more narrative explanation in the text. Alternatively, a=20 > simpler or more plausible example might help readers out more. >=20 > Section 8: > "Mechanisms that > protect against eavesdropping (such as Transport Layer Security > (TLS)) SHOULD be preferentially used whenever feasible." >=20 > This needs a sentence about the existing deployed base of=20 > clear text SIP to explain why this requirement is not a MUST.=20 >=20 > s/HTTPS is specified/HTTPS is REQUIRED/ >=20 > "Data provided by devices by reference have similar credential > validation issues as for service providers, and the=20 > solutions are the > same." >=20 > Maybe the solutions are the same, but aren't the challenges=20 > of doing this for every device much more significant? That=20 > seems worth mention. >=20 > s/Service providers SHOULD choose the latter/Service=20 > providers ought to choose the latter/ (otherwise this reads=20 > like a normative requirement on IMS functionality) >=20 > Section 10.1.1: > "Private entities issuing and using internally-generated IDs are > encouraged to register and use a unique identifier." >=20 > What is meant by "use a unique identifier"? >=20 > Section 10.1.8: > It might be useful to give the experts some additional=20 > criteria around weighing privacy vs. utility trade-offs.=20 > E.g., if someone wants to register the biometric fingerprint=20 > used to authenticate a device as a device ID and few or no=20 > PSAPs can actually make use of it, that may argue against=20 > registering it. >=20 > Section 12.2: > I think RFC 3966 should be a normative reference. >=20 >=20 > Nits: >=20 > General: > Why are some of the registry tables in the main sections of=20 > the document and others are in the IANA Considerations=20 > section? Seems like they should all be one or the other. >=20 > Section 2: > Citations for vCard and xCard should be added to the last paragraph. >=20 > Section 4.1.7: > This sentence seems redundant: "For encoding of the xCard this > specification uses the XML-based encoding specified in=20 > [RFC6351], > referred to in this document as "xCard"." > =20 > Section 4.2.1: > s/therefore this is/this is/ >=20 > s/Figure 22/Section 10.1.2/ >=20 > Section 4.2.2: > s/Figure 3/Section 10.1.3/ >=20 > Section 4.2.3: > s/Figure 23/Section 10.1.4/ >=20 > Section 4.3.6: > A reference to the IEEE 1512 spec should be included. >=20 > Section 4.3.7: > s/which allow/that allow/ >=20 > "Some standards being developed by other organizations" --=20 > would be good to provide citations. >=20 > Section 4.4.2: > Given that 4.4 says the location provided here is the contact=20 > address and not necessarily the location of the caller, it=20 > seems like this section needs to explain a little more why a=20 > call taker would use the location provided here. >=20 > Section 5.1: > OLD > A Call-info header with a purpose value starting with > 'EmergencyCallData' MUST only be sent on an emergency call=20 > NEW A Call-info header with a purpose value starting with > 'EmergencyCallData' MUST NOT be sent unless the call is an=20 > emergency call > =20 > Section 9: > s/The functionality defined in this document, however/The=20 > functionality defined in this document/ >=20 > Section 10.1.2: > s/A s[RFC4119]hort/A short/ >=20 > Section 10.1.5: > Seems like this section and Figure 1 should both use "Token"=20 > rather than "Tokenproviderid." > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From nobody Fri May 1 15:06:02 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 DE23F1A0264 for ; Fri, 1 May 2015 15:06:00 -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 CaY0Z9O3yMdf for ; Fri, 1 May 2015 15:05:58 -0700 (PDT) Received: from server907.appriver.com (server907.appriver.com [204.232.250.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAA21A0270 for ; Fri, 1 May 2015 15:05:56 -0700 (PDT) X-Note-AR-ScanTimeLocal: 5/1/2015 6:05:53 PM X-Policy: GLOBAL - UNKNOWN X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 4/17/2015 7:31:11 PM UTC X-Virus-Scan: V- X-Note: ICH-CT/SI:0-694/SG:1 5/1/2015 6:05:39 PM X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-336/SG:8 5/1/2015 6:04:55 PM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=1 p=-0.985578 Source White X-Signature-Violations: 0-0-0-14129-c X-Note-419: 0 ms. Fail:0 Chk:1319 of 1319 total X-Note: SCH-CT/SI:0-1319/SG:1 5/1/2015 6:05:42 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: G254 G255 G256 G257 G261 G262 G376 G388 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 5808658 for ecrit@ietf.org; Fri, 01 May 2015 18:05:53 -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.1104.1; Fri, 1 May 2015 18:05:53 -0400 Received: from DAGN04A-S1E7.exg7.exghost.local ([fe80::8910:68f9:549b:d97b]) by DAGN04A-S1E7.exg7.exghost.local ([fe80::8910:68f9:549b:d97b%22]) with mapi id 15.00.1104.000; Fri, 1 May 2015 18:05:53 -0400 From: Matt Serra To: "ecrit@ietf.org" Thread-Topic: Suggestion for "Provider-Info" block usage (draft-ietf-ecrit-additional-data-29.txt) Thread-Index: AdCEWlU4uQ8diqUCS4OSSbY6wXhOXg== Date: Fri, 1 May 2015 22:05:53 +0000 Message-ID: <0545a5a6cb97408c9a6a288b6831a61f@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_0545a5a6cb97408c9a6a288b6831a61fDAGN04AS1E7exg7exghostl_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [Ecrit] Suggestion for "Provider-Info" block usage (draft-ietf-ecrit-additional-data-29.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 22:06:01 -0000 --_004_0545a5a6cb97408c9a6a288b6831a61fDAGN04AS1E7exg7exghostl_ Content-Type: multipart/alternative; boundary="_000_0545a5a6cb97408c9a6a288b6831a61fDAGN04AS1E7exg7exghostl_" --_000_0545a5a6cb97408c9a6a288b6831a61fDAGN04AS1E7exg7exghostl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Our NENA Additional Data WG made an observation that we'd like to submit fo= r the groups consideration: We noted section 4.1 describes the usage for the "Data Provider Information= Block" as "SHOULD" and "MAY" provide. We'd like to propose that the group consider making the usage of this block= "Conditional": MUST be provided if the data-provider inserts any other blo= ck, otherwise MAY be provided. This would ensure that the provider of all data inserted into the Call Info= header identifies themselves. Regards, Matt [rave_email_signature] Matthew A. Serra, ENP Sr. Director, Product Management Mobile: 201.245.1557 mserra@ravemobilesafety.com --_000_0545a5a6cb97408c9a6a288b6831a61fDAGN04AS1E7exg7exghostl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our NENA Additional Data WG made an observation that= we’d like to submit for the groups consideration:

 

We noted section 4.1 describes the usage for the = 220;Data Provider Information Block” as “SHOULD” and R= 20;MAY” provide.

 

We’d like to propose that the group consider m= aking the usage of this block “Conditional”: MUST be provided i= f the data-provider inserts any other block, otherwise MAY be provided.

 

This would ensure that the provider of all data inse= rted into the Call Info header identifies themselves.

 

Regards,

 

Matt

 

3D"rave_email_signature"

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

 

 

--_000_0545a5a6cb97408c9a6a288b6831a61fDAGN04AS1E7exg7exghostl_-- --_004_0545a5a6cb97408c9a6a288b6831a61fDAGN04AS1E7exg7exghostl_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3039; creation-date="Fri, 01 May 2015 22:05:53 GMT"; modification-date="Fri, 01 May 2015 22:05:53 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_0545a5a6cb97408c9a6a288b6831a61fDAGN04AS1E7exg7exghostl_-- From nobody Fri May 1 15:21:52 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 2632A1A19F7 for ; Fri, 1 May 2015 15:21:51 -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 X1zpeltmdPZr for ; Fri, 1 May 2015 15:21:48 -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 51E901A070E for ; Fri, 1 May 2015 15:21:48 -0700 (PDT) X-Note-AR-ScanTimeLocal: 5/1/2015 6:21:46 PM X-Policy: GLOBAL - UNKNOWN X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 4/17/2015 7:31:11 PM UTC X-Virus-Scan: V- X-Note: ICH-CT/SI:0-694/SG:1 5/1/2015 6:21:16 PM X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-624/SG:8 5/1/2015 6:21:20 PM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=1 p=-0.98407 Source White X-Signature-Violations: 0-0-0-19556-c X-Note-419: 15.627 ms. Fail:0 Chk:1319 of 1319 total X-Note: SCH-CT/SI:0-1319/SG:1 5/1/2015 6:21:45 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: G254 G255 G256 G257 G261 G262 G376 G388 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 84848 for ecrit@ietf.org; Fri, 01 May 2015 18:21:46 -0400 Received: from DAGN04A-S1E7.exg7.exghost.local (192.168.244.53) by DAGN04A-S1E7.exg7.exghost.local (192.168.244.53) with Microsoft SMTP Server (TLS) id 15.0.1104.1; Fri, 1 May 2015 18:21:46 -0400 Received: from DAGN04A-S1E7.exg7.exghost.local ([fe80::8910:68f9:549b:d97b]) by DAGN04A-S1E7.exg7.exghost.local ([fe80::8910:68f9:549b:d97b%22]) with mapi id 15.00.1104.000; Fri, 1 May 2015 18:21:46 -0400 From: Matt Serra To: "ecrit@ietf.org" Thread-Topic: Suggestion for "Provider-Info" block usage (draft-ietf-ecrit-additional-data-29.txt) Thread-Index: AdCEWy9Iv7yRS73OTvey/I4v0MK6rQ== Date: Fri, 1 May 2015 22:21:46 +0000 Message-ID: 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_daf15f4d4f5c4c17b8fe2895f75a843eDAGN04AS1E7exg7exghostl_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [Ecrit] Suggestion for "Provider-Info" block usage (draft-ietf-ecrit-additional-data-29.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 22:21:51 -0000 --_004_daf15f4d4f5c4c17b8fe2895f75a843eDAGN04AS1E7exg7exghostl_ Content-Type: multipart/alternative; boundary="_000_daf15f4d4f5c4c17b8fe2895f75a843eDAGN04AS1E7exg7exghostl_" --_000_daf15f4d4f5c4c17b8fe2895f75a843eDAGN04AS1E7exg7exghostl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another recommendation coming out of the NENA Additional Data WG: I raised this a few weeks ago, and I realize I may not have been clear enou= gh the first time around. After speaking with Randall Gellens this evening= , he recommended I resubmit this suggestion for re-consideration by this wo= rk group: The Additional Data Draft, as written, describes mechanisms to carry additi= onal information about the call itself. The mechanisms defined in this additional-data document are targeted for ex= pansion. This is alluded to in section 1, where it recognizes the existenc= e of data that can be associated with a Caller and Location in addition to = the Call. Since it is likely that additional data blocks will be added to address Cal= ler and Location, and that Caller and Location data may reuse some of the d= ata-blocks identified for Call Data (minimally Provider Information and Com= ments) an additional field, named something like "Information About", with = an initial registry value of "Call" may be warranted. This could be expand= ed to include "Location", "Caller", etc. as Data Structures are added to th= e Emergency Call Data Types registry (10.1.10) to support other forms of da= ta. Potentially this new field could be located in the Provider Info block, alt= hough Randy suggested it is probably best in each of the other blocks defin= ed in this draft standard. This would allow any system processing the Call= Info headers to readily determine what "kind" of data is being conveyed. At one time, forms of Additional Data were to be distinguished with a uniqu= e Purpose Parameter, but that was abandoned somewhere during the developmen= t of i3 or this IETF spec - likely for good reason. If valid, that would b= e another approach. I hope I'm being more clear this time around! Regards, Matt. [rave_email_signature] Matthew A. Serra, ENP Sr. Director, Product Management Mobile: 201.245.1557 mserra@ravemobilesafety.com --_000_daf15f4d4f5c4c17b8fe2895f75a843eDAGN04AS1E7exg7exghostl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another recommendation coming out of the NENA Additi= onal Data WG:

 

I raised this a few weeks ago, and I realize I may n= ot have been clear enough the first time around.  After speaking with = Randall Gellens this evening, he recommended I resubmit this suggestion for= re-consideration by this work group:

 

The Additional Data Draft, as written, describes mec= hanisms to carry additional information about the call itself.

 

The mechanisms defined in this additional-data docum= ent are targeted for expansion.  This is alluded to in section 1, wher= e it recognizes the existence of data that can be associated with a Caller = and Location in addition to the Call.

 

Since it is likely that additional data blocks will = be added to address Caller and Location, and that Caller and Location data = may reuse some of the data-blocks identified for Call Data (minimally Provi= der Information and Comments) an additional field, named something like “Information About”, with an initi= al registry value of “Call” may be warranted.  This could = be expanded to include “Location”, “Caller”, etc. a= s Data Structures are added to the Emergency Call Data Types registry (10.1= .10) to support other forms of data.

 

Potentially this new field could be located in the P= rovider Info block, although Randy suggested it is probably best in each of= the other blocks defined in this draft standard.  This would allow an= y system processing the Call Info headers to readily determine what “kind” of data is being conveyed.

 

At one time, forms of Additional Data were to be dis= tinguished with a unique Purpose Parameter, but that was abandoned somewher= e during the development of i3 or this IETF spec – likely for good re= ason.  If valid, that would be another approach.

 

I hope I’m being more clear this time around!<= o:p>

 

Regards,

 

Matt.

 

3D"rave_email_signature"

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

 

 

--_000_daf15f4d4f5c4c17b8fe2895f75a843eDAGN04AS1E7exg7exghostl_-- --_004_daf15f4d4f5c4c17b8fe2895f75a843eDAGN04AS1E7exg7exghostl_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3039; creation-date="Fri, 01 May 2015 22:21:46 GMT"; modification-date="Fri, 01 May 2015 22:21:46 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_daf15f4d4f5c4c17b8fe2895f75a843eDAGN04AS1E7exg7exghostl_-- From nobody Tue May 5 12:27:10 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 135FF1ACD6D for ; Tue, 5 May 2015 12:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.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] 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 CZetWZLcnIm0 for ; Tue, 5 May 2015 12:27:00 -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 539781ACD60 for ; Tue, 5 May 2015 12:26:59 -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=1430854020; x=1462390020; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=sr3HJ1dPT/TyPQ+hv2ie9OIqtzLDSTHrSqwkAlXQzNc=; b=giLTLwSGJhHjv3M82z/n9kOQqfIOQwygX7lPl8wMIb41o6CRPgqABGbO D7bFGHe8yW8CUGDjEoyjupQLf3YW3ssE3dfvYg4/+TNT/R1njYFkQSpUL /GhWavKThlY/g0utP+/QWDY7g2tfcyzopI5QimYYyzVpirSL12mkGsF5m E=; X-IronPort-AV: E=McAfee;i="5700,7163,7792"; a="116691559" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2015 12:26:59 -0700 X-IronPort-AV: E=Sophos;i="5.13,374,1427785200"; d="scan'208";a="878074831" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 May 2015 12:26:59 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 5 May 2015 12:26:58 -0700 Message-ID: In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112889CB0@ESESSMB301.ericsson.se> References: <385fee84e7fc4876db03e86bf9b641f8.squirrel@ocean.qualcomm.com> <39B5E4D390E9BD4890E2B31079006101128891C0@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112889CB0@ESESSMB301.ericsson.se> X-Mailer: Eudora for Mac OS X Date: Tue, 5 May 2015 12:26:53 -0700 To: Ivo Sedlacek , Roger Marshall , Randall Gellens , "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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To nasanexm02f.na.qualcomm.com (10.85.0.87) 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: Tue, 05 May 2015 19:27:03 -0000 I think Ivo makes a good point and I agree that the current text has some details that are out of scope of the draft. Accordingly, I suggest we simply say "in which SIP is used" and not get into these out of scope details. Here is a link to the PDF version of the revised text: https://www.dropbox.com/s/sk2vg5yllx7z8kp/Liaison%20Statement%20from%20IETF%20ECRIT%20WG%20to%203GPP%20%5Bclean%5D.pdf?dl=0 Here is a plain text version of the revised text: ------------------ Title: Liaison Statement on NG eCall support for the EU Date: xxxx Source: IETF Ecrit WG To: 3GPP SA1, SA2, CT1 Contact Person: Name: Randall Gellens Affiliation: Qualcomm Inc. Tel. Number: +1-858-651-5115 E-mail Address: randy@qti.qualcomm.com 1. Overall Description: The IETF ECRIT WG would like to inform 3GPP of IETF work enabling eCall over IETF SIP. The IETF has been developing a specification to support this (mainly in the EU but not limited to it). The document is still in a draft state and describes how an eCall placed using SIP is identified, transfers the MSD and supports other necessary interaction between an eCall IVS and a PSAP. IETF ECRIT intends the eventual RFC to define the necessary SIP protocol conventions and mechanisms that will be needed to support any solution (e.g., such as a solution defined later by 3GPP) in which SIP is used. The IETF draft has been referenced by ETSI in their report Mobile Standards Group (MSG); eCall for VoIP (TR 103 140 V1.1.1). The IETF would like to be sure that 3GPP is aware of the work, and welcomes 3GPP review of the work including any comments concerning possible omissions or other defects. The latest version of the document may be accessed at: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ Respectfully, The IETF ECRIT WG 2. Actions: To 3GPP SA1, SA2, CT1 groups. ACTION: Please provide any feedback to IETF Ecrit that may be useful or necessary to enable IETF Ecrit to complete their specification on support of NG eCall in the EU. 3. Date of Next IETF Ecrit Meeting: IETF#93 Dates: 19-24 July, 2015 Location: Prague, Czech Republic ------------------ At 8:04 AM +0000 4/30/15, Ivo Sedlacek wrote: > 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 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 two SIP UAs. > RFC will not specify interworking of the SIP based eCall to the > existing circuit 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 both ends are IP and SIP capable. > > Other than the above, I think the LS tooks OK. > > Kind regards > > Ivo Sedlacek > -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- If you would look up bad labor relations in the dictionary, you would have an American Airlines logo beside it. --U.S. District Judge Joe Kendall, issuing a restraining order against an American Airlines APA pilot union sick out, 10 Feb 1999. From nobody Tue May 5 15:49:08 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 ADE671B2A6F for ; Tue, 5 May 2015 15:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Zjye2xf_ubNv for ; Tue, 5 May 2015 15:49:05 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5674A1B2A71 for ; Tue, 5 May 2015 15:49: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=1430866146; x=1462402146; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=xphZ5QNpGMhmDnoXwS4HBpj9uI6E5OaCehoVZdiHUN4=; b=s5B2p2pb5I4G7DexJuDM0QzQ1HFT8HTbUYpMpwA19btr9YQK03WbC94q LO79h73yLLjj67QUOVHdTvXSLt/AjEFXpszjl4E0kT2dLysUbHNEyn7XE BK6REES12xeTeWR+ZkPuW88+t1kU/f5eztO2CHxQhVV+2MwhdiKK/RKNc c=; X-IronPort-AV: E=McAfee;i="5700,7163,7792"; a="89376835" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2015 15:49:04 -0700 X-IronPort-AV: E=Sophos;i="5.13,375,1427785200"; d="scan'208";a="963758350" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 May 2015 15:49:04 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 5 May 2015 15:49:02 -0700 Message-ID: In-Reply-To: <0545a5a6cb97408c9a6a288b6831a61f@DAGN04A-S1E7.exg7.exghost.local> References: <0545a5a6cb97408c9a6a288b6831a61f@DAGN04A-S1E7.exg7.exghost.local> X-Mailer: Eudora for Mac OS X Date: Tue, 5 May 2015 15:49:01 -0700 To: Matt Serra , "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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Ecrit] Suggestion for "Provider-Info" block usage (draft-ietf-ecrit-additional-data-29.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: Tue, 05 May 2015 22:49:07 -0000 At 10:05 PM +0000 5/1/15, Matt Serra wrote: > Our NENA Additional Data WG made an observation that we'd like to > submit for the groups consideration: > > We noted section 4.1 describes the usage for the "Data Provider > Information Block" as "SHOULD" and "MAY" provide. > > We'd like to propose that the group consider making the usage of > this block "Conditional": MUST be provided if the data-provider > inserts any other block, otherwise MAY be provided. > > This would ensure that the provider of all data inserted into the > Call Info header identifies themselves. This seems reasonable to me: if an entity adds any blocks, it MUST add a Provider Info block. If it touches the call in some way but does not add any blocks, it MAY add a Provider Info block (to indicate that it did touch the call, which might be useful for after the fact problem tracking). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Americans have an abiding belief in their ability to control reality by purely material means.... airline insurance replaces the fear of death with the comforting prospect of cash. ==Cecil Beaton, It Gives Me Great Pleasure, 1955. From nobody Tue May 5 16:00:12 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 01C391B2A87 for ; Tue, 5 May 2015 16:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 rTlDsuQJvcz9 for ; Tue, 5 May 2015 16:00:07 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C284A1A8939 for ; Tue, 5 May 2015 16:00: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=1430866807; x=1462402807; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=EQIZEk4Iu5r97S1piNp/Auao/DmC1AtyFhaOUFiqY08=; b=N4omjM4HMcQLkubXD0+QKb5swoZ/1f9mpwo5F0aXCQvMIsZ1f//vK2DF 7b7xqLOkJvH829zfkkcJxRcmixyVvrlPz497yYJhe6s6A14DwlRfN0gyM zAyzyjtdae3SbjuuvLrB0In6frVDzTD08jwG6hJNPhGtYSNclBqnToAPD 0=; X-IronPort-AV: E=McAfee;i="5700,7163,7792"; a="89377365" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 05 May 2015 16:00:07 -0700 X-IronPort-AV: E=Sophos;i="5.13,375,1427785200"; d="scan'208";a="32434628" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 05 May 2015 16:00:08 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 5 May 2015 16:00:06 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 5 May 2015 16:00:04 -0700 To: Matt Serra , "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-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Ecrit] Suggestion for "Provider-Info" block usage (draft-ietf-ecrit-additional-data-29.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: Tue, 05 May 2015 23:00:10 -0000 At 10:21 PM +0000 5/1/15, Matt Serra wrote: > Another recommendation coming out of the NENA Additional Data WG: > > I raised this a few weeks ago, and I realize I may not have been > clear enough the first time around. After speaking with Randall > Gellens this evening, he recommended I resubmit this suggestion for > re-consideration by this work group: > > The Additional Data Draft, as written, describes mechanisms to > carry additional information about the call itself. > > The mechanisms defined in this additional-data document are > targeted for expansion. This is alluded to in section 1, where it > recognizes the existence of data that can be associated with a > Caller and Location in addition to the Call. > > Since it is likely that additional data blocks will be added to > address Caller and Location, and that Caller and Location data may > reuse some of the data-blocks identified for Call Data (minimally > Provider Information and Comments) an additional field, named > something like "Information About", with an initial registry value > of "Call" may be warranted. This could be expanded to include > "Location", "Caller", etc. as Data Structures are added to the > Emergency Call Data Types registry (10.1.10) to support other forms > of data. > > Potentially this new field could be located in the Provider Info > block, although Randy suggested it is probably best in each of the > other blocks defined in this draft standard. This would allow any > system processing the Call Info headers to readily determine what > "kind" of data is being conveyed. > > At one time, forms of Additional Data were to be distinguished with > a unique Purpose Parameter, but that was abandoned somewhere during > the development of i3 or this IETF spec - likely for good reason. > If valid, that would be another approach. > > I hope I'm being more clear this time around! I'd like to suggest that this additional information exist in the registration information for each block, but not in the block itself. Currently, the registration/description of each block carries the following items of information (referred to as labels): Data Element: A unique human-readable concise name for the block Use: Required, Conditional, or Optional XML Element: a unique XML element name Description: Human-readable description of the block Reason for Need: Human-readable explanation of why the block is needed How Used by Call Taker: Human-readable explanation of how block is used I'm suggesting that we add one additional item to this list: Information About. This would not change the contents of the blocks (and hence nor their XML schema), it only changes the description of the blocks. However, this should make it easier for entities to establish policy as to which blocks they will access and which they won't. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Progress is made on alternate Fridays. From nobody Mon May 11 00:17:08 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 2D4051A1B8E for ; Mon, 11 May 2015 00:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 tolS6s2DVbWh for ; Mon, 11 May 2015 00:17:05 -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 CCB4A1A1B87 for ; Mon, 11 May 2015 00:17:04 -0700 (PDT) X-AuditID: c1b4fb30-f798d6d0000009ec-1a-5550576ef26b Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0C.D4.02540.E6750555; Mon, 11 May 2015 09:17:02 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.223]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Mon, 11 May 2015 09:17:02 +0200 From: Ivo Sedlacek To: Randall Gellens , Roger Marshall , Randall Gellens , "marc.linsner@cisco.com" Thread-Topic: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP Thread-Index: AQHQh2l7/ai+6AhaA0KNonhdI2gzWp12ZbeA Date: Mon, 11 May 2015 07:17:01 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011289195F@ESESSMB301.ericsson.se> References: <385fee84e7fc4876db03e86bf9b641f8.squirrel@ocean.qualcomm.com> <39B5E4D390E9BD4890E2B31079006101128891C0@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112889CB0@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.146] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3RjcvPCDU4O9NY4vGRU9ZLTac+sZi ce1RB7PFl8MdrBaHry5lcmD1mPJ7I6vHkiU/mTwWTX3G6LHpQzerx4atp5gDWKO4bFJSczLL Uov07RK4MhoPrWcq2KdQ0fLiClsD42rJLkZODgkBE4n/vz4wQdhiEhfurWfrYuTiEBI4yijx 5MRiRghnCaPEum37wKrYBPQkJm45wgqSEBHYxiix8vIkNpAEs4CqxLnGxywgtrCAo8Sn68eZ uxg5gIqcJM5flwYJiwgYSXyZMBNsDgtQ+cvNj1lBbF4BX4lXG64yQyw7ziTx99FDdpAEJ9B5 J6c/YQaxGQVkJa7+6WWE2CUucevJfKizBSSW7DnPDGGLSrx8/I8VwlaS+LHhEgtEvZ7Es1Oz oGxtiWULXzNDLBaUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWJ+WmGxnppRZlJhcX 5+fp5aWWbGIExt/BLb8NdjC+fO54iFGAg1GJh/fBFf9QIdbEsuLK3EOM0hwsSuK8dsaHQoQE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw1kcvvhhl33Uhpr3j90bOHrP//sFqnVM9Nh3/FNB6 RbL3iePNBf+S+Zp953C93FTDVnQg5/2p8Gclz39u37GM89wnK/15hwzVlQ7zvN5fOG/BpOw/ KgnLhP0CyhcKr7L5sN9kVo3Dg9XK9jz/SrQu+H5fO+3guY7VXGelvHfYf40T5Y637u5YpsRS nJFoqMVcVJwIABpVovmgAgAA 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, 11 May 2015 07:17:07 -0000 OK for me. Thank you for addressing my comment. Kind regards Ivo Sedlacek -----Original Message----- From: Randall Gellens [mailto:randy@qti.qualcomm.com]=20 Sent: 5. kv=ECtna 2015 21:27 To: Ivo Sedlacek; Roger Marshall; Randall Gellens; marc.linsner@cisco.com Cc: ecrit@ietf.org Subject: RE: [Ecrit] Liaison Statement from IETF ECRIT WG to 3GPP I think Ivo makes a good point and I agree that the current text has some d= etails that are out of scope of the draft. Accordingly, I suggest we simpl= y say "in which SIP is used" and not get into these out of scope details. Here is a link to the PDF version of the revised text: https://www.dropbox.com/s/sk2vg5yllx7z8kp/Liaison%20Statement%20from%20IETF= %20ECRIT%20WG%20to%203GPP%20%5Bclean%5D.pdf?dl=3D0 Here is a plain text version of the revised text: ------------------ Title: Liaison Statement on NG eCall support for the EU Date: xxxx Source: IETF Ecrit WG To: 3GPP SA1, SA2, CT1 Contact Person: Name: Randall Gellens Affiliation: Qualcomm Inc. Tel. Number: +1-858-651-5115 E-mail Address: randy@qti.qualcomm.com 1. Overall Description: The IETF ECRIT WG would like to inform 3GPP of IETF work enabling eCall ove= r IETF SIP. The IETF has been developing a specification to support this (= mainly in the EU but not limited to it). The document is still in a draft s= tate and describes how an eCall placed using SIP is identified, transfers t= he MSD and supports other necessary interaction between an eCall IVS and a = PSAP. IETF ECRIT intends the eventual RFC to define the necessary SIP proto= col conventions and mechanisms that will be needed to support any solution = (e.g., such as a solution defined later by 3GPP) in which SIP is used. The = IETF draft has been referenced by ETSI in their report Mobile Standards Gro= up (MSG); eCall for VoIP (TR 103 140 V1.1.1). The IETF would like to be sure that 3GPP is aware of the work, and welcomes= 3GPP review of the work including any comments concerning possible omissio= ns or other defects. The latest version of the document may be accessed at: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ Respectfully, The IETF ECRIT WG 2. Actions: To 3GPP SA1, SA2, CT1 groups. ACTION: Please provide any feedback to IETF Ecrit that may be useful or necessary to enable IETF Ecrit to complete their specification on= support of NG eCall in the EU. 3. Date of Next IETF Ecrit Meeting: IETF#93 Dates: 19-24 July, 2015 Location: Prague, Czech Republic ------------------ At 8:04 AM +0000 4/30/15, Ivo Sedlacek wrote: > Hello, > > the following sentence of the LS is misleading. > > IETF ECRIT intends the eventual RFC to define the=20 > necessary SIP protocol convensions and mechanisms that will be needed=20 > to support any end-to-end solution > (e.g. such as a solution defined later by 3GPP) in=20 > which both ends (IVS adn PSAP) are IP capable or in which one end is=20 > IP capable with 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=20 > existing circuit switched based eCall. > > Thus, I propose to modify the statement as follows: > > IETF ECRIT intends the eventual RFC to define the=20 > necessary SIP protocol convensions and mechanisms that will be needed=20 > to support any solution > (e.g. such as a solution defined later by 3GPP) in=20 > which both ends are IP and SIP capable. > > Other than the above, I think the LS tooks OK. > > Kind regards > > Ivo Sedlacek > -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- If you would look up = bad labor relations in the dictionary, you would have an American Airlines = logo beside it. --U.S. District Judge Joe Kendall, issuing a restraining order against = an American Airlines APA pilot union sick out, 10 Feb 1999. From nobody Mon May 11 08:24:20 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 7DB7E1A8F34 for ; Mon, 11 May 2015 08:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 J84XoDb1aOND for ; Mon, 11 May 2015 08:24:16 -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 2C2E51A8F33 for ; Mon, 11 May 2015 08:24:15 -0700 (PDT) X-Note-AR-ScanTimeLocal: 5/11/2015 11:24:13 AM X-Policy: GLOBAL - UNKNOWN X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 5/5/2015 3:12:01 PM UTC X-Virus-Scan: V- X-Note: ICH-CT/SI:0-695/SG:1 5/11/2015 11:23:29 AM X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-928/SG:8 5/11/2015 11:23:45 AM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=1 p=-0.981228 Source White X-Signature-Violations: 0-0-0-16948-c X-Note-419: 0 ms. Fail:0 Chk:1323 of 1323 total X-Note: SCH-CT/SI:0-1323/SG:1 5/11/2015 11:24:07 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 G388 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 6418970 for ecrit@ietf.org; Mon, 11 May 2015 11:24:13 -0400 Received: from DAGN04A-S1E7.exg7.exghost.local (192.168.244.53) by DAGN04C-S1E7.exg7.exghost.local (192.168.244.55) with Microsoft SMTP Server (TLS) id 15.0.1104.1; Mon, 11 May 2015 11:24:13 -0400 Received: from DAGN04A-S1E7.exg7.exghost.local ([fe80::8910:68f9:549b:d97b]) by DAGN04A-S1E7.exg7.exghost.local ([fe80::8910:68f9:549b:d97b%22]) with mapi id 15.00.1104.000; Mon, 11 May 2015 11:24:13 -0400 From: Matt Serra To: "ecrit@ietf.org" Thread-Topic: Request for clarification: Dave Provider ID / Data Provider ID Series Usage (and Type of Data Provider) Thread-Index: AdCL/j81YUZiGgIGRY2K8hoj+cwY0Q== Date: Mon, 11 May 2015 15:24:13 +0000 Message-ID: <28a5559a9d184119bea47ea803a4a248@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_28a5559a9d184119bea47ea803a4a248DAGN04AS1E7exg7exghostl_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [Ecrit] Request for clarification: Dave Provider ID / Data Provider ID Series Usage (and Type of Data Provider) 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, 11 May 2015 15:24:18 -0000 --_004_28a5559a9d184119bea47ea803a4a248DAGN04AS1E7exg7exghostl_ Content-Type: multipart/alternative; boundary="_000_28a5559a9d184119bea47ea803a4a248DAGN04AS1E7exg7exghostl_" --_000_28a5559a9d184119bea47ea803a4a248DAGN04AS1E7exg7exghostl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Group: In the Additional Call Data draft, the Data Provider ID and Data Provider I= D Series fields within the Data Provider Information Block are shown as Req= uired. In addition to coming from a Service or Access provider, the Additional Cal= l Data can also be provided by the device or user agent. In the case of the Device or User Agent, how should these blocks be populat= ed? The device or UA would not have a NENA or EENA assigned Data Provider = ID. While the spec allow for a "domain" to be used as a Provider ID, the d= omain alone would not uniquely identify the device or User agent. That lan= guage seems to exist to accommodate Service and Access Network providers. So - it seems like we should EITHER provide guidance on how to populate the= se fields in this case (perhaps populate the Data Provider ID with From URI= or PAI? And Data Provider ID Series with "domain" or maybe "URI"?!?!) OR = make these fields optional where provided by a device or user agent and all= ow the From URI/PAI in the INVITE to speak for themselves? This also has ramifications on "Type of Data Provider" as well. There shou= ld be "Device" and "User Agent" value(s) I'd think. Thanks, [rave_email_signature] Matthew A. Serra, ENP Sr. Director, Product Management Mobile: 201.245.1557 mserra@ravemobilesafety.com --_000_28a5559a9d184119bea47ea803a4a248DAGN04AS1E7exg7exghostl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Group:

 

In the Additional Call Data draft, the Data Provider= ID and Data Provider ID Series fields within the Data Provider Information= Block are shown as Required.

 

In addition to coming from a Service or Access provi= der, the Additional Call Data can also be provided by the device or user ag= ent.

 

In the case of the Device or User Agent, how should = these blocks be populated?  The device or UA would not have a NENA or = EENA assigned Data Provider ID.  While the spec allow for a “dom= ain” to be used as a Provider ID, the domain alone would not uniquely identify the device or User agent.  That language = seems to exist to accommodate Service and Access Network providers.

 

So – it seems like we should EITHER provide gu= idance on how to populate these fields in this case (perhaps populate the D= ata Provider ID with From URI or PAI? And Data Provider ID Series with R= 20;domain” or maybe “URI”?!?!)  OR make these fields optional where provided by a device or user agent and allow the Fro= m URI/PAI in the INVITE to speak for themselves?

 

This also has ramifications on “Type of Data P= rovider” as well.  There should be “Device” and R= 20;User Agent” value(s) I’d think.

 

Thanks,

 

3D"rave_email_signature"

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

 

 

--_000_28a5559a9d184119bea47ea803a4a248DAGN04AS1E7exg7exghostl_-- --_004_28a5559a9d184119bea47ea803a4a248DAGN04AS1E7exg7exghostl_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3039; creation-date="Mon, 11 May 2015 15:24:12 GMT"; modification-date="Mon, 11 May 2015 15:24:12 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_28a5559a9d184119bea47ea803a4a248DAGN04AS1E7exg7exghostl_-- From nobody Fri May 22 19:27:44 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 D3E6F1A89B9 for ; Fri, 22 May 2015 19:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVMpMnYv6D4D for ; Fri, 22 May 2015 19:27:41 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (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 CD2541A899F for ; Fri, 22 May 2015 19:27:41 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so32549257pac.2 for ; Fri, 22 May 2015 19:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=/vhmWORDDGXXhiIS8t7mLdZf95FuLkO6NLMPSy4xf2E=; b=IuIXOw9zpVGFjYi3XnUN0g/YeZMvZ0cp+2wsuKekIoEnTrh62FQxoFyVv+e7wkHXWF WIfo/TGD+5EXK+gZnqYnow7KEh/rcK4+KV2Sri9ZIf1UcNpeAN3ZtAg0oENKZ2P8V3qu dyBP0+Kcr/gk84jY7aq4ecDFYoFjXX6ZfBn+6o1q6OmcSm977eu9RoflnyzjEZVPiwCY rkZzIF2hMDwVT9ncP7yc2PEnxq0+KsNFKUHV4K5gm7hfMEkHSkPjnwDnixCcP6cEuoXv 4jf0E1B0nJ0rR1KzzWIyfjkGUH9yuSfi+Tr1hHWimXfhIqHlfbR0Q7AiiOSsM64flXqp dt5g== X-Received: by 10.70.35.201 with SMTP id k9mr20452662pdj.128.1432348061515; Fri, 22 May 2015 19:27:41 -0700 (PDT) Received: from [192.168.1.100] ([1.150.114.23]) by mx.google.com with ESMTPSA id l1sm3343440pdp.71.2015.05.22.19.27.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 May 2015 19:27:40 -0700 (PDT) From: James Winterbottom Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 23 May 2015 12:27:45 +1000 To: "ecrit_ietf.org" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Ecrit] HELD routing progress X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 02:27:43 -0000 Hi Chairs, I updated this draft with the rough consensus reached at the last = meeting, which was to include an extension point. I would like to ask that a WGLC be initiated for this work please. Cheers James= From nobody Tue May 26 15:41: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 B72DD1B32D7 for ; Tue, 26 May 2015 15:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 XLDKL6fMx_Jc for ; Tue, 26 May 2015 15:41:28 -0700 (PDT) Received: from server907.appriver.com (server907.appriver.com [204.232.250.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897861B32DC for ; Tue, 26 May 2015 15:41:24 -0700 (PDT) X-Note-AR-ScanTimeLocal: 5/26/2015 6:41:22 PM X-Policy: GLOBAL - UNKNOWN X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-Note: SecureTide Build: 5/5/2015 3:12:01 PM UTC X-Virus-Scan: V- X-Note: ICH-CT/SI:0-697/SG:1 5/26/2015 6:41:20 PM X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-176/SG:8 5/26/2015 6:40:37 PM X-GBUdb-Analysis: 0, 10.246.0.39, Ugly c=0.9895 p=-0.985672 Source White X-Signature-Violations: 0-0-0-32393-c X-Note-419: 15.6258 ms. Fail:1 Chk:1327 of 1327 total X-Note: SCH-CT/SI:1-1327/SG:1 5/26/2015 6:41:15 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: G254 G255 G256 G257 G261 G262 G376 G388 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 7659503 for ecrit@ietf.org; Tue, 26 May 2015 18:41:22 -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.1104.1; Tue, 26 May 2015 18:41:20 -0400 Received: from DAGN04A-S1E7.exg7.exghost.local ([fe80::2d3a:34ed:796e:7e40]) by DAGN04A-S1E7.exg7.exghost.local ([fe80::2d3a:34ed:796e:7e40%22]) with mapi id 15.00.1104.000; Tue, 26 May 2015 18:41:21 -0400 From: Matt Serra To: "ecrit@ietf.org" Thread-Topic: Request for clarification: Dave Provider ID / Data Provider ID Series Usage (and Type of Data Provider) Thread-Index: AdCL/j81YUZiGgIGRY2K8hoj+cwY0QMBQ1PQ Date: Tue, 26 May 2015 22:41:20 +0000 Message-ID: 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_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] Request for clarification: Dave Provider ID / Data Provider ID Series Usage (and Type of Data Provider) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 22:41:37 -0000 --_004_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl_ Content-Type: multipart/alternative; boundary="_000_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl_" --_000_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have not seen any comment on this, so I'll try to bring the issue into sh= arper focus. I'd appreciate knowing if there is support for the Preferred Solution or Al= ternate Solution I outline below (or if you have better idea). Problem: * Within the Data Provider Block, Data Provider ID and Provider ID = Series are required fields. * Per the DRAFT, there are cases where an entity providing the Data= Provider Block would not be able to fill out these required fields as they= are defined, which in North America calls for populating a NENA Company ID= which an end-user would not have. * Examples of entities that could not meet this requirement are end= -user managed devices or a user agent used to place an emergency call. Preferred Solution: * Instruct the Device or User Agent to populate Data Provider ID wi= th the PAI or From URI from the SIP INVITE * Instruct the Device or User Agent to populate Data Provider ID Se= ries with 'End-User' or a similar string. Update the Provider ID registry = with this new value * Add a value to the Type of Data Provider to read as "End User" "U= ser Agent" or similar Alternate Solution: * Make the Data Provider ID and Provider ID Series Conditional (opt= ional where provided by end-user device or user agent, otherwise required) * Add a value to the Type of Data Provider to read as "End User" "U= ser Agent" or similar to provide some context to the reader of the XML docu= ment. Thanks, Matt. From: Matt Serra Sent: Monday, May 11, 2015 11:24 AM To: ecrit@ietf.org Subject: Request for clarification: Dave Provider ID / Data Provider ID Ser= ies Usage (and Type of Data Provider) Group: In the Additional Call Data draft, the Data Provider ID and Data Provider I= D Series fields within the Data Provider Information Block are shown as Req= uired. In addition to coming from a Service or Access provider, the Additional Cal= l Data can also be provided by the device or user agent. In the case of the Device or User Agent, how should these blocks be populat= ed? The device or UA would not have a NENA or EENA assigned Data Provider = ID. While the spec allow for a "domain" to be used as a Provider ID, the d= omain alone would not uniquely identify the device or User agent. That lan= guage seems to exist to accommodate Service and Access Network providers. So - it seems like we should EITHER provide guidance on how to populate the= se fields in this case (perhaps populate the Data Provider ID with From URI= or PAI? And Data Provider ID Series with "domain" or maybe "URI"?!?!) OR = make these fields optional where provided by a device or user agent and all= ow the From URI/PAI in the INVITE to speak for themselves? This also has ramifications on "Type of Data Provider" as well. There shou= ld be "Device" and "User Agent" value(s) I'd think. Thanks, [rave_email_signature] Matthew A. Serra, ENP Sr. Director, Product Management Mobile: 201.245.1557 mserra@ravemobilesafety.com --_000_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have not seen any co= mment on this, so I’ll try to bring the issue into sharper focus.

 

I’d appreciate k= nowing if there is support for the Preferred Solution or Alternate Solution= I outline below (or if you have better idea).

 

Problem:=

·         Within the Dat= a Provider Block, Data Provider ID and Provider ID Series are required fiel= ds.

·         Per the DRAFT,= there are cases where an entity providing the Data Provider Block would no= t be able to fill out these required fields as they are defined, which in N= orth America calls for populating a NENA Company ID which an end-user would not have.

·         Examples of en= tities that could not meet this requirement are end-user managed devices or= a user agent used to place an emergency call.

 

Preferred Solution:=

·         Instruct the D= evice or User Agent to populate Data Provider ID with the PAI or From URI f= rom the SIP INVITE

·         Instruct the D= evice or User Agent to populate Data Provider ID Series with ‘End-Use= r’ or a similar string.  Update the Provider ID registry with th= is new value

·         Add a value to= the Type of Data Provider to read as “End User” “User Ag= ent” or similar

 <= /o:p>

Alternate Solution:=

·         Make the Data = Provider ID and Provider ID Series Conditional (optional where provided by = end-user device or user agent, otherwise required)

·         Add a value to= the Type of Data Provider to read as “End User” “User Ag= ent” or similar to provide some context to the reader of the XML docu= ment.

 

Thanks,

 

Matt.

 

From: Matt Ser= ra
Sent: Monday, May 11, 2015 11:24 AM
To: ecrit@ietf.org
Subject: Request for clarification: Dave Provider ID / Data Provider= ID Series Usage (and Type of Data Provider)

 

Group:

 

In the Additional Call Data draft, the Data Provider= ID and Data Provider ID Series fields within the Data Provider Information= Block are shown as Required.

 

In addition to coming from a Service or Access provi= der, the Additional Call Data can also be provided by the device or user ag= ent.

 

In the case of the Device or User Agent, how should = these blocks be populated?  The device or UA would not have a NENA or = EENA assigned Data Provider ID.  While the spec allow for a “dom= ain” to be used as a Provider ID, the domain alone would not uniquely identify the device or User agent.  That language = seems to exist to accommodate Service and Access Network providers.

 

So – it seems like we should EITHER provide gu= idance on how to populate these fields in this case (perhaps populate the D= ata Provider ID with From URI or PAI? And Data Provider ID Series with R= 20;domain” or maybe “URI”?!?!)  OR make these fields optional where provided by a device or user agent and allow the Fro= m URI/PAI in the INVITE to speak for themselves?

 

This also has ramifications on “Type of Data P= rovider” as well.  There should be “Device” and R= 20;User Agent” value(s) I’d think.

 

Thanks,

 

3D"rave_email_signature"

&nbs= p; Matthew A. Serra, ENP
  Sr. Director, P= roduct Management
  Mobile:  201.245.1557
  mserra@ravemobilesafe= ty.com<= /span>

 

 

--_000_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl_-- --_004_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3039; creation-date="Tue, 26 May 2015 22:41:20 GMT"; modification-date="Tue, 26 May 2015 22:41:20 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_ed375d4434db4875baa41a892df4019dDAGN04AS1E7exg7exghostl_-- From nobody Wed May 27 05:06:08 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 846E01ACD0A for ; Wed, 27 May 2015 05:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW4jtml6CiWq for ; Wed, 27 May 2015 05:06:03 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BC71ACE60 for ; Wed, 27 May 2015 05:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=246; q=dns/txt; s=iport; t=1432728329; x=1433937929; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=54I030mubhyXBJYPNhcrJfzbGZw1ZDFpwtyAgdNHuas=; b=gnDAyuCWH7Js18lhQdAfcWvMxaZ0mmvmQuCMgjNlQIxoL5FWh8e1554t KFiFl4wpc5OoKpLvaHQoSG+BqwiMDZQRHDS4GoAsA98fhPtjhb1S0Tq8W +0+L4TqYDILlAQXXhOYiN2bCdXx1Vj63y9g1fES6cuhkhpYYYXK5DV/BB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AXBACJsmVV/4kNJK1cgxBUZMFYCYFZhW6BQzgUAQEBAQEBAYEKhCk6UQE+QicEiEANnAyzewEBAQEBAQQBAQEBAQEBAQEVBJNdgRYFkwiENYZagSmDcYdWij8jYYMXgjWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,505,1427760000"; d="scan'208";a="153734938" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 27 May 2015 12:05:28 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4RC5SpV026780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 27 May 2015 12:05:28 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.191]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 27 May 2015 07:05:28 -0500 From: "Marc Linsner (mlinsner)" To: "ecrit@ietf.org" Thread-Topic: WGLC - draft-ietf-ecrit-held-routing Thread-Index: AQHQmHVrxR16KncLa0eKO22wA4VexA== Date: Wed, 27 May 2015 12:05:27 +0000 Message-ID: <6EB1BAFC-49FC-4D1F-92A2-E01C931FE92B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.98] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ecrit] WGLC - draft-ietf-ecrit-held-routing 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, 27 May 2015 12:06:07 -0000 All, This marks the start of working group last call on this draft. Please revi= ew and send comments to the list by COB, Wednesday June 10th, 2015. https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-02 Thanks, Marc & Roger