From nobody Fri Jul 1 17:12:36 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6112D74C for ; Fri, 1 Jul 2016 17:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POCEZ1Y_UgpY for ; Fri, 1 Jul 2016 17:12:33 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 5DE5D12B01B for ; Fri, 1 Jul 2016 17:12:33 -0700 (PDT) Received: from [10.1.4.132] (unknown [208.77.234.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F0C2D22E255; Fri, 1 Jul 2016 20:12:31 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard Date: Fri, 1 Jul 2016 17:12:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160701235426.24621.84539.idtracker@ietfa.amsl.com> To: dispatch@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Carsten Bormann Subject: [dispatch] OID Tags for CBOR, and CBOR update New Version Notification for draft-bormann-cbor-tags-oid-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 00:12:35 -0000 Greetings DISPATCH: Wanted to let folks know that Carsten and I have posted = draft-bormann-cbor-tags-oid-03, which updates CBOR to support Object = Identifiers and Relative Object Identifiers, along with diagnostic = notation. It also has some semantic changes and corrections to tagged = items in CBOR, that escaped review in RFC 7049. (There are no changes to = the =E2=80=9Ccore=E2=80=9D features of CBOR on the wire.) Appendix A = lists the changes. Since this is DISPATCH, I guess the question is: where does it go from = here? Thanks. (Note: Carsten and I discussed the changes in this draft compared to = -02; however, I am the author of most of the content. Therefore any = controversies in the details of the draft are probably my responsibility = rather than his. A future draft update may mellow subsequent issues = out.) Regards, Sean > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-bormann-cbor-tags-oid-03.txt > Date: July 1, 2016 at 4:54:26 PM PDT >=20 A new version of I-D, draft-bormann-cbor-tags-oid-03.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-bormann-cbor-tags-oid Revision: 03 Title: Concise Binary Object Representation (CBOR) Tags for = ASN.1 Object Identifiers, and Omnibus Corrections and Techniques Document date: 2016-06-30 Group: Individual Submission Pages: 29 URL: = https://www.ietf.org/internet-drafts/draft-bormann-cbor-tags-oid-03.txt Status: = https://datatracker.ietf.org/doc/draft-bormann-cbor-tags-oid/ Htmlized: = https://tools.ietf.org/html/draft-bormann-cbor-tags-oid-03 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-cbor-tags-oid-03 Abstract: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document makes use of this extensibility to define CBOR tags <> and <> [values TBD] for ASN.1 object identifiers. It is intended as the reference document for the IANA registration of the CBOR tags so defined. This document also provides other corrections and improvements to CBOR. From nobody Fri Jul 1 23:24:32 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0492812D0D1 for ; Fri, 1 Jul 2016 23:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D9ceTR8vcJP for ; Fri, 1 Jul 2016 23:24:29 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 96C6412D0B8 for ; Fri, 1 Jul 2016 23:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id u626OP9v017777 for ; Sat, 2 Jul 2016 08:24:25 +0200 (CEST) Received: from nar.localdomain.mail (xdsl-213-196-208-161.netcologne.de [213.196.208.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3rhNXn0PFPzDgc2; Sat, 2 Jul 2016 08:24:25 +0200 (CEST) Date: Sat, 2 Jul 2016 08:24:27 +0200 From: Carsten Bormann To: dispatch@ietf.org Message-ID: In-Reply-To: References: <20160701235426.24621.84539.idtracker@ietfa.amsl.com> X-Mailer: Airmail (367) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="57775e20_32da118b_1e10" Archived-At: Subject: Re: [dispatch] OID Tags for CBOR, and CBOR update New Version Notification for draft-bormann-cbor-tags-oid-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 06:24:31 -0000 --57775e20_32da118b_1e10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Whoa. This is what you get for letting a co-author charge ahead on a draft with= out having time for review. This document also provides other=C2=A0 corrections and improvements to CBOR.=C2=A0 =46or the record, I don=E2=80=99t believe CBOR needs =E2=80=9Ccorrections= and improvements=E2=80=9D. =C2=A0At all. (I still have to read the rest of the new text in the document.) Gr=C3=BC=C3=9Fe, Carsten --57775e20_32da118b_1e10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

 

Ekr

 

MCPTT uses RFC 5373 for auto answer t= riggering and is what enables the feature.

 

That RFC describes in detail the secu= rity/privacy concerns with auto answering and the “bug my phone”= ; attack.

 

The ambient listening mode is for fir= st responders such as police and fire fighters in situations when they are = injured etc.

 

This mode would not be enabled in com= mercial applications.

 

Andrew

 

From: dispatch [mailto:dispatch-boun= ces@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Monday, July 18, 2016 11:00 AM
To: Eric Rescorla <ekr@rtfm.com>
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-0= 1

 

MC is for Mission Critical communications, not for c= ommercial use. We would never expect this from a consumer UE. 

Martin C Dolly

Lead Member of Technical Staff

Core & Government/Regulatory Standards 

AT&T

Cell: 609-903-3360


On Jul 18, 2016, at 10:47 AM, Eric Rescorla <ekr@rtfm.com> wrote:

 

 

On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley <= worley@ariadne.com<= /a>> wrote:

Eric Rescorla <ek= r@rtfm.com> writes:
> One of the "features" that this claims to be enable is:
> "Ambient Listening", which seems to be having the device sta= rt recording
> the environment without user consent or indication. This seems like an=
> anti-feature, especially in consumer devices.

As far as I can tell, "Ambient Listening" is a feature of MCPTT, = and
while the work in draft-holmberg-dispatch-mcptt-rp-namespace is needed
by MCPTT, the draft is not sufficient to enable "Ambient Listening&quo= t;.
The only argument I can see against proceeding with the draft is if we
wanted to reject the draft specifically to prevent MCPTT from being
implemented because we didn't like the "Ambient Listening" featur= e of
MCPTT.

 

Yes, that's what I'm suggesting.

 

 

And it does appear that 3GPP is aware of the privacy= implications of
"Ambient Listening":

   MCPTT is primarily targeting to provide a professional Push To= Talk
   service to e.g., public safety, transport companies, utilities= or
   industrial and nuclear plants.  In addition to this a com= mercial PTT
   service for non-professional use (e.g., groups of people on ho= liday)
   may be delivered through an MCPTT system.  Based on their= operational
   model, the performance and MCPTT features in use vary per user=
   organization, where functionality which is more mission critic= al
   specific (e.g., Ambient Listening and Imminent Peril Call) mig= ht not
   be available to commercial customers.

 

I found this section fairly unclear as to when these= features would be allowed.

 

-Ekr

 


Dale

 

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

--_000_BBF5DDFE515C3946BC18D733B20DAD233A747141XMB122CNCrimnet_-- From nobody Mon Jul 18 10:37:09 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F9D12DB1D for ; Mon, 18 Jul 2016 10:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAPPWB7SA6uT for ; Mon, 18 Jul 2016 10:37:05 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 8DC9E12D126 for ; Mon, 18 Jul 2016 10:37:03 -0700 (PDT) Received: from dhcp-b27d.meeting.ietf.org (dhcp-b27d.meeting.ietf.org [31.133.178.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 4740C428B; Mon, 18 Jul 2016 19:36:59 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_937E8EEE-AAFC-4F90-8EA3-3723855B53DD" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 18 Jul 2016 19:36:56 +0200 Message-Id: References: <87oa5vnia0.fsf@hobgoblin.ariadne.com> <77386A7F-638A-44D2-ABE4-9D84EF0E65F8@att.com> To: Andrew Allen X-Mailer: Apple Mail (2.3124) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 17:37:08 -0000 --Apple-Mail=_937E8EEE-AAFC-4F90-8EA3-3723855B53DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Jul 2016, at 18:59, Andrew Allen wrote: >=20 > =20 > Ekr > =20 > MCPTT uses RFC 5373 for auto answer triggering and is what enables the = feature. > =20 > That RFC describes in detail the security/privacy concerns with auto = answering and the =E2=80=9Cbug my phone=E2=80=9D attack. > =20 > The ambient listening mode is for first responders such as police and = fire fighters in situations when they are injured etc. > =20 > This mode would not be enabled in commercial applications. How can you be sure that no one will find any use case for that mode = outside blue light areas? /O > =20 > Andrew > =20 > From: dispatch [mailto:dispatch-bounces@ietf.org = ] On Behalf Of DOLLY, MARTIN C > Sent: Monday, July 18, 2016 11:00 AM > To: Eric Rescorla > > Cc: DISPATCH > > Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 > =20 > MC is for Mission Critical communications, not for commercial use. We = would never expect this from a consumer UE.=20 >=20 > Martin C Dolly=20 > Lead Member of Technical Staff > Core & Government/Regulatory Standards=20 > AT&T > Cell: 609-903-3360 > Email: md3135@att.com >=20 > On Jul 18, 2016, at 10:47 AM, Eric Rescorla > wrote: >=20 > =20 > =20 > On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley > wrote: > Eric Rescorla > writes: > > One of the "features" that this claims to be enable is: > > "Ambient Listening", which seems to be having the device start = recording > > the environment without user consent or indication. This seems like = an > > anti-feature, especially in consumer devices. >=20 > As far as I can tell, "Ambient Listening" is a feature of MCPTT, and > while the work in draft-holmberg-dispatch-mcptt-rp-namespace is needed > by MCPTT, the draft is not sufficient to enable "Ambient Listening". > The only argument I can see against proceeding with the draft is if we > wanted to reject the draft specifically to prevent MCPTT from being > implemented because we didn't like the "Ambient Listening" feature of > MCPTT. > =20 > Yes, that's what I'm suggesting. > =20 > =20 > And it does appear that 3GPP is aware of the privacy implications of > "Ambient Listening": >=20 > MCPTT is primarily targeting to provide a professional Push To Talk > service to e.g., public safety, transport companies, utilities or > industrial and nuclear plants. In addition to this a commercial = PTT > service for non-professional use (e.g., groups of people on = holiday) > may be delivered through an MCPTT system. Based on their = operational > model, the performance and MCPTT features in use vary per user > organization, where functionality which is more mission critical > specific (e.g., Ambient Listening and Imminent Peril Call) might = not > be available to commercial customers. > =20 > I found this section fairly unclear as to when these features would be = allowed. > =20 > -Ekr > =20 >=20 > Dale > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = __________________________= _____________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_937E8EEE-AAFC-4F90-8EA3-3723855B53DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 18 Jul 2016, at 18:59, Andrew Allen <aallen@blackberry.com> wrote:

 
Ekr
 
MCPTT uses RFC 5373 for = auto answer triggering and is what enables the feature.
 
That RFC describes in = detail the security/privacy concerns with auto answering and the =E2=80=9C= bug my phone=E2=80=9D attack.
 
The ambient listening = mode is for first responders such as police and fire fighters in = situations when they are injured etc.
 
This mode would not be = enabled in commercial = applications.
How can you be sure = that no one will find any use case for that mode outside blue light = areas?

/O
 
Andrew
 
From: dispatch = [mailto:dispatch-bounces@ietf.org] On Behalf = Of DOLLY, MARTIN = C
Sent: Monday, July 18, 2016 11:00 = AM
To: Eric Rescorla <ekr@rtfm.com>
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] = draft-holmberg-dispatch-mcptt-rp-namespace-01
 
MC is for Mission Critical = communications, not for commercial use. We would never expect this from = a consumer UE. 

Martin C Dolly 
Lead Member of Technical Staff
Core & Government/Regulatory Standards 
AT&T
Cell: 609-903-3360


On Jul 18, 2016, at 10:47 AM, Eric = Rescorla <ekr@rtfm.com> wrote:

 
 
On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley <worley@ariadne.com>= wrote:
Eric = Rescorla <ekr@rtfm.com> writes:
> One of the "features" that this claims to be enable = is:
> "Ambient Listening", which seems to be having the = device start recording
> the environment without user = consent or indication. This seems like an
> = anti-feature, especially in consumer devices.

As far as I can tell, "Ambient Listening" is a feature of = MCPTT, and
while the work in = draft-holmberg-dispatch-mcptt-rp-namespace is needed
by = MCPTT, the draft is not sufficient to enable "Ambient Listening".
The only argument I can see against proceeding with the draft = is if we
wanted to reject the draft specifically to = prevent MCPTT from being
implemented because we didn't = like the "Ambient Listening" feature of
MCPTT.
 
Yes, that's what I'm = suggesting.
 
 
And it does appear that 3GPP is aware of the privacy = implications of
"Ambient Listening":

   MCPTT is primarily targeting to provide a = professional Push To Talk
   service to e.g., = public safety, transport companies, utilities or
  =  industrial and nuclear plants.  In addition to this a = commercial PTT
   service for non-professional = use (e.g., groups of people on holiday)
   may = be delivered through an MCPTT system.  Based on their = operational
   model, the performance and MCPTT = features in use vary per user
   organization, = where functionality which is more mission critical
  =  specific (e.g., Ambient Listening and Imminent Peril Call) might = not
   be available to commercial customers.
 
I found this section = fairly unclear as to when these features would be allowed.
 
-Ekr
 

Dale
 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_937E8EEE-AAFC-4F90-8EA3-3723855B53DD-- From nobody Mon Jul 18 10:42:20 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C57912DB34 for ; Mon, 18 Jul 2016 10:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egtATzI6JwRx for ; Mon, 18 Jul 2016 10:42:16 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 3B1E812DB2A for ; Mon, 18 Jul 2016 10:42:16 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-03v.sys.comcast.net with SMTP id PCYHbqAvP8GkCPCYZbv1u6; Mon, 18 Jul 2016 17:42:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id PCYYb0o7An4ytPCYYbWLch; Mon, 18 Jul 2016 17:42:15 +0000 To: dispatch@ietf.org References: <87oa5vnia0.fsf@hobgoblin.ariadne.com> <77386A7F-638A-44D2-ABE4-9D84EF0E65F8@att.com> From: Paul Kyzivat Message-ID: Date: Mon, 18 Jul 2016 13:42:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFVt1t9yKMfbluFVdXmJS6iwaoU3ssviMqfBQX6plO40P8gOM/7JeIJVtkY7cZt76i70Fb0iFuQ6UJUbtwlYvPuFR7hF6Teop8GwWrocipiE9MRrpyPh 3a/7I09gOrMxPb1QQS5VhtAg4TZn+OSaWutf2dHahUZ6jSkNQLCHiWUKNATQqd+s4O86jnMAGvetug== Archived-At: Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 17:42:18 -0000 The key question to answer is: How can a *user* know it won't be enabled on his device? Thanks, Paul On 7/18/16 1:36 PM, Olle E. Johansson wrote: > >> On 18 Jul 2016, at 18:59, Andrew Allen > > wrote: >> >> >> Ekr >> >> MCPTT uses RFC 5373 for auto answer triggering and is what enables the >> feature. >> >> That RFC describes in detail the security/privacy concerns with auto >> answering and the bug my phone attack. >> >> The ambient listening mode is for first responders such as police and >> fire fighters in situations when they are injured etc. >> >> This mode would not be enabled in commercial applications. > How can you be sure that no one will find any use case for that mode > outside blue light areas? > > /O >> >> Andrew >> >> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf >> Of *DOLLY, MARTIN C >> *Sent:* Monday, July 18, 2016 11:00 AM >> *To:* Eric Rescorla > >> *Cc:* DISPATCH > >> *Subject:* Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 >> >> MC is for Mission Critical communications, not for commercial use. We >> would never expect this from a consumer UE. >> >> Martin C Dolly >> Lead Member of Technical Staff >> Core & Government/Regulatory Standards >> AT&T >> Cell: 609-903-3360 >> Email: md3135@att.com >> >> >> On Jul 18, 2016, at 10:47 AM, Eric Rescorla > > wrote: >> >> >> >> On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley >> > wrote: >> >> Eric Rescorla > writes: >> > One of the "features" that this claims to be enable is: >> > "Ambient Listening", which seems to be having the device >> start recording >> > the environment without user consent or indication. This >> seems like an >> > anti-feature, especially in consumer devices. >> >> As far as I can tell, "Ambient Listening" is a feature of >> MCPTT, and >> while the work in draft-holmberg-dispatch-mcptt-rp-namespace >> is needed >> by MCPTT, the draft is not sufficient to enable "Ambient >> Listening". >> The only argument I can see against proceeding with the draft >> is if we >> wanted to reject the draft specifically to prevent MCPTT from >> being >> implemented because we didn't like the "Ambient Listening" >> feature of >> MCPTT. >> >> >> Yes, that's what I'm suggesting. >> >> >> >> And it does appear that 3GPP is aware of the privacy >> implications of >> "Ambient Listening": >> >> MCPTT is primarily targeting to provide a professional Push >> To Talk >> service to e.g., public safety, transport companies, >> utilities or >> industrial and nuclear plants. In addition to this a >> commercial PTT >> service for non-professional use (e.g., groups of people on >> holiday) >> may be delivered through an MCPTT system. Based on their >> operational >> model, the performance and MCPTT features in use vary per user >> organization, where functionality which is more mission >> critical >> specific (e.g., Ambient Listening and Imminent Peril Call) >> might not >> be available to commercial customers. >> >> >> I found this section fairly unclear as to when these features >> would be allowed. >> >> -Ekr >> >> >> >> Dale >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Jul 18 11:00:26 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731C512D0A8 for ; Mon, 18 Jul 2016 11:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTdtWtrHjf-J for ; Mon, 18 Jul 2016 11:00:23 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 8819812B00C for ; Mon, 18 Jul 2016 11:00:23 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u6IHxAdu007539; Mon, 18 Jul 2016 14:00:22 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2493av18bv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Jul 2016 14:00:21 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6II0J4J005368; Mon, 18 Jul 2016 14:00:20 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6II0C26004966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Jul 2016 14:00:13 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Mon, 18 Jul 2016 17:59:54 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.245]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 13:59:53 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat Thread-Topic: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 Thread-Index: AQHR4QLz9e1LpxidHUOyroBBq7bubKAef50A///IcFCAAGR8gIAACnQAgAABewD//8Hh8Q== Date: Mon, 18 Jul 2016 17:59:53 +0000 Message-ID: <6B7396D8-A71A-4FC5-917C-BC8FE33F4C8F@att.com> References: <87oa5vnia0.fsf@hobgoblin.ariadne.com> <77386A7F-638A-44D2-ABE4-9D84EF0E65F8@att.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607180198 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:00:25 -0000 Cannot occur.=20 Martin C Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards=20 AT&T Cell: 609-903-3360 Email: md3135@att.com > On Jul 18, 2016, at 1:42 PM, Paul Kyzivat wrote: >=20 > The key question to answer is: How can a *user* know it won't be enabled = on his device? >=20 > Thanks, > Paul >=20 >> On 7/18/16 1:36 PM, Olle E. Johansson wrote: >>=20 >>> On 18 Jul 2016, at 18:59, Andrew Allen >> > wrote: >>>=20 >>>=20 >>> Ekr >>>=20 >>> MCPTT uses RFC 5373 for auto answer triggering and is what enables the >>> feature. >>>=20 >>> That RFC describes in detail the security/privacy concerns with auto >>> answering and the =93bug my phone=94 attack. >>>=20 >>> The ambient listening mode is for first responders such as police and >>> fire fighters in situations when they are injured etc. >>>=20 >>> This mode would not be enabled in commercial applications. >> How can you be sure that no one will find any use case for that mode >> outside blue light areas? >>=20 >> /O >>>=20 >>> Andrew >>>=20 >>> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf >>> Of *DOLLY, MARTIN C >>> *Sent:* Monday, July 18, 2016 11:00 AM >>> *To:* Eric Rescorla > >>> *Cc:* DISPATCH > >>> *Subject:* Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 >>>=20 >>> MC is for Mission Critical communications, not for commercial use. We >>> would never expect this from a consumer UE. >>>=20 >>> Martin C Dolly >>> Lead Member of Technical Staff >>> Core & Government/Regulatory Standards >>> AT&T >>> Cell: 609-903-3360 >>> Email: md3135@att.com >>>=20 >>>=20 >>> On Jul 18, 2016, at 10:47 AM, Eric Rescorla >> > wrote: >>>=20 >>>=20 >>>=20 >>> On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley >>> > wrote: >>>=20 >>> Eric Rescorla > writes: >>> > One of the "features" that this claims to be enable is: >>> > "Ambient Listening", which seems to be having the device >>> start recording >>> > the environment without user consent or indication. This >>> seems like an >>> > anti-feature, especially in consumer devices. >>>=20 >>> As far as I can tell, "Ambient Listening" is a feature of >>> MCPTT, and >>> while the work in draft-holmberg-dispatch-mcptt-rp-namespace >>> is needed >>> by MCPTT, the draft is not sufficient to enable "Ambient >>> Listening". >>> The only argument I can see against proceeding with the draft >>> is if we >>> wanted to reject the draft specifically to prevent MCPTT from >>> being >>> implemented because we didn't like the "Ambient Listening" >>> feature of >>> MCPTT. >>>=20 >>>=20 >>> Yes, that's what I'm suggesting. >>>=20 >>>=20 >>>=20 >>> And it does appear that 3GPP is aware of the privacy >>> implications of >>> "Ambient Listening": >>>=20 >>> MCPTT is primarily targeting to provide a professional Push >>> To Talk >>> service to e.g., public safety, transport companies, >>> utilities or >>> industrial and nuclear plants. In addition to this a >>> commercial PTT >>> service for non-professional use (e.g., groups of people on >>> holiday) >>> may be delivered through an MCPTT system. Based on their >>> operational >>> model, the performance and MCPTT features in use vary per use= r >>> organization, where functionality which is more mission >>> critical >>> specific (e.g., Ambient Listening and Imminent Peril Call) >>> might not >>> be available to commercial customers. >>>=20 >>>=20 >>> I found this section fairly unclear as to when these features >>> would be allowed. >>>=20 >>> -Ekr >>>=20 >>>=20 >>>=20 >>> Dale >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Jul 18 11:07:19 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683B812DB3C for ; Mon, 18 Jul 2016 11:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dLotVwT1AVf for ; Mon, 18 Jul 2016 11:07:13 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 B62D512DB36 for ; Mon, 18 Jul 2016 11:07:12 -0700 (PDT) Received: from dhcp-b27d.meeting.ietf.org (dhcp-b27d.meeting.ietf.org [31.133.178.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 82C91428B; Mon, 18 Jul 2016 20:07:08 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <6B7396D8-A71A-4FC5-917C-BC8FE33F4C8F@att.com> Date: Mon, 18 Jul 2016 20:07:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18106252-578D-4FF8-ABD1-2DA73188CD04@edvina.net> References: <87oa5vnia0.fsf@hobgoblin.ariadne.com> <77386A7F-638A-44D2-ABE4-9D84EF0E65F8@att.com> <6B7396D8-A71A-4FC5-917C-BC8FE33F4C8F@att.com> To: "DOLLY, MARTIN C" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:07:15 -0000 > On 18 Jul 2016, at 19:59, DOLLY, MARTIN C wrote: >=20 > Cannot occur.=20 Does the protocol prohibit that? How? For all usages in all = implementations? /O >=20 > Martin C Dolly > Lead Member of Technical Staff > Core & Government/Regulatory Standards=20 > AT&T > Cell: 609-903-3360 > Email: md3135@att.com >=20 >> On Jul 18, 2016, at 1:42 PM, Paul Kyzivat = wrote: >>=20 >> The key question to answer is: How can a *user* know it won't be = enabled on his device? >>=20 >> Thanks, >> Paul >>=20 >>> On 7/18/16 1:36 PM, Olle E. Johansson wrote: >>>=20 >>>> On 18 Jul 2016, at 18:59, Andrew Allen >>> > wrote: >>>>=20 >>>>=20 >>>> Ekr >>>>=20 >>>> MCPTT uses RFC 5373 for auto answer triggering and is what enables = the >>>> feature. >>>>=20 >>>> That RFC describes in detail the security/privacy concerns with = auto >>>> answering and the =93bug my phone=94 attack. >>>>=20 >>>> The ambient listening mode is for first responders such as police = and >>>> fire fighters in situations when they are injured etc. >>>>=20 >>>> This mode would not be enabled in commercial applications. >>> How can you be sure that no one will find any use case for that mode >>> outside blue light areas? >>>=20 >>> /O >>>>=20 >>>> Andrew >>>>=20 >>>> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf >>>> Of *DOLLY, MARTIN C >>>> *Sent:* Monday, July 18, 2016 11:00 AM >>>> *To:* Eric Rescorla > >>>> *Cc:* DISPATCH > >>>> *Subject:* Re: [dispatch] = draft-holmberg-dispatch-mcptt-rp-namespace-01 >>>>=20 >>>> MC is for Mission Critical communications, not for commercial use. = We >>>> would never expect this from a consumer UE. >>>>=20 >>>> Martin C Dolly >>>> Lead Member of Technical Staff >>>> Core & Government/Regulatory Standards >>>> AT&T >>>> Cell: 609-903-3360 >>>> Email: md3135@att.com >>>>=20 >>>>=20 >>>> On Jul 18, 2016, at 10:47 AM, Eric Rescorla >>> > wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley >>>> > wrote: >>>>=20 >>>> Eric Rescorla > writes: >>>>> One of the "features" that this claims to be enable is: >>>>> "Ambient Listening", which seems to be having the device >>>> start recording >>>>> the environment without user consent or indication. This >>>> seems like an >>>>> anti-feature, especially in consumer devices. >>>>=20 >>>> As far as I can tell, "Ambient Listening" is a feature of >>>> MCPTT, and >>>> while the work in draft-holmberg-dispatch-mcptt-rp-namespace >>>> is needed >>>> by MCPTT, the draft is not sufficient to enable "Ambient >>>> Listening". >>>> The only argument I can see against proceeding with the draft >>>> is if we >>>> wanted to reject the draft specifically to prevent MCPTT from >>>> being >>>> implemented because we didn't like the "Ambient Listening" >>>> feature of >>>> MCPTT. >>>>=20 >>>>=20 >>>> Yes, that's what I'm suggesting. >>>>=20 >>>>=20 >>>>=20 >>>> And it does appear that 3GPP is aware of the privacy >>>> implications of >>>> "Ambient Listening": >>>>=20 >>>> MCPTT is primarily targeting to provide a professional = Push >>>> To Talk >>>> service to e.g., public safety, transport companies, >>>> utilities or >>>> industrial and nuclear plants. In addition to this a >>>> commercial PTT >>>> service for non-professional use (e.g., groups of people = on >>>> holiday) >>>> may be delivered through an MCPTT system. Based on their >>>> operational >>>> model, the performance and MCPTT features in use vary per = user >>>> organization, where functionality which is more mission >>>> critical >>>> specific (e.g., Ambient Listening and Imminent Peril Call) >>>> might not >>>> be available to commercial customers. >>>>=20 >>>>=20 >>>> I found this section fairly unclear as to when these features >>>> would be allowed. >>>>=20 >>>> -Ekr >>>>=20 >>>>=20 >>>>=20 >>>> Dale >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Jul 18 11:22:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8625012B036 for ; Mon, 18 Jul 2016 11:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YKN4G9M-SKu for ; Mon, 18 Jul 2016 11:22:43 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84A112B016 for ; Mon, 18 Jul 2016 11:22:42 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-e7-578d1e70e74b Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 68.2D.18043.07E1D875; Mon, 18 Jul 2016 20:22:40 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.208]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 20:22:40 +0200 From: Christer Holmberg To: "Olle E. Johansson" , "DOLLY, MARTIN C" Thread-Topic: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 Thread-Index: AQHR4P724HLgfDzDbUSUlYfE+esJjqAeGw8AgAALfYCAACFvgIAACnUAgAABewCAAATugIAAAgQAgAAju6A= Date: Mon, 18 Jul 2016 18:22:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476D2936@ESESSMB209.ericsson.se> References: <87oa5vnia0.fsf@hobgoblin.ariadne.com> <77386A7F-638A-44D2-ABE4-9D84EF0E65F8@att.com> <6B7396D8-A71A-4FC5-917C-BC8FE33F4C8F@att.com> <18106252-578D-4FF8-ABD1-2DA73188CD04@edvina.net> In-Reply-To: <18106252-578D-4FF8-ABD1-2DA73188CD04@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7jW6BXG+4wY1mBYulkxawWhx68JTd 4uXqQ8wOzB4v++cwekxbu5LVY8mSn0wBzFFcNimpOZllqUX6dglcGT27L7AVLNKv+P/sAnsD 4y3VLkZODgkBE4mFW7rYIGwxiQv31gPZXBxCAkcYJRofr4VyljBKLJrYzNLFyMHBJmAh0f1P G6RBRMBHornjCDuIzSygLfH/+jpGkBJhAVeJjgdKIKaIgJtE+1QViOokiaULHrKA2CwCqhJf V61kBrF5BXwlHt1vhNr0n1niwLtdrCAJTgE7icb/b8DGMwLd9v3UGiaIVeISt57MZ4K4WUBi yZ7zzBC2qMTLx/9YIWwliUW3P0PV60gs2P2JDebMZQtfQy0WlDg58wnLBEaxWUjGzkLSMgtJ yywkLQsYWVYxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBEbUwS2/rXYwHnzueIhRgINRiYdX QbI3XIg1say4MvcQowQHs5II7xVpoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC6Ykl qdmpqQWpRTBZJg5OqQZGq/gJzzPz/rzj8lxpq2A197Gtb0aX9Bv+t7V7OOIXOl38/z0qKIat yvDM1dXX7nOyL7GY5BAz0S8rt31JiYmxcuTdLY8v//rzw9ok6sPa5I+/HV4uuHda72Loh46N LYW/X72P057Tv+50gZ5buUjwarcNi4/d+pbP4GCg+OWWSlzWsptWq+JalFiKMxINtZiLihMB WQjOoaQCAAA= Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:22:45 -0000 Hi, The person to whom you make the auto-answer call needs to authorize you to = make such calls to that person.=20 The service does NOT allow one to make auto-answer calls to "anyone". Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Olle E. Joha= nsson Sent: 18 July 2016 21:07 To: DOLLY, MARTIN C Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 > On 18 Jul 2016, at 19:59, DOLLY, MARTIN C wrote: >=20 > Cannot occur.=20 Does the protocol prohibit that? How? For all usages in all implementations= ? /O >=20 > Martin C Dolly > Lead Member of Technical Staff > Core & Government/Regulatory Standards AT&T > Cell: 609-903-3360 > Email: md3135@att.com >=20 >> On Jul 18, 2016, at 1:42 PM, Paul Kyzivat wrote: >>=20 >> The key question to answer is: How can a *user* know it won't be enabled= on his device? >>=20 >> Thanks, >> Paul >>=20 >>> On 7/18/16 1:36 PM, Olle E. Johansson wrote: >>>=20 >>>> On 18 Jul 2016, at 18:59, Andrew Allen >>> > wrote: >>>>=20 >>>>=20 >>>> Ekr >>>>=20 >>>> MCPTT uses RFC 5373 for auto answer triggering and is what enables=20 >>>> the feature. >>>>=20 >>>> That RFC describes in detail the security/privacy concerns with=20 >>>> auto answering and the "bug my phone" attack. >>>>=20 >>>> The ambient listening mode is for first responders such as police=20 >>>> and fire fighters in situations when they are injured etc. >>>>=20 >>>> This mode would not be enabled in commercial applications. >>> How can you be sure that no one will find any use case for that mode=20 >>> outside blue light areas? >>>=20 >>> /O >>>>=20 >>>> Andrew >>>>=20 >>>> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of=20 >>>> *DOLLY, MARTIN C >>>> *Sent:* Monday, July 18, 2016 11:00 AM >>>> *To:* Eric Rescorla > >>>> *Cc:* DISPATCH > >>>> *Subject:* Re: [dispatch]=20 >>>> draft-holmberg-dispatch-mcptt-rp-namespace-01 >>>>=20 >>>> MC is for Mission Critical communications, not for commercial use.=20 >>>> We would never expect this from a consumer UE. >>>>=20 >>>> Martin C Dolly >>>> Lead Member of Technical Staff >>>> Core & Government/Regulatory Standards AT&T >>>> Cell: 609-903-3360 >>>> Email: md3135@att.com >>>>=20 >>>>=20 >>>> On Jul 18, 2016, at 10:47 AM, Eric Rescorla >>> > wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley >>>> > wrote: >>>>=20 >>>> Eric Rescorla > writes: >>>>> One of the "features" that this claims to be enable is: >>>>> "Ambient Listening", which seems to be having the device >>>> start recording >>>>> the environment without user consent or indication. This >>>> seems like an >>>>> anti-feature, especially in consumer devices. >>>>=20 >>>> As far as I can tell, "Ambient Listening" is a feature of >>>> MCPTT, and >>>> while the work in draft-holmberg-dispatch-mcptt-rp-namespace >>>> is needed >>>> by MCPTT, the draft is not sufficient to enable "Ambient >>>> Listening". >>>> The only argument I can see against proceeding with the draft >>>> is if we >>>> wanted to reject the draft specifically to prevent MCPTT from >>>> being >>>> implemented because we didn't like the "Ambient Listening" >>>> feature of >>>> MCPTT. >>>>=20 >>>>=20 >>>> Yes, that's what I'm suggesting. >>>>=20 >>>>=20 >>>>=20 >>>> And it does appear that 3GPP is aware of the privacy >>>> implications of >>>> "Ambient Listening": >>>>=20 >>>> MCPTT is primarily targeting to provide a professional Push >>>> To Talk >>>> service to e.g., public safety, transport companies, >>>> utilities or >>>> industrial and nuclear plants. In addition to this a >>>> commercial PTT >>>> service for non-professional use (e.g., groups of people on >>>> holiday) >>>> may be delivered through an MCPTT system. Based on their >>>> operational >>>> model, the performance and MCPTT features in use vary per use= r >>>> organization, where functionality which is more mission >>>> critical >>>> specific (e.g., Ambient Listening and Imminent Peril Call) >>>> might not >>>> be available to commercial customers. >>>>=20 >>>>=20 >>>> I found this section fairly unclear as to when these features >>>> would be allowed. >>>>=20 >>>> -Ekr >>>>=20 >>>>=20 >>>>=20 >>>> Dale >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Jul 18 12:42:41 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F10412B036 for ; Mon, 18 Jul 2016 12:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfRcP-Ujcxw7 for ; Mon, 18 Jul 2016 12:42:38 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id A4B2D127078 for ; Mon, 18 Jul 2016 12:42:37 -0700 (PDT) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 18:23:54 -0400 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Mon, 18 Jul 2016 15:42:36 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Mon, 18 Jul 2016 15:42:35 -0400 From: Andrew Allen To: Christer Holmberg , "Olle E. Johansson" , "DOLLY, MARTIN C" Thread-Topic: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 Thread-Index: AQHR4P72lzwunYT4GUqrLejoiV9k0qAef6UAgAALfID//91wYIAATnQAgAABewCAAATugIAAAgUAgAAEWID//9NH7w== Date: Mon, 18 Jul 2016 19:42:35 +0000 Message-ID: <20160718194228.6570072.36880.24716@blackberry.com> References: <87oa5vnia0.fsf@hobgoblin.ariadne.com> <77386A7F-638A-44D2-ABE4-9D84EF0E65F8@att.com> <6B7396D8-A71A-4FC5-917C-BC8FE33F4C8F@att.com> <18106252-578D-4FF8-ABD1-2DA73188CD04@edvina.net>, <7594FB04B1934943A5C02806D1A2204B476D2936@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476D2936@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 19:42:40 -0000 Totally agree with Christer and as I said all =FDthese concerns are address= ed in RFC 5373 which is the mechanism to get the device to auto answer in t= he first place. Sent from my BlackBerry 10 smartphone. Original Message From: Christer Holmberg Sent: Monday, July 18, 2016 20:23 To: Olle E. Johansson; DOLLY, MARTIN C Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 Hi, The person to whom you make the auto-answer call needs to authorize you to = make such calls to that person. The service does NOT allow one to make auto-answer calls to "anyone". Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Olle E. Joha= nsson Sent: 18 July 2016 21:07 To: DOLLY, MARTIN C Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 > On 18 Jul 2016, at 19:59, DOLLY, MARTIN C wrote: > > Cannot occur. Does the protocol prohibit that? How? For all usages in all implementations= ? /O > > Martin C Dolly > Lead Member of Technical Staff > Core & Government/Regulatory Standards AT&T > Cell: 609-903-3360 > Email: md3135@att.com > >> On Jul 18, 2016, at 1:42 PM, Paul Kyzivat wrote: >> >> The key question to answer is: How can a *user* know it won't be enabled= on his device? >> >> Thanks, >> Paul >> >>> On 7/18/16 1:36 PM, Olle E. Johansson wrote: >>> >>>> On 18 Jul 2016, at 18:59, Andrew Allen >>> > wrote: >>>> >>>> >>>> Ekr >>>> >>>> MCPTT uses RFC 5373 for auto answer triggering and is what enables >>>> the feature. >>>> >>>> That RFC describes in detail the security/privacy concerns with >>>> auto answering and the "bug my phone" attack. >>>> >>>> The ambient listening mode is for first responders such as police >>>> and fire fighters in situations when they are injured etc. >>>> >>>> This mode would not be enabled in commercial applications. >>> How can you be sure that no one will find any use case for that mode >>> outside blue light areas? >>> >>> /O >>>> >>>> Andrew >>>> >>>> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of >>>> *DOLLY, MARTIN C >>>> *Sent:* Monday, July 18, 2016 11:00 AM >>>> *To:* Eric Rescorla > >>>> *Cc:* DISPATCH > >>>> *Subject:* Re: [dispatch] >>>> draft-holmberg-dispatch-mcptt-rp-namespace-01 >>>> >>>> MC is for Mission Critical communications, not for commercial use. >>>> We would never expect this from a consumer UE. >>>> >>>> Martin C Dolly >>>> Lead Member of Technical Staff >>>> Core & Government/Regulatory Standards AT&T >>>> Cell: 609-903-3360 >>>> Email: md3135@att.com >>>> >>>> >>>> On Jul 18, 2016, at 10:47 AM, Eric Rescorla >>> > wrote: >>>> >>>> >>>> >>>> On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley >>>> > wrote: >>>> >>>> Eric Rescorla > writes: >>>>> One of the "features" that this claims to be enable is: >>>>> "Ambient Listening", which seems to be having the device >>>> start recording >>>>> the environment without user consent or indication. This >>>> seems like an >>>>> anti-feature, especially in consumer devices. >>>> >>>> As far as I can tell, "Ambient Listening" is a feature of >>>> MCPTT, and >>>> while the work in draft-holmberg-dispatch-mcptt-rp-namespace >>>> is needed >>>> by MCPTT, the draft is not sufficient to enable "Ambient >>>> Listening". >>>> The only argument I can see against proceeding with the draft >>>> is if we >>>> wanted to reject the draft specifically to prevent MCPTT from >>>> being >>>> implemented because we didn't like the "Ambient Listening" >>>> feature of >>>> MCPTT. >>>> >>>> >>>> Yes, that's what I'm suggesting. >>>> >>>> >>>> >>>> And it does appear that 3GPP is aware of the privacy >>>> implications of >>>> "Ambient Listening": >>>> >>>> MCPTT is primarily targeting to provide a professional Push >>>> To Talk >>>> service to e.g., public safety, transport companies, >>>> utilities or >>>> industrial and nuclear plants. In addition to this a >>>> commercial PTT >>>> service for non-professional use (e.g., groups of people on >>>> holiday) >>>> may be delivered through an MCPTT system. Based on their >>>> operational >>>> model, the performance and MCPTT features in use vary per use= r >>>> organization, where functionality which is more mission >>>> critical >>>> specific (e.g., Ambient Listening and Imminent Peril Call) >>>> might not >>>> be available to commercial customers. >>>> >>>> >>>> I found this section fairly unclear as to when these features >>>> would be allowed. >>>> >>>> -Ekr >>>> >>>> >>>> >>>> Dale >>>> >>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Jul 18 14:59:11 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3712DA9E for ; Mon, 18 Jul 2016 14:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhnbCX0u_lZa for ; Mon, 18 Jul 2016 14:59:09 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 DE2F112DA51 for ; Mon, 18 Jul 2016 14:59:08 -0700 (PDT) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-12v.sys.comcast.net with SMTP id PGXGbp5osxBKTPGZAbUZEz; Mon, 18 Jul 2016 21:59:08 +0000 Received: from hobgoblin.ariadne.com ([173.48.63.26]) by comcast with SMTP id PGX3bMj1l4t7APGX6bKdgR; Mon, 18 Jul 2016 21:57:06 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6ILuvvk010798; Mon, 18 Jul 2016 17:56:57 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6ILuuld010795; Mon, 18 Jul 2016 17:56:56 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Eric Rescorla In-Reply-To: (ekr@rtfm.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 18 Jul 2016 17:56:56 -0400 Message-ID: <87vb02mwyf.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfAPEILl5thUiujXEfRwhlFLSbdeNiKSlJ1Dt4Hn71HNihv/HU+heaI/dV7+/8x1sGgDxqARRqdT7wfSU9SRPHO+HuhwBJqdHB7VZRwvOzk8Tg4WYrFTk c6bw6nZbJwGdOobprI/Z1T/dYRRG6PR/49wtBs2E+ddJfxJUnA7kagp7DpzyH3FNyF8PJU5Pr/pNX4pSGtt5RHPS0G9XslSORQA= Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 21:59:11 -0000 Eric Rescorla writes: > And it does appear that 3GPP is aware of the privacy implications of >> "Ambient Listening": >> >> MCPTT is primarily targeting to provide a professional Push To Talk >> service to e.g., public safety, transport companies, utilities or >> industrial and nuclear plants. In addition to this a commercial PTT >> service for non-professional use (e.g., groups of people on holiday) >> may be delivered through an MCPTT system. Based on their operational >> model, the performance and MCPTT features in use vary per user >> organization, where functionality which is more mission critical >> specific (e.g., Ambient Listening and Imminent Peril Call) might not >> be available to commercial customers. > > I found this section fairly unclear as to when these features would be > allowed. True, but this isn't the document that defines MCPTT. It's useful to be paranoid about "Ambient Listening", but there is no technical solution. Anyone can *already* build a UA that simply answers an incoming call without notifying the user, and that function can be triggered by any element of the INVITE request that is chosen. And no doubt such code is being maliciously inserted into UAs somewhere as we discuss this. The only mitigation is a proper regulatory framework to protect the public, and proper legal enforcement. What the IETF can do to help is ensure that the technical documents clearly state what the regulators need to take into account. It appears that RFC 5373 is where that is done. Dale From nobody Mon Jul 18 15:54:40 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F6D12DB3E for ; Mon, 18 Jul 2016 15:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wr8MGGYX6VP for ; Mon, 18 Jul 2016 15:54:36 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 4E58E12DB6B for ; Mon, 18 Jul 2016 15:54:24 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-01v.sys.comcast.net with SMTP id PHQIbWdnbTaLwPHQdbBrYv; Mon, 18 Jul 2016 22:54:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id PHQcbLvrtCigVPHQcb4oxC; Mon, 18 Jul 2016 22:54:23 +0000 To: dispatch@ietf.org References: <87oa5vnia0.fsf@hobgoblin.ariadne.com> <77386A7F-638A-44D2-ABE4-9D84EF0E65F8@att.com> <6B7396D8-A71A-4FC5-917C-BC8FE33F4C8F@att.com> <18106252-578D-4FF8-ABD1-2DA73188CD04@edvina.net> <7594FB04B1934943A5C02806D1A2204B476D2936@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Mon, 18 Jul 2016 18:54:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476D2936@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfK2OB10fLrEKtOXf8azAS/gKuo1Zh10bSA3PKCk3Y6spkTfdyJpZNJVkICrL9ehptrDkr7MkQaH+sVMiRsFXlbtv+K7W9e3fEdwOrnu2WGBpT1x36EaI Bb1Noe/wjXPoZuAXEYdrjClZ4H3RMm26m1iKhSBkKmQP2oDbXHh6J+wLZzILHc6DMQUggBH4mms7Sw== Archived-At: Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 22:54:38 -0000 On 7/18/16 2:22 PM, Christer Holmberg wrote: > Hi, > > The person to whom you make the auto-answer call needs to authorize you to make such calls to that person. > > The service does NOT allow one to make auto-answer calls to "anyone". And that authorization is performed by the user, in the device? (Not in the network.) And this can't be preconfigured by the SP as part of device provisioning? (At the same time they preinstall all those apps users don't want and can't remove.) Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Olle E. Johansson > Sent: 18 July 2016 21:07 > To: DOLLY, MARTIN C > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 > > >> On 18 Jul 2016, at 19:59, DOLLY, MARTIN C wrote: >> >> Cannot occur. > Does the protocol prohibit that? How? For all usages in all implementations? > > /O >> >> Martin C Dolly >> Lead Member of Technical Staff >> Core & Government/Regulatory Standards AT&T >> Cell: 609-903-3360 >> Email: md3135@att.com >> >>> On Jul 18, 2016, at 1:42 PM, Paul Kyzivat wrote: >>> >>> The key question to answer is: How can a *user* know it won't be enabled on his device? >>> >>> Thanks, >>> Paul >>> >>>> On 7/18/16 1:36 PM, Olle E. Johansson wrote: >>>> >>>>> On 18 Jul 2016, at 18:59, Andrew Allen >>>> > wrote: >>>>> >>>>> >>>>> Ekr >>>>> >>>>> MCPTT uses RFC 5373 for auto answer triggering and is what enables >>>>> the feature. >>>>> >>>>> That RFC describes in detail the security/privacy concerns with >>>>> auto answering and the "bug my phone" attack. >>>>> >>>>> The ambient listening mode is for first responders such as police >>>>> and fire fighters in situations when they are injured etc. >>>>> >>>>> This mode would not be enabled in commercial applications. >>>> How can you be sure that no one will find any use case for that mode >>>> outside blue light areas? >>>> >>>> /O >>>>> >>>>> Andrew >>>>> >>>>> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of >>>>> *DOLLY, MARTIN C >>>>> *Sent:* Monday, July 18, 2016 11:00 AM >>>>> *To:* Eric Rescorla > >>>>> *Cc:* DISPATCH > >>>>> *Subject:* Re: [dispatch] >>>>> draft-holmberg-dispatch-mcptt-rp-namespace-01 >>>>> >>>>> MC is for Mission Critical communications, not for commercial use. >>>>> We would never expect this from a consumer UE. >>>>> >>>>> Martin C Dolly >>>>> Lead Member of Technical Staff >>>>> Core & Government/Regulatory Standards AT&T >>>>> Cell: 609-903-3360 >>>>> Email: md3135@att.com >>>>> >>>>> >>>>> On Jul 18, 2016, at 10:47 AM, Eric Rescorla >>>> > wrote: >>>>> >>>>> >>>>> >>>>> On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley >>>>> > wrote: >>>>> >>>>> Eric Rescorla > writes: >>>>>> One of the "features" that this claims to be enable is: >>>>>> "Ambient Listening", which seems to be having the device >>>>> start recording >>>>>> the environment without user consent or indication. This >>>>> seems like an >>>>>> anti-feature, especially in consumer devices. >>>>> >>>>> As far as I can tell, "Ambient Listening" is a feature of >>>>> MCPTT, and >>>>> while the work in draft-holmberg-dispatch-mcptt-rp-namespace >>>>> is needed >>>>> by MCPTT, the draft is not sufficient to enable "Ambient >>>>> Listening". >>>>> The only argument I can see against proceeding with the draft >>>>> is if we >>>>> wanted to reject the draft specifically to prevent MCPTT from >>>>> being >>>>> implemented because we didn't like the "Ambient Listening" >>>>> feature of >>>>> MCPTT. >>>>> >>>>> >>>>> Yes, that's what I'm suggesting. >>>>> >>>>> >>>>> >>>>> And it does appear that 3GPP is aware of the privacy >>>>> implications of >>>>> "Ambient Listening": >>>>> >>>>> MCPTT is primarily targeting to provide a professional Push >>>>> To Talk >>>>> service to e.g., public safety, transport companies, >>>>> utilities or >>>>> industrial and nuclear plants. In addition to this a >>>>> commercial PTT >>>>> service for non-professional use (e.g., groups of people on >>>>> holiday) >>>>> may be delivered through an MCPTT system. Based on their >>>>> operational >>>>> model, the performance and MCPTT features in use vary per user >>>>> organization, where functionality which is more mission >>>>> critical >>>>> specific (e.g., Ambient Listening and Imminent Peril Call) >>>>> might not >>>>> be available to commercial customers. >>>>> >>>>> >>>>> I found this section fairly unclear as to when these features >>>>> would be allowed. >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> >>>>> Dale >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Jul 18 21:38:04 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBAC12DC5D for ; Mon, 18 Jul 2016 21:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YBkK1kkRyqw for ; Mon, 18 Jul 2016 21:38:01 -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 D002E12DC4E for ; Mon, 18 Jul 2016 21:38:00 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-ab-578daea6e5c0 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F2.72.27088.6AEAD875; Tue, 19 Jul 2016 06:37:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.208]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0294.000; Tue, 19 Jul 2016 06:37:58 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 Thread-Index: AQHR4P724HLgfDzDbUSUlYfE+esJjqAeGw8AgAALfYCAACFvgIAACnUAgAABewCAAATugIAAAgQAgAAju6CAACyIAIAAgBiw Date: Tue, 19 Jul 2016 04:37:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B476D2F16@ESESSMB209.ericsson.se> References: <87oa5vnia0.fsf@hobgoblin.ariadne.com> <77386A7F-638A-44D2-ABE4-9D84EF0E65F8@att.com> <6B7396D8-A71A-4FC5-917C-BC8FE33F4C8F@att.com> <18106252-578D-4FF8-ABD1-2DA73188CD04@edvina.net> <7594FB04B1934943A5C02806D1A2204B476D2936@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7uu6ydb3hBs3/9SyWTlrAarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj5fwfloJfZhVbjm1kbGBs0+li5OCQEDCR uLWGvYuRE8gUk7hwbz0biC0kcIRRoneWRBcjF5C9hFFiz5wORpB6NgELie5/2iA1IgLBEgcP 72QBCQsLuEp0PFACMUUE3CTap6pAVORJfNh5hxXEZhFQlTjSM5cRxOYV8JXYf/wcC8T0nywS J3b3gk3nFHCQuLJOE6SGEeia76fWMIHYzALiEreezGeCuFJAYsme88wQtqjEy8f/WCFsJYkV 2y8xQtTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNocWpx Um66kZFealFmcnFxfp5eXmrJJkZgfBzc8ttgB+PL546HGAU4GJV4eBUke8OFWBPLiitzDzFK cDArifCemQgU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnV wFhzrrwxU6N2zZzdX7dzifpN2JS8l9XtqUHQtnduJ/gzRP3Ft534s+I+47GZu9lXvd7harI1 8i5z4vYQjUjOWva+x383HzyVe33v9IVfLl4OMTspcMAg7VlEy4nFKy7YTtrWd2evYXvnz3+n t1ac3ZQTeE/vuRJf1F4Xk7mxLS2n9OUYr6wVO6GgxFKckWioxVxUnAgAkZcQ3YsCAAA= Archived-At: Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 04:38:03 -0000 Hi, >>> The person to whom you make the auto-answer call needs to authorize=20 >>> you to make such calls to that person. >> >> The service does NOT allow one to make auto-answer calls to "anyone". > > And that authorization is performed by the user, in the device? (Not in t= he network.) And this can't be=20 > preconfigured by the SP as part of device provisioning? (At the same time= they preinstall all those apps=20 > users don't want and can't remove.) Users need to be authorized in order to use the MCPTT service to begin with= (with or without auto-answer). MCPTT is NOT a service that the "average co= nsumer" can just download/preinstall, sign-up for and start using. MCPTT is= a "tool" that can be used by authorized professionals (fire fighters, firs= t responders, etc...) when performing their work. Regards, Christer > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Olle E.=20 > Johansson > Sent: 18 July 2016 21:07 > To: DOLLY, MARTIN C > Cc: dispatch@ietf.org > Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 > > >> On 18 Jul 2016, at 19:59, DOLLY, MARTIN C wrote: >> >> Cannot occur. > Does the protocol prohibit that? How? For all usages in all implementatio= ns? > > /O >> >> Martin C Dolly >> Lead Member of Technical Staff >> Core & Government/Regulatory Standards AT&T >> Cell: 609-903-3360 >> Email: md3135@att.com >> >>> On Jul 18, 2016, at 1:42 PM, Paul Kyzivat wrote= : >>> >>> The key question to answer is: How can a *user* know it won't be enable= d on his device? >>> >>> Thanks, >>> Paul >>> >>>> On 7/18/16 1:36 PM, Olle E. Johansson wrote: >>>> >>>>> On 18 Jul 2016, at 18:59, Andrew Allen >>>> > wrote: >>>>> >>>>> >>>>> Ekr >>>>> >>>>> MCPTT uses RFC 5373 for auto answer triggering and is what enables=20 >>>>> the feature. >>>>> >>>>> That RFC describes in detail the security/privacy concerns with=20 >>>>> auto answering and the "bug my phone" attack. >>>>> >>>>> The ambient listening mode is for first responders such as police=20 >>>>> and fire fighters in situations when they are injured etc. >>>>> >>>>> This mode would not be enabled in commercial applications. >>>> How can you be sure that no one will find any use case for that=20 >>>> mode outside blue light areas? >>>> >>>> /O >>>>> >>>>> Andrew >>>>> >>>>> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of=20 >>>>> *DOLLY, MARTIN C >>>>> *Sent:* Monday, July 18, 2016 11:00 AM >>>>> *To:* Eric Rescorla > >>>>> *Cc:* DISPATCH > >>>>> *Subject:* Re: [dispatch] >>>>> draft-holmberg-dispatch-mcptt-rp-namespace-01 >>>>> >>>>> MC is for Mission Critical communications, not for commercial use. >>>>> We would never expect this from a consumer UE. >>>>> >>>>> Martin C Dolly >>>>> Lead Member of Technical Staff >>>>> Core & Government/Regulatory Standards AT&T >>>>> Cell: 609-903-3360 >>>>> Email: md3135@att.com >>>>> >>>>> >>>>> On Jul 18, 2016, at 10:47 AM, Eric Rescorla >>>> > wrote: >>>>> >>>>> >>>>> >>>>> On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley >>>>> > wrote: >>>>> >>>>> Eric Rescorla > writes: >>>>>> One of the "features" that this claims to be enable is: >>>>>> "Ambient Listening", which seems to be having the device >>>>> start recording >>>>>> the environment without user consent or indication. This >>>>> seems like an >>>>>> anti-feature, especially in consumer devices. >>>>> >>>>> As far as I can tell, "Ambient Listening" is a feature of >>>>> MCPTT, and >>>>> while the work in draft-holmberg-dispatch-mcptt-rp-namespace >>>>> is needed >>>>> by MCPTT, the draft is not sufficient to enable "Ambient >>>>> Listening". >>>>> The only argument I can see against proceeding with the draft >>>>> is if we >>>>> wanted to reject the draft specifically to prevent MCPTT from >>>>> being >>>>> implemented because we didn't like the "Ambient Listening" >>>>> feature of >>>>> MCPTT. >>>>> >>>>> >>>>> Yes, that's what I'm suggesting. >>>>> >>>>> >>>>> >>>>> And it does appear that 3GPP is aware of the privacy >>>>> implications of >>>>> "Ambient Listening": >>>>> >>>>> MCPTT is primarily targeting to provide a professional Push >>>>> To Talk >>>>> service to e.g., public safety, transport companies, >>>>> utilities or >>>>> industrial and nuclear plants. In addition to this a >>>>> commercial PTT >>>>> service for non-professional use (e.g., groups of people on >>>>> holiday) >>>>> may be delivered through an MCPTT system. Based on their >>>>> operational >>>>> model, the performance and MCPTT features in use vary per us= er >>>>> organization, where functionality which is more mission >>>>> critical >>>>> specific (e.g., Ambient Listening and Imminent Peril Call) >>>>> might not >>>>> be available to commercial customers. >>>>> >>>>> >>>>> I found this section fairly unclear as to when these features >>>>> would be allowed. >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> >>>>> Dale >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org =20 >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Jul 19 00:55:33 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAA812D0E0 for ; Tue, 19 Jul 2016 00:55:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=genaker-net.20150623.gappssmtp.com 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 2S8quO4FkF27 for ; Tue, 19 Jul 2016 00:55:23 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 C385E12D151 for ; Tue, 19 Jul 2016 00:55:22 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id f65so129740931wmi.0 for ; Tue, 19 Jul 2016 00:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=genaker-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N+XvcF4QtOJLz9sGY2h4dFBFXbFHHhsBjNpBCshMtw4=; b=xojiwrJMAA1gh78DfKTFWtQJ6+8fBMKO/2hpw8qbbyCfHqEKl7cjQwyNDu4hjUULOZ Ama0eNRmQvrN+muVDKl8jeBsWAkuQh/2pEKCqNLixiTTadOLQmCx4sxG6iGhkSqqVM11 EFR7851usiE3mqRRfBADXafQph9QLAVz/0vjAddgr9/6HmArH7A8w0oQHG4tTSlDxMIk feWko/danBKELycgFigpFVXV71G2epzMNXHe8YQHkDkk5NklwZuAlsa6Eeqxcnmb1054 +/vH9b2xk71gC/yCzgdVNQiIH378TfGhyV2528YntwfYVMnwumsin08swVZK9FnZp58t qdeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N+XvcF4QtOJLz9sGY2h4dFBFXbFHHhsBjNpBCshMtw4=; b=L7dbaJcp4p1/HAgWc8po2NdvR9twwmbIOLClmZCPpHlWHus3oCRlBR7Nzji3fGJn3U qrqPW2STNHOVmMCANR0pPqOYaFiAxWCvDi56zO1nFFQ9ZZgb/wNXyOXgoFfF5EyjL0Iu qJxo7ufCzZ20E8xRDuagrXVnT06qcyWtx65q0Jnzsmipc8ZNq4DCWgUnkP3UhkneFZ9q abfFNRjpDkdTlSHrpgYwKBsPYUkM4G35QVv6ULrOco3xlYfOfE7wgvTVJU3YmJdRp9MI BmwAFhwo0TBIHq1kV6Hrn0/xpMSmDmDpLotM4u68A7D0pTy23KVqIOxYyPdWtYU654yY 8kBA== X-Gm-Message-State: ALyK8tJvrPtbxepjBg9EYnElMB3/JMsEccShHv/W1XypybEEPMYWZJ4Esza2S7B8oRUxG7mW4zKKflEfpYOKFw== X-Received: by 10.28.228.132 with SMTP id b126mr2294612wmh.93.1468914921257; Tue, 19 Jul 2016 00:55:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.200.104 with HTTP; Tue, 19 Jul 2016 00:55:20 -0700 (PDT) X-Originating-IP: [2.139.201.247] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B476D2F16@ESESSMB209.ericsson.se> References: <87oa5vnia0.fsf@hobgoblin.ariadne.com> <77386A7F-638A-44D2-ABE4-9D84EF0E65F8@att.com> <6B7396D8-A71A-4FC5-917C-BC8FE33F4C8F@att.com> <18106252-578D-4FF8-ABD1-2DA73188CD04@edvina.net> <7594FB04B1934943A5C02806D1A2204B476D2936@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B476D2F16@ESESSMB209.ericsson.se> From: David Viamonte Date: Tue, 19 Jul 2016 09:55:20 +0200 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114b09b21653680537f86833 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 07:55:31 -0000 --001a114b09b21653680537f86833 Content-Type: text/plain; charset=UTF-8 Just adding some context without entering the technical discussion: in particular, this feature is also available in some of the traditional radio systems that Public Safety and First Responders are using today. Since MCPTT is intended to emulate and eventually replace those systems in the future, the intention is that it should be able to mimick such features. Hacing said this, like with many technical solutions, ways to misuse the capability will certainly exist. Let's hope that having the capability developed based on open standards may allow for controlling it in a more transparent way than vendors implementing their own solutions each. On Tue, Jul 19, 2016 at 6:37 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>> The person to whom you make the auto-answer call needs to authorize > >>> you to make such calls to that person. > >> > >> The service does NOT allow one to make auto-answer calls to "anyone". > > > > And that authorization is performed by the user, in the device? (Not in > the network.) And this can't be > > preconfigured by the SP as part of device provisioning? (At the same > time they preinstall all those apps > > users don't want and can't remove.) > > Users need to be authorized in order to use the MCPTT service to begin > with (with or without auto-answer). MCPTT is NOT a service that the > "average consumer" can just download/preinstall, sign-up for and start > using. MCPTT is a "tool" that can be used by authorized professionals (fire > fighters, first responders, etc...) when performing their work. > > Regards, > > Christer > > > > > -----Original Message----- > > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Olle E. > > Johansson > > Sent: 18 July 2016 21:07 > > To: DOLLY, MARTIN C > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 > > > > > >> On 18 Jul 2016, at 19:59, DOLLY, MARTIN C wrote: > >> > >> Cannot occur. > > Does the protocol prohibit that? How? For all usages in all > implementations? > > > > /O > >> > >> Martin C Dolly > >> Lead Member of Technical Staff > >> Core & Government/Regulatory Standards AT&T > >> Cell: 609-903-3360 > >> Email: md3135@att.com > >> > >>> On Jul 18, 2016, at 1:42 PM, Paul Kyzivat > wrote: > >>> > >>> The key question to answer is: How can a *user* know it won't be > enabled on his device? > >>> > >>> Thanks, > >>> Paul > >>> > >>>> On 7/18/16 1:36 PM, Olle E. Johansson wrote: > >>>> > >>>>> On 18 Jul 2016, at 18:59, Andrew Allen >>>>> > wrote: > >>>>> > >>>>> > >>>>> Ekr > >>>>> > >>>>> MCPTT uses RFC 5373 for auto answer triggering and is what enables > >>>>> the feature. > >>>>> > >>>>> That RFC describes in detail the security/privacy concerns with > >>>>> auto answering and the "bug my phone" attack. > >>>>> > >>>>> The ambient listening mode is for first responders such as police > >>>>> and fire fighters in situations when they are injured etc. > >>>>> > >>>>> This mode would not be enabled in commercial applications. > >>>> How can you be sure that no one will find any use case for that > >>>> mode outside blue light areas? > >>>> > >>>> /O > >>>>> > >>>>> Andrew > >>>>> > >>>>> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of > >>>>> *DOLLY, MARTIN C > >>>>> *Sent:* Monday, July 18, 2016 11:00 AM > >>>>> *To:* Eric Rescorla > > >>>>> *Cc:* DISPATCH > > >>>>> *Subject:* Re: [dispatch] > >>>>> draft-holmberg-dispatch-mcptt-rp-namespace-01 > >>>>> > >>>>> MC is for Mission Critical communications, not for commercial use. > >>>>> We would never expect this from a consumer UE. > >>>>> > >>>>> Martin C Dolly > >>>>> Lead Member of Technical Staff > >>>>> Core & Government/Regulatory Standards AT&T > >>>>> Cell: 609-903-3360 > >>>>> Email: md3135@att.com > >>>>> > >>>>> > >>>>> On Jul 18, 2016, at 10:47 AM, Eric Rescorla >>>>> > wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley > >>>>> > wrote: > >>>>> > >>>>> Eric Rescorla > writes: > >>>>>> One of the "features" that this claims to be enable is: > >>>>>> "Ambient Listening", which seems to be having the device > >>>>> start recording > >>>>>> the environment without user consent or indication. This > >>>>> seems like an > >>>>>> anti-feature, especially in consumer devices. > >>>>> > >>>>> As far as I can tell, "Ambient Listening" is a feature of > >>>>> MCPTT, and > >>>>> while the work in draft-holmberg-dispatch-mcptt-rp-namespace > >>>>> is needed > >>>>> by MCPTT, the draft is not sufficient to enable "Ambient > >>>>> Listening". > >>>>> The only argument I can see against proceeding with the draft > >>>>> is if we > >>>>> wanted to reject the draft specifically to prevent MCPTT from > >>>>> being > >>>>> implemented because we didn't like the "Ambient Listening" > >>>>> feature of > >>>>> MCPTT. > >>>>> > >>>>> > >>>>> Yes, that's what I'm suggesting. > >>>>> > >>>>> > >>>>> > >>>>> And it does appear that 3GPP is aware of the privacy > >>>>> implications of > >>>>> "Ambient Listening": > >>>>> > >>>>> MCPTT is primarily targeting to provide a professional Push > >>>>> To Talk > >>>>> service to e.g., public safety, transport companies, > >>>>> utilities or > >>>>> industrial and nuclear plants. In addition to this a > >>>>> commercial PTT > >>>>> service for non-professional use (e.g., groups of people on > >>>>> holiday) > >>>>> may be delivered through an MCPTT system. Based on their > >>>>> operational > >>>>> model, the performance and MCPTT features in use vary per > user > >>>>> organization, where functionality which is more mission > >>>>> critical > >>>>> specific (e.g., Ambient Listening and Imminent Peril Call) > >>>>> might not > >>>>> be available to commercial customers. > >>>>> > >>>>> > >>>>> I found this section fairly unclear as to when these features > >>>>> would be allowed. > >>>>> > >>>>> -Ekr > >>>>> > >>>>> > >>>>> > >>>>> Dale > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> dispatch mailing list > >>>>> dispatch@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>>> > >>>>> _______________________________________________ > >>>>> dispatch mailing list > >>>>> dispatch@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> dispatch mailing list > >>>> dispatch@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dispatch > >>> > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a114b09b21653680537f86833 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just adding some context without entering the technical di= scussion: in particular, this feature is also available in some of the trad= itional radio systems that Public Safety and First Responders are using tod= ay. Since MCPTT is intended to emulate and eventually replace those systems= in the future, the intention is that it should be able to mimick such feat= ures.

Hacing said this, like with many technical solutio= ns, ways to misuse the capability will certainly exist. Let's hope that= having the capability developed based on open standards may allow for cont= rolling it in a more transparent way than vendors implementing their own so= lutions each.



On Tue, Jul 19, 2016 at 6:37 AM, Chri= ster Holmberg <christer.holmberg@ericsson.com> = wrote:
Hi,

>>> The person to whom you make the auto-answer call needs to auth= orize
>>> you to make such calls to that person.
>>
>> The service does NOT allow one to make auto-answer calls to "= anyone".
>
> And that authorization is performed by the user, in the device? (Not i= n the network.) And this can't be
> preconfigured by the SP as part of device provisioning? (At the same t= ime they preinstall all those apps
> users don't want and can't remove.)

Users need to be authorized in order to use the MCPTT service to beg= in with (with or without auto-answer). MCPTT is NOT a service that the &quo= t;average consumer" can just download/preinstall, sign-up for and star= t using. MCPTT is a "tool" that can be used by authorized profess= ionals (fire fighters, first responders, etc...) when performing their work= .

Regards,

Christer



> -----Original Message-----
> From: dispatch [mailto:di= spatch-bounces@ietf.org] On Behalf Of Olle E.
> Johansson
> Sent: 18 July 2016 21:07
> To: DOLLY, MARTIN C <md3135@att.c= om>
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01<= br> >
>
>> On 18 Jul 2016, at 19:59, DOLLY, MARTIN C <md3135@att.com> wrote:
>>
>> Cannot occur.
> Does the protocol prohibit that? How? For all usages in all implementa= tions?
>
> /O
>>
>> Martin C Dolly
>> Lead Member of Technical Staff
>> Core & Government/Regulatory Standards AT&T
>> Cell: 609-903-= 3360
>> Email: md3135@att.com
>>
>>> On Jul 18, 2016, at 1:42 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>>
>>> The key question to answer is: How can a *user* know it won= 9;t be enabled on his device?
>>>
>>>=C2=A0 =C2=A0Thanks,
>>>=C2=A0 =C2=A0Paul
>>>
>>>> On 7/18/16 1:36 PM, Olle E. Johansson wrote:
>>>>
>>>>> On 18 Jul 2016, at 18:59, Andrew Allen <aallen@blackberry.com
>>>>> <mailto:aa= llen@blackberry.com>> wrote:
>>>>>
>>>>>
>>>>> Ekr
>>>>>
>>>>> MCPTT uses RFC 5373 for auto answer triggering and is = what enables
>>>>> the feature.
>>>>>
>>>>> That RFC describes in detail the security/privacy conc= erns with
>>>>> auto answering and the "bug my phone" attack= .
>>>>>
>>>>> The ambient listening mode is for first responders suc= h as police
>>>>> and fire fighters in situations when they are injured = etc.
>>>>>
>>>>> This mode would not be enabled in commercial applicati= ons.
>>>> How can you be sure that no one will find any use case for= that
>>>> mode outside blue light areas?
>>>>
>>>> /O
>>>>>
>>>>> Andrew
>>>>>
>>>>> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of
>>>>> *DOLLY, MARTIN C
>>>>> *Sent:* Monday, July 18, 2016 11:00 AM
>>>>> *To:* Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com<= /a>>>
>>>>> *Cc:* DISPATCH <dispatch@ietf.org <mailto:dis= patch@ietf.org>>
>>>>> *Subject:* Re: [dispatch]
>>>>> draft-holmberg-dispatch-mcptt-rp-namespace-01
>>>>>
>>>>> MC is for Mission Critical communications, not for com= mercial use.
>>>>> We would never expect this from a consumer UE.
>>>>>
>>>>> Martin C Dolly
>>>>> Lead Member of Technical Staff
>>>>> Core & Government/Regulatory Standards AT&T >>>>> Cell: 609-903-3360
>>>>> Email: md3135@att.co= m <mailto:md3135@att.com> >>>>>
>>>>>
>>>>> On Jul 18, 2016, at 10:47 AM, Eric Rescorla <ekr@rtfm.com
>>>>> <mailto:ekr@rtfm.co= m>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0On Mon, Jul 18, 2016 at 4:16 PM, Dale R. W= orley
>>>>>=C2=A0 =C2=A0<= worley@ariadne.com <mailto:wor= ley@ariadne.com>> wrote:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> writes:
>>>>>> One of the "features" that this claims t= o be enable is:
>>>>>> "Ambient Listening", which seems to be h= aving the device
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0start recording
>>>>>> the environment without user consent or indication= . This
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0seems like an
>>>>>> anti-feature, especially in consumer devices.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0As far as I can tell, "= Ambient Listening" is a feature of
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0MCPTT, and
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0while the work in draft-holm= berg-dispatch-mcptt-rp-namespace
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0is needed
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0by MCPTT, the draft is not s= ufficient to enable "Ambient
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Listening".
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0The only argument I can see = against proceeding with the draft
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0is if we
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0wanted to reject the draft s= pecifically to prevent MCPTT from
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0being
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented because we didn&= #39;t like the "Ambient Listening"
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0feature of
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0MCPTT.
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0Yes, that's what I'm suggesting. >>>>>
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0And it does appear that 3GPP= is aware of the privacy
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0implications of
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"Ambient Listening"= ;:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MCPTT is primarily t= argeting to provide a professional Push
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0To Talk
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 service to e.g., pub= lic safety, transport companies,
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0utilities or
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 industrial and nucle= ar plants.=C2=A0 In addition to this a
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0commercial PTT
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 service for non-prof= essional use (e.g., groups of people on
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0holiday)
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 may be delivered thr= ough an MCPTT system.=C2=A0 Based on their
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0operational
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 model, the performan= ce and MCPTT features in use vary per user
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 organization, where = functionality which is more mission
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0critical
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specific (e.g., Ambi= ent Listening and Imminent Peril Call)
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0might not
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be available to comm= ercial customers.
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0I found this section fairly unclear as to = when these features
>>>>>=C2=A0 =C2=A0would be allowed.
>>>>>
>>>>>=C2=A0 =C2=A0-Ekr
>>>>>
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Dale
>>>>>
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0__________________________________________= _____
>>>>>=C2=A0 =C2=A0dispatch mailing list
>>>>>=C2=A0 =C2=A0dispa= tch@ietf.org <mailto:dispatch@i= etf.org>
>>>>>=C2=A0 =C2=A0https://www.ietf.org/= mailman/listinfo/dispatch
>>>>>
>>>>> _______________________________________________
>>>>> dispatch mailing list
>>>>> dispatch@ietf.org= <mailto:dispatch@ietf.org&= gt;
>>>>> https://www.ietf.org/mailman/list= info/dispatch
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> dispatch@ietf.org=
>>>> https://www.ietf.org/mailman/listinfo= /dispatch
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dis= patch
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatc= h
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

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

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

--001a114b09b21653680537f86833-- From nobody Tue Jul 19 14:09:09 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23C112D8D0 for ; Tue, 19 Jul 2016 14:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaxv-7VS7-Wa for ; Tue, 19 Jul 2016 14:09:04 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.111]) (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 34E7512D899 for ; Tue, 19 Jul 2016 14:09:03 -0700 (PDT) Received: from [193.109.255.99] by server-7.bemta-14.messagelabs.com id 9F/C6-09881-EE69E875; Tue, 19 Jul 2016 21:09:02 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRWlGSWpSXmKPExsViJ5l1QffttL5 wg9cfFCyWTlrA6sDosWTJT6YAxijWzLyk/IoE1oy+zSfYCg6fYqrY/PIbewPjhGNMXYycHGwC VhKtb++C2SICBRLbNm5lAbGZBbQl/l9fx9jFyMEhLOAq0fFACcQUEXCTaJ+q0sXIBWQ2MUrMe bOSDaScRUBVYumOCWCtvAIREqdudLGDFAkJrGGT+LlrGStIglMgVOL/1cdgDYwCshJfGlczQ+ wSl7j1ZD7YDRICAhJL9pxnhrBFJV4+/scKYctLfFv6lBWivkji5KtuRohlghInZz5hmcAoOAv JqFlIymYhKZsF9AOzgKbE+l36ECWKElO6H7JD2BoSrXPmsiOLL2BkX8WoXpxaVJZapGuml1SU mZ5RkpuYmaNraGiil5taXJyYnpqTmFSsl5yfu4kRGBUMQLCD8e8E50OMkhxMSqK8qqK94UJ8S fkplRmJxRnxRaU5qcWHGGU4OJQkeFOm9oULCRalpqdWpGXmAOMTJi3BwaMkwjsdJM1bXJCYW5 yZDpE6xajLcaTnxlomIZa8/LxUKXHeZJAiAZCijNI8uBGwVHGJUVZKmJcR6CghnoLUotzMElT 5V4ziHIxKwrw5IFN4MvNK4Da9AjqCCegIA9VukCNKEhFSUg2MM4uYfolPSmTw+rGoXkh31d2u /Y18mt+M8/vYNqvmSfvNXD/BJJfVgD1EaS2fm+SUlNUebnWHnJu+GGzUvxPu3j//RjHbv6j02 MlbnjCxG195p7Gsm+Vkqvqh9iv1ty6XcR5bFL8op0NNtHyzTkPlOqG1ihei/QWD/rxI3xK839 DKRu7o+kwlluKMREMt5qLiRABhxsu0EAMAAA== X-Env-Sender: Richard.Allen3@homeoffice.gsi.gov.uk X-Msg-Ref: server-15.tower-48.messagelabs.com!1468962541!58616644!1 X-Originating-IP: [62.25.106.208] X-StarScan-Received: X-StarScan-Version: 8.77; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27330 invoked from network); 19 Jul 2016 21:09:01 -0000 Received: from gateway-102.energis.gsi.gov.uk (HELO mailgate.gsi.gov.uk) (62.25.106.208) by server-15.tower-48.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 19 Jul 2016 21:09:01 -0000 From: Allen Richard To: David Viamonte , Christer Holmberg Thread-Topic: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 Thread-Index: AQHR4P72MK4Fy15wv0ie5FK6Ztp+F6AeK9MAgAALfYCAACFvgIAACnQAgAABewCAAATvgIAAAgQAgAAEWICAAEvrAIAAX/+AgAA3JgCAAOnC0A== Date: Tue, 19 Jul 2016 21:08:46 +0000 Message-ID: <1E80BA6F6526374AA13EF37036BEEDBA9303F04B@sdccmm8017.Poise.HomeOffice.Local> References: <87oa5vnia0.fsf@hobgoblin.ariadne.com> <77386A7F-638A-44D2-ABE4-9D84EF0E65F8@att.com> <6B7396D8-A71A-4FC5-917C-BC8FE33F4C8F@att.com> <18106252-578D-4FF8-ABD1-2DA73188CD04@edvina.net> <7594FB04B1934943A5C02806D1A2204B476D2936@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B476D2F16@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.17.45.56] Content-Type: multipart/alternative; boundary="_000_1E80BA6F6526374AA13EF37036BEEDBA9303F04Bsdccmm8017Poise_" MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:09:08 -0000 --_000_1E80BA6F6526374AA13EF37036BEEDBA9303F04Bsdccmm8017Poise_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgdGhlcmUsDQoNCkkgd29yayBmb3IgRVNNQ1AsIGEgcHJvZ3JhbW1lIGluIHRoZSBVSyB0byBk ZWxpdmVyIHB1YmxpYyBzYWZldHkgY29tbXVuaWNhdGlvbnMgZm9yIHRoZSAzIEVtZXJnZW5jeSBT ZXJ2aWNlcy4gU3BlY2lmaWNhbGx5IEkgaGF2ZSBvdmVyc2lnaHQgb24gc3RhbmRhcmRzIGFuZCBh c3N1cmluZyBQdWJsaWMgU2FmZXR5IEZ1bmN0aW9uYWxpdHkgaW4gb3VyIGZ1dHVyZSBkZXBsb3lt ZW50Lg0KDQpJIGludHJvZHVjZWQgdGhlIEFtYmllbnQgbGlzdGVuaW5nIHJlcXVpcmVtZW50cyBp biAzR1BQLCBhcyB0aGlzIGlzIG9uZSBvZiBvdXIgcHJvZ3JhbW1l4oCZcyB1c2VyIHJlcXVpcmVt ZW50cyAuIEFzIG1lbnRpb25lZCBwcmV2aW91c2x5IG9uIHRoZSB0aHJlYWQgdGhpcyByZXBsaWNh dGVzIGV4aXN0aW5nIFRFVFJBIGZ1bmN0aW9uYWxpdHkgZGVwbG95ZWQgaW4gb3VyIGN1cnJlbnQg bmF0aW9ud2lkZSBURVRSQSBuZXR3b3JrLiBUaGlzIGlzIHVzZWQgZm9yIGVtZXJnZW5jeSBzZXJ2 aWNlIHVzZXJzIGluIGRpc3RyZXNzIGFuZCBpcyBhbHNvIHVzZWQgdG8gZW5hYmxlIHByb2Zlc3Np b25hbCBpbnZlc3RpZ2F0aW9ucy4gVGhpcyBmdW5jdGlvbmFsaXR5IGlzIHZlcnkgc3RyaWN0bHkg Y29udHJvbGxlZCB3aXRoaW4gYSBwdWJsaWMgc2FmZXR5IGVudmlyb25tZW50ICh0aGluayBzeXN0 ZW0gYWRtaW5zIGZvciB1c2VyIG9yZ2FuaXNhdGlvbnMpICxhcyBpdCBhbHNvIGhhcyBwZXJzb25h bCBjb25zaWRlcmF0aW9ucyB0aGVyZSwgYmVjYXVzZSBzb21lIHdpbGwgaGF2ZSBkZWRpY2F0ZWQg ZGV2aWNlcyB0aGF0IHRoZXkgZG9u4oCZdCBoYW5kIGluIGF0IHRoZSBlbmQgb2YgdGhlIHdvcmtp bmcgZGF5LiBUaGlzIHNob3VsZCBiZSB2aWV3ZWQgaW4gdGhlIHNhbWUgY29udGV4dCBhcyB0aGUg cHJvZmVzc2lvbmFsIHRvb2xzIHdlIGFsbCB1c2UgZXZlcnkgZGF5IChJIGV4cGVjdCB0aGF0IHRo aXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBieSBteSBvcmdhbmlzYXRpb24gdG8gaGVscCBndWFy ZCBhZ2FpbnN0IGFuZCBpbnZlc3RpZ2F0ZSBtaXNjb25kdWN0KS4NCg0KQ2hlZXJzLA0KUmljaGFy ZA0KDQpGcm9tOiBkaXNwYXRjaCBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBEYXZpZCBWaWFtb250ZQ0KU2VudDogMTkgSnVseSAyMDE2IDA4OjU1DQpUbzog Q2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBkaXNwYXRjaEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtk aXNwYXRjaF0gZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtbWNwdHQtcnAtbmFtZXNwYWNlLTAxDQoN Ckp1c3QgYWRkaW5nIHNvbWUgY29udGV4dCB3aXRob3V0IGVudGVyaW5nIHRoZSB0ZWNobmljYWwg ZGlzY3Vzc2lvbjogaW4gcGFydGljdWxhciwgdGhpcyBmZWF0dXJlIGlzIGFsc28gYXZhaWxhYmxl IGluIHNvbWUgb2YgdGhlIHRyYWRpdGlvbmFsIHJhZGlvIHN5c3RlbXMgdGhhdCBQdWJsaWMgU2Fm ZXR5IGFuZCBGaXJzdCBSZXNwb25kZXJzIGFyZSB1c2luZyB0b2RheS4gU2luY2UgTUNQVFQgaXMg aW50ZW5kZWQgdG8gZW11bGF0ZSBhbmQgZXZlbnR1YWxseSByZXBsYWNlIHRob3NlIHN5c3RlbXMg aW4gdGhlIGZ1dHVyZSwgdGhlIGludGVudGlvbiBpcyB0aGF0IGl0IHNob3VsZCBiZSBhYmxlIHRv IG1pbWljayBzdWNoIGZlYXR1cmVzLg0KDQpIYWNpbmcgc2FpZCB0aGlzLCBsaWtlIHdpdGggbWFu eSB0ZWNobmljYWwgc29sdXRpb25zLCB3YXlzIHRvIG1pc3VzZSB0aGUgY2FwYWJpbGl0eSB3aWxs IGNlcnRhaW5seSBleGlzdC4gTGV0J3MgaG9wZSB0aGF0IGhhdmluZyB0aGUgY2FwYWJpbGl0eSBk ZXZlbG9wZWQgYmFzZWQgb24gb3BlbiBzdGFuZGFyZHMgbWF5IGFsbG93IGZvciBjb250cm9sbGlu ZyBpdCBpbiBhIG1vcmUgdHJhbnNwYXJlbnQgd2F5IHRoYW4gdmVuZG9ycyBpbXBsZW1lbnRpbmcg dGhlaXIgb3duIHNvbHV0aW9ucyBlYWNoLg0KDQoNCg0KT24gVHVlLCBKdWwgMTksIDIwMTYgYXQg NjozNyBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0K Pj4+IFRoZSBwZXJzb24gdG8gd2hvbSB5b3UgbWFrZSB0aGUgYXV0by1hbnN3ZXIgY2FsbCBuZWVk cyB0byBhdXRob3JpemUNCj4+PiB5b3UgdG8gbWFrZSBzdWNoIGNhbGxzIHRvIHRoYXQgcGVyc29u Lg0KPj4NCj4+IFRoZSBzZXJ2aWNlIGRvZXMgTk9UIGFsbG93IG9uZSB0byBtYWtlIGF1dG8tYW5z d2VyIGNhbGxzIHRvICJhbnlvbmUiLg0KPg0KPiBBbmQgdGhhdCBhdXRob3JpemF0aW9uIGlzIHBl cmZvcm1lZCBieSB0aGUgdXNlciwgaW4gdGhlIGRldmljZT8gKE5vdCBpbiB0aGUgbmV0d29yay4p IEFuZCB0aGlzIGNhbid0IGJlDQo+IHByZWNvbmZpZ3VyZWQgYnkgdGhlIFNQIGFzIHBhcnQgb2Yg ZGV2aWNlIHByb3Zpc2lvbmluZz8gKEF0IHRoZSBzYW1lIHRpbWUgdGhleSBwcmVpbnN0YWxsIGFs bCB0aG9zZSBhcHBzDQo+IHVzZXJzIGRvbid0IHdhbnQgYW5kIGNhbid0IHJlbW92ZS4pDQoNClVz ZXJzIG5lZWQgdG8gYmUgYXV0aG9yaXplZCBpbiBvcmRlciB0byB1c2UgdGhlIE1DUFRUIHNlcnZp Y2UgdG8gYmVnaW4gd2l0aCAod2l0aCBvciB3aXRob3V0IGF1dG8tYW5zd2VyKS4gTUNQVFQgaXMg Tk9UIGEgc2VydmljZSB0aGF0IHRoZSAiYXZlcmFnZSBjb25zdW1lciIgY2FuIGp1c3QgZG93bmxv YWQvcHJlaW5zdGFsbCwgc2lnbi11cCBmb3IgYW5kIHN0YXJ0IHVzaW5nLiBNQ1BUVCBpcyBhICJ0 b29sIiB0aGF0IGNhbiBiZSB1c2VkIGJ5IGF1dGhvcml6ZWQgcHJvZmVzc2lvbmFscyAoZmlyZSBm aWdodGVycywgZmlyc3QgcmVzcG9uZGVycywgZXRjLi4uKSB3aGVuIHBlcmZvcm1pbmcgdGhlaXIg d29yay4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE9sbGUg RS4NCj4gSm9oYW5zc29uDQo+IFNlbnQ6IDE4IEp1bHkgMjAxNiAyMTowNw0KPiBUbzogRE9MTFks IE1BUlRJTiBDIDxtZDMxMzVAYXR0LmNvbTxtYWlsdG86bWQzMTM1QGF0dC5jb20+Pg0KPiBDYzog ZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPg0KPiBTdWJqZWN0OiBS ZTogW2Rpc3BhdGNoXSBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1tY3B0dC1ycC1uYW1lc3BhY2Ut MDENCj4NCj4NCj4+IE9uIDE4IEp1bCAyMDE2LCBhdCAxOTo1OSwgRE9MTFksIE1BUlRJTiBDIDxt ZDMxMzVAYXR0LmNvbTxtYWlsdG86bWQzMTM1QGF0dC5jb20+PiB3cm90ZToNCj4+DQo+PiBDYW5u b3Qgb2NjdXIuDQo+IERvZXMgdGhlIHByb3RvY29sIHByb2hpYml0IHRoYXQ/IEhvdz8gRm9yIGFs bCB1c2FnZXMgaW4gYWxsIGltcGxlbWVudGF0aW9ucz8NCj4NCj4gL08NCj4+DQo+PiBNYXJ0aW4g QyBEb2xseQ0KPj4gTGVhZCBNZW1iZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQo+PiBDb3JlICYgR292 ZXJubWVudC9SZWd1bGF0b3J5IFN0YW5kYXJkcyBBVCZUDQo+PiBDZWxsOiA2MDktOTAzLTMzNjA8 dGVsOjYwOS05MDMtMzM2MD4NCj4+IEVtYWlsOiBtZDMxMzVAYXR0LmNvbTxtYWlsdG86bWQzMTM1 QGF0dC5jb20+DQo+Pg0KPj4+IE9uIEp1bCAxOCwgMjAxNiwgYXQgMTo0MiBQTSwgUGF1bCBLeXpp dmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+ IHdyb3RlOg0KPj4+DQo+Pj4gVGhlIGtleSBxdWVzdGlvbiB0byBhbnN3ZXIgaXM6IEhvdyBjYW4g YSAqdXNlcioga25vdyBpdCB3b24ndCBiZSBlbmFibGVkIG9uIGhpcyBkZXZpY2U/DQo+Pj4NCj4+ PiAgIFRoYW5rcywNCj4+PiAgIFBhdWwNCj4+Pg0KPj4+PiBPbiA3LzE4LzE2IDE6MzYgUE0sIE9s bGUgRS4gSm9oYW5zc29uIHdyb3RlOg0KPj4+Pg0KPj4+Pj4gT24gMTggSnVsIDIwMTYsIGF0IDE4 OjU5LCBBbmRyZXcgQWxsZW4gPGFhbGxlbkBibGFja2JlcnJ5LmNvbTxtYWlsdG86YWFsbGVuQGJs YWNrYmVycnkuY29tPg0KPj4+Pj4gPG1haWx0bzphYWxsZW5AYmxhY2tiZXJyeS5jb208bWFpbHRv OmFhbGxlbkBibGFja2JlcnJ5LmNvbT4+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gRWty DQo+Pj4+Pg0KPj4+Pj4gTUNQVFQgdXNlcyBSRkMgNTM3MyBmb3IgYXV0byBhbnN3ZXIgdHJpZ2dl cmluZyBhbmQgaXMgd2hhdCBlbmFibGVzDQo+Pj4+PiB0aGUgZmVhdHVyZS4NCj4+Pj4+DQo+Pj4+ PiBUaGF0IFJGQyBkZXNjcmliZXMgaW4gZGV0YWlsIHRoZSBzZWN1cml0eS9wcml2YWN5IGNvbmNl cm5zIHdpdGgNCj4+Pj4+IGF1dG8gYW5zd2VyaW5nIGFuZCB0aGUgImJ1ZyBteSBwaG9uZSIgYXR0 YWNrLg0KPj4+Pj4NCj4+Pj4+IFRoZSBhbWJpZW50IGxpc3RlbmluZyBtb2RlIGlzIGZvciBmaXJz dCByZXNwb25kZXJzIHN1Y2ggYXMgcG9saWNlDQo+Pj4+PiBhbmQgZmlyZSBmaWdodGVycyBpbiBz aXR1YXRpb25zIHdoZW4gdGhleSBhcmUgaW5qdXJlZCBldGMuDQo+Pj4+Pg0KPj4+Pj4gVGhpcyBt b2RlIHdvdWxkIG5vdCBiZSBlbmFibGVkIGluIGNvbW1lcmNpYWwgYXBwbGljYXRpb25zLg0KPj4+ PiBIb3cgY2FuIHlvdSBiZSBzdXJlIHRoYXQgbm8gb25lIHdpbGwgZmluZCBhbnkgdXNlIGNhc2Ug Zm9yIHRoYXQNCj4+Pj4gbW9kZSBvdXRzaWRlIGJsdWUgbGlnaHQgYXJlYXM/DQo+Pj4+DQo+Pj4+ IC9PDQo+Pj4+Pg0KPj4+Pj4gQW5kcmV3DQo+Pj4+Pg0KPj4+Pj4gKkZyb206KiBkaXNwYXRjaCBb bWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmc+XSAqT24gQmVoYWxmIE9mDQo+Pj4+PiAqRE9MTFksIE1BUlRJTiBDDQo+Pj4+PiAq U2VudDoqIE1vbmRheSwgSnVseSAxOCwgMjAxNiAxMTowMCBBTQ0KPj4+Pj4gKlRvOiogRXJpYyBS ZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+IDxtYWlsdG86ZWtyQHJ0 Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+Pj4NCj4+Pj4+ICpDYzoqIERJU1BBVENIIDxkaXNw YXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+IDxtYWlsdG86ZGlzcGF0Y2hA aWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPj4+DQo+Pj4+PiAqU3ViamVjdDoqIFJl OiBbZGlzcGF0Y2hdDQo+Pj4+PiBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1tY3B0dC1ycC1uYW1l c3BhY2UtMDENCj4+Pj4+DQo+Pj4+PiBNQyBpcyBmb3IgTWlzc2lvbiBDcml0aWNhbCBjb21tdW5p Y2F0aW9ucywgbm90IGZvciBjb21tZXJjaWFsIHVzZS4NCj4+Pj4+IFdlIHdvdWxkIG5ldmVyIGV4 cGVjdCB0aGlzIGZyb20gYSBjb25zdW1lciBVRS4NCj4+Pj4+DQo+Pj4+PiBNYXJ0aW4gQyBEb2xs eQ0KPj4+Pj4gTGVhZCBNZW1iZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQo+Pj4+PiBDb3JlICYgR292 ZXJubWVudC9SZWd1bGF0b3J5IFN0YW5kYXJkcyBBVCZUDQo+Pj4+PiBDZWxsOiA2MDktOTAzLTMz NjA8dGVsOjYwOS05MDMtMzM2MD4NCj4+Pj4+IEVtYWlsOiBtZDMxMzVAYXR0LmNvbTxtYWlsdG86 bWQzMTM1QGF0dC5jb20+IDxtYWlsdG86bWQzMTM1QGF0dC5jb208bWFpbHRvOm1kMzEzNUBhdHQu Y29tPj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gSnVsIDE4LCAyMDE2LCBhdCAxMDo0NyBBTSwg RXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+DQo+Pj4+PiA8 bWFpbHRvOmVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4+IHdyb3RlOg0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gICBPbiBNb24sIEp1bCAxOCwgMjAxNiBhdCA0OjE2IFBNLCBE YWxlIFIuIFdvcmxleQ0KPj4+Pj4gICA8d29ybGV5QGFyaWFkbmUuY29tPG1haWx0bzp3b3JsZXlA YXJpYWRuZS5jb20+IDxtYWlsdG86d29ybGV5QGFyaWFkbmUuY29tPG1haWx0bzp3b3JsZXlAYXJp YWRuZS5jb20+Pj4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gICAgICAgRXJpYyBSZXNjb3JsYSA8ZWty QHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+IDxtYWlsdG86ZWtyQHJ0Zm0uY29tPG1haWx0 bzpla3JAcnRmbS5jb20+Pj4gd3JpdGVzOg0KPj4+Pj4+IE9uZSBvZiB0aGUgImZlYXR1cmVzIiB0 aGF0IHRoaXMgY2xhaW1zIHRvIGJlIGVuYWJsZSBpczoNCj4+Pj4+PiAiQW1iaWVudCBMaXN0ZW5p bmciLCB3aGljaCBzZWVtcyB0byBiZSBoYXZpbmcgdGhlIGRldmljZQ0KPj4+Pj4gICAgICAgc3Rh cnQgcmVjb3JkaW5nDQo+Pj4+Pj4gdGhlIGVudmlyb25tZW50IHdpdGhvdXQgdXNlciBjb25zZW50 IG9yIGluZGljYXRpb24uIFRoaXMNCj4+Pj4+ICAgICAgIHNlZW1zIGxpa2UgYW4NCj4+Pj4+PiBh bnRpLWZlYXR1cmUsIGVzcGVjaWFsbHkgaW4gY29uc3VtZXIgZGV2aWNlcy4NCj4+Pj4+DQo+Pj4+ PiAgICAgICBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgIkFtYmllbnQgTGlzdGVuaW5nIiBpcyBhIGZl YXR1cmUgb2YNCj4+Pj4+ICAgICAgIE1DUFRULCBhbmQNCj4+Pj4+ICAgICAgIHdoaWxlIHRoZSB3 b3JrIGluIGRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLW1jcHR0LXJwLW5hbWVzcGFjZQ0KPj4+Pj4g ICAgICAgaXMgbmVlZGVkDQo+Pj4+PiAgICAgICBieSBNQ1BUVCwgdGhlIGRyYWZ0IGlzIG5vdCBz dWZmaWNpZW50IHRvIGVuYWJsZSAiQW1iaWVudA0KPj4+Pj4gICAgICAgTGlzdGVuaW5nIi4NCj4+ Pj4+ICAgICAgIFRoZSBvbmx5IGFyZ3VtZW50IEkgY2FuIHNlZSBhZ2FpbnN0IHByb2NlZWRpbmcg d2l0aCB0aGUgZHJhZnQNCj4+Pj4+ICAgICAgIGlzIGlmIHdlDQo+Pj4+PiAgICAgICB3YW50ZWQg dG8gcmVqZWN0IHRoZSBkcmFmdCBzcGVjaWZpY2FsbHkgdG8gcHJldmVudCBNQ1BUVCBmcm9tDQo+ Pj4+PiAgICAgICBiZWluZw0KPj4+Pj4gICAgICAgaW1wbGVtZW50ZWQgYmVjYXVzZSB3ZSBkaWRu J3QgbGlrZSB0aGUgIkFtYmllbnQgTGlzdGVuaW5nIg0KPj4+Pj4gICAgICAgZmVhdHVyZSBvZg0K Pj4+Pj4gICAgICAgTUNQVFQuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ICAgWWVzLCB0aGF0J3Mgd2hh dCBJJ20gc3VnZ2VzdGluZy4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ICAgICAgIEFuZCBp dCBkb2VzIGFwcGVhciB0aGF0IDNHUFAgaXMgYXdhcmUgb2YgdGhlIHByaXZhY3kNCj4+Pj4+ICAg ICAgIGltcGxpY2F0aW9ucyBvZg0KPj4+Pj4gICAgICAgIkFtYmllbnQgTGlzdGVuaW5nIjoNCj4+ Pj4+DQo+Pj4+PiAgICAgICAgICBNQ1BUVCBpcyBwcmltYXJpbHkgdGFyZ2V0aW5nIHRvIHByb3Zp ZGUgYSBwcm9mZXNzaW9uYWwgUHVzaA0KPj4+Pj4gICAgICAgVG8gVGFsaw0KPj4+Pj4gICAgICAg ICAgc2VydmljZSB0byBlLmcuLCBwdWJsaWMgc2FmZXR5LCB0cmFuc3BvcnQgY29tcGFuaWVzLA0K Pj4+Pj4gICAgICAgdXRpbGl0aWVzIG9yDQo+Pj4+PiAgICAgICAgICBpbmR1c3RyaWFsIGFuZCBu dWNsZWFyIHBsYW50cy4gIEluIGFkZGl0aW9uIHRvIHRoaXMgYQ0KPj4+Pj4gICAgICAgY29tbWVy Y2lhbCBQVFQNCj4+Pj4+ICAgICAgICAgIHNlcnZpY2UgZm9yIG5vbi1wcm9mZXNzaW9uYWwgdXNl IChlLmcuLCBncm91cHMgb2YgcGVvcGxlIG9uDQo+Pj4+PiAgICAgICBob2xpZGF5KQ0KPj4+Pj4g ICAgICAgICAgbWF5IGJlIGRlbGl2ZXJlZCB0aHJvdWdoIGFuIE1DUFRUIHN5c3RlbS4gIEJhc2Vk IG9uIHRoZWlyDQo+Pj4+PiAgICAgICBvcGVyYXRpb25hbA0KPj4+Pj4gICAgICAgICAgbW9kZWws IHRoZSBwZXJmb3JtYW5jZSBhbmQgTUNQVFQgZmVhdHVyZXMgaW4gdXNlIHZhcnkgcGVyIHVzZXIN Cj4+Pj4+ICAgICAgICAgIG9yZ2FuaXphdGlvbiwgd2hlcmUgZnVuY3Rpb25hbGl0eSB3aGljaCBp cyBtb3JlIG1pc3Npb24NCj4+Pj4+ICAgICAgIGNyaXRpY2FsDQo+Pj4+PiAgICAgICAgICBzcGVj aWZpYyAoZS5nLiwgQW1iaWVudCBMaXN0ZW5pbmcgYW5kIEltbWluZW50IFBlcmlsIENhbGwpDQo+ Pj4+PiAgICAgICBtaWdodCBub3QNCj4+Pj4+ICAgICAgICAgIGJlIGF2YWlsYWJsZSB0byBjb21t ZXJjaWFsIGN1c3RvbWVycy4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gICBJIGZvdW5kIHRoaXMgc2Vj dGlvbiBmYWlybHkgdW5jbGVhciBhcyB0byB3aGVuIHRoZXNlIGZlYXR1cmVzDQo+Pj4+PiAgIHdv dWxkIGJlIGFsbG93ZWQuDQo+Pj4+Pg0KPj4+Pj4gICAtRWtyDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+PiAgICAgICBEYWxlDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiAgIGRpc3BhdGNo IG1haWxpbmcgbGlzdA0KPj4+Pj4gICBkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hA aWV0Zi5vcmc+IDxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYu b3JnPj4NCj4+Pj4+ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNw YXRjaA0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+PiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4+Pj4+IGRpc3BhdGNoQGll dGYub3JnPG1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZz4gPG1haWx0bzpkaXNwYXRjaEBpZXRmLm9y ZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+Pg0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBkaXNwYXRjaCBt YWlsaW5nIGxpc3QNCj4+Pj4gZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYu b3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNo DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPj4+IGRpc3BhdGNoQGlldGYub3JnPG1haWx0 bzpkaXNwYXRjaEBpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Rpc3BhdGNoDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPj4gZGlzcGF0Y2hAaWV0 Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gZGlzcGF0 Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiBk aXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0K ZGlzcGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpkaXNw YXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhpcyBl bWFpbCBoYXMgYmVlbiBzY2FubmVkIGJ5IHRoZSBTeW1hbnRlYyBFbWFpbCBTZWN1cml0eS5jbG91 ZCBzZXJ2aWNlLg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gcGxlYXNlIHZpc2l0IGh0dHA6Ly93d3cu c3ltYW50ZWNjbG91ZC5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KVGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIHByaXZhdGUgYW5kIGlu dGVuZGVkDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdob20gdGhleSBhcmUgYWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2UgcmV0dXJuIGl0IHRvIHRoZSBhZGRyZXNzDQppdCBjYW1lIGZyb20g dGVsbGluZyB0aGVtIGl0IGlzIG5vdCBmb3IgeW91IGFuZCB0aGVuIGRlbGV0ZSBpdCBmcm9tIHlv dXIgc3lzdGVtLg0KVGhpcyBlbWFpbCBtZXNzYWdlIGhhcyBiZWVuIHN3ZXB0IGZvciBjb21wdXRl ciB2aXJ1c2VzLg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCg== --_000_1E80BA6F6526374AA13EF37036BEEDBA9303F04Bsdccmm8017Poise_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWlnaHQ6 bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgdGhlcmUsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB3b3JrIGZvciBFU01DUCwgYSBwcm9ncmFtbWUgaW4gdGhlIFVLIHRvIGRlbGl2ZXIg cHVibGljIHNhZmV0eSBjb21tdW5pY2F0aW9ucyBmb3IgdGhlIDMgRW1lcmdlbmN5IFNlcnZpY2Vz LiBTcGVjaWZpY2FsbHkgSSBoYXZlIG92ZXJzaWdodCBvbiBzdGFuZGFyZHMgYW5kIGFzc3VyaW5n IFB1YmxpYyBTYWZldHkNCiBGdW5jdGlvbmFsaXR5IGluIG91ciBmdXR1cmUgZGVwbG95bWVudC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGludHJvZHVjZWQgdGhlIEFtYmllbnQgbGlz dGVuaW5nIHJlcXVpcmVtZW50cyBpbiAzR1BQLCBhcyB0aGlzIGlzIG9uZSBvZiBvdXIgcHJvZ3Jh bW1l4oCZcyB1c2VyIHJlcXVpcmVtZW50cyAuIEFzIG1lbnRpb25lZCBwcmV2aW91c2x5IG9uIHRo ZSB0aHJlYWQgdGhpcyByZXBsaWNhdGVzIGV4aXN0aW5nIFRFVFJBDQogZnVuY3Rpb25hbGl0eSBk ZXBsb3llZCBpbiBvdXIgY3VycmVudCBuYXRpb253aWRlIFRFVFJBIG5ldHdvcmsuIFRoaXMgaXMg dXNlZCBmb3IgZW1lcmdlbmN5IHNlcnZpY2UgdXNlcnMgaW4gZGlzdHJlc3MgYW5kIGlzIGFsc28g dXNlZCB0byBlbmFibGUgcHJvZmVzc2lvbmFsIGludmVzdGlnYXRpb25zLiBUaGlzIGZ1bmN0aW9u YWxpdHkgaXMNCjx1PnZlcnk8L3U+IHN0cmljdGx5IGNvbnRyb2xsZWQgd2l0aGluIGEgcHVibGlj IHNhZmV0eSBlbnZpcm9ubWVudCAodGhpbmsgc3lzdGVtIGFkbWlucyBmb3IgdXNlciBvcmdhbmlz YXRpb25zKSAsYXMgaXQgYWxzbyBoYXMgcGVyc29uYWwgY29uc2lkZXJhdGlvbnMgdGhlcmUsIGJl Y2F1c2Ugc29tZSB3aWxsIGhhdmUgZGVkaWNhdGVkIGRldmljZXMgdGhhdCB0aGV5IGRvbuKAmXQg aGFuZCBpbiBhdCB0aGUgZW5kIG9mIHRoZSB3b3JraW5nIGRheS4gVGhpcw0KIHNob3VsZCBiZSB2 aWV3ZWQgaW4gdGhlIHNhbWUgY29udGV4dCBhcyB0aGUgcHJvZmVzc2lvbmFsIHRvb2xzIHdlIGFs bCB1c2UgZXZlcnkgZGF5IChJIGV4cGVjdCB0aGF0IHRoaXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5l ZCBieSBteSBvcmdhbmlzYXRpb24gdG8gaGVscCBndWFyZCBhZ2FpbnN0IGFuZCBpbnZlc3RpZ2F0 ZSBtaXNjb25kdWN0KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UmljaGFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0 Y2gtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGF2aWQgVmlhbW9udGU8 YnI+DQo8Yj5TZW50OjwvYj4gMTkgSnVseSAyMDE2IDA4OjU1PGJyPg0KPGI+VG86PC9iPiBDaHJp c3RlciBIb2xtYmVyZzxicj4NCjxiPkNjOjwvYj4gZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtkaXNwYXRjaF0gZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtbWNwdHQt cnAtbmFtZXNwYWNlLTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5KdXN0IGFkZGluZyBzb21lIGNvbnRleHQgd2l0aG91dCBlbnRlcmluZyB0aGUgdGVjaG5p Y2FsIGRpc2N1c3Npb246IGluIHBhcnRpY3VsYXIsIHRoaXMgZmVhdHVyZSBpcyBhbHNvIGF2YWls YWJsZSBpbiBzb21lIG9mIHRoZSB0cmFkaXRpb25hbCByYWRpbyBzeXN0ZW1zIHRoYXQgUHVibGlj IFNhZmV0eSBhbmQgRmlyc3QgUmVzcG9uZGVycyBhcmUgdXNpbmcgdG9kYXkuIFNpbmNlIE1DUFRU IGlzIGludGVuZGVkDQogdG8gZW11bGF0ZSBhbmQgZXZlbnR1YWxseSByZXBsYWNlIHRob3NlIHN5 c3RlbXMgaW4gdGhlIGZ1dHVyZSwgdGhlIGludGVudGlvbiBpcyB0aGF0IGl0IHNob3VsZCBiZSBh YmxlIHRvIG1pbWljayBzdWNoIGZlYXR1cmVzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGFjaW5nIHNhaWQgdGhpcywgbGlrZSB3aXRoIG1hbnkgdGVjaG5p Y2FsIHNvbHV0aW9ucywgd2F5cyB0byBtaXN1c2UgdGhlIGNhcGFiaWxpdHkgd2lsbCBjZXJ0YWlu bHkgZXhpc3QuIExldCdzIGhvcGUgdGhhdCBoYXZpbmcgdGhlIGNhcGFiaWxpdHkgZGV2ZWxvcGVk IGJhc2VkIG9uIG9wZW4gc3RhbmRhcmRzIG1heSBhbGxvdyBmb3IgY29udHJvbGxpbmcgaXQgaW4g YSBtb3JlIHRyYW5zcGFyZW50IHdheSB0aGFuDQogdmVuZG9ycyBpbXBsZW1lbnRpbmcgdGhlaXIg b3duIHNvbHV0aW9ucyBlYWNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwgMTksIDIwMTYgYXQgNjozNyBBTSwgQ2hy aXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxi cj4NCjxicj4NCiZndDsmZ3Q7Jmd0OyBUaGUgcGVyc29uIHRvIHdob20geW91IG1ha2UgdGhlIGF1 dG8tYW5zd2VyIGNhbGwgbmVlZHMgdG8gYXV0aG9yaXplPGJyPg0KJmd0OyZndDsmZ3Q7IHlvdSB0 byBtYWtlIHN1Y2ggY2FsbHMgdG8gdGhhdCBwZXJzb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBUaGUgc2VydmljZSBkb2VzIE5PVCBhbGxvdyBvbmUgdG8gbWFrZSBhdXRvLWFuc3dlciBj YWxscyB0byAmcXVvdDthbnlvbmUmcXVvdDsuPGJyPg0KJmd0Ozxicj4NCiZndDsgQW5kIHRoYXQg YXV0aG9yaXphdGlvbiBpcyBwZXJmb3JtZWQgYnkgdGhlIHVzZXIsIGluIHRoZSBkZXZpY2U/IChO b3QgaW4gdGhlIG5ldHdvcmsuKSBBbmQgdGhpcyBjYW4ndCBiZTxicj4NCiZndDsgcHJlY29uZmln dXJlZCBieSB0aGUgU1AgYXMgcGFydCBvZiBkZXZpY2UgcHJvdmlzaW9uaW5nPyAoQXQgdGhlIHNh bWUgdGltZSB0aGV5IHByZWluc3RhbGwgYWxsIHRob3NlIGFwcHM8YnI+DQomZ3Q7IHVzZXJzIGRv bid0IHdhbnQgYW5kIGNhbid0IHJlbW92ZS4pPGJyPg0KPGJyPg0KVXNlcnMgbmVlZCB0byBiZSBh dXRob3JpemVkIGluIG9yZGVyIHRvIHVzZSB0aGUgTUNQVFQgc2VydmljZSB0byBiZWdpbiB3aXRo ICh3aXRoIG9yIHdpdGhvdXQgYXV0by1hbnN3ZXIpLiBNQ1BUVCBpcyBOT1QgYSBzZXJ2aWNlIHRo YXQgdGhlICZxdW90O2F2ZXJhZ2UgY29uc3VtZXImcXVvdDsgY2FuIGp1c3QgZG93bmxvYWQvcHJl aW5zdGFsbCwgc2lnbi11cCBmb3IgYW5kIHN0YXJ0IHVzaW5nLiBNQ1BUVCBpcyBhICZxdW90O3Rv b2wmcXVvdDsgdGhhdCBjYW4gYmUgdXNlZCBieSBhdXRob3JpemVkDQogcHJvZmVzc2lvbmFscyAo ZmlyZSBmaWdodGVycywgZmlyc3QgcmVzcG9uZGVycywgZXRjLi4uKSB3aGVuIHBlcmZvcm1pbmcg dGhlaXIgd29yay48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxicj4NCjxicj4N Cjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IGRp c3BhdGNoIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmci PmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgT2xsZSBFLjxicj4N CiZndDsgSm9oYW5zc29uPGJyPg0KJmd0OyBTZW50OiAxOCBKdWx5IDIwMTYgMjE6MDc8YnI+DQom Z3Q7IFRvOiBET0xMWSwgTUFSVElOIEMgJmx0OzxhIGhyZWY9Im1haWx0bzptZDMxMzVAYXR0LmNv bSI+bWQzMTM1QGF0dC5jb208L2E+Jmd0Ozxicj4NCiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpk aXNwYXRjaEBpZXRmLm9yZyI+ZGlzcGF0Y2hAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0 OiBSZTogW2Rpc3BhdGNoXSBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1tY3B0dC1ycC1uYW1lc3Bh Y2UtMDE8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IE9uIDE4IEp1bCAyMDE2LCBh dCAxOTo1OSwgRE9MTFksIE1BUlRJTiBDICZsdDs8YSBocmVmPSJtYWlsdG86bWQzMTM1QGF0dC5j b20iPm1kMzEzNUBhdHQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBDYW5ub3Qgb2NjdXIuPGJyPg0KJmd0OyBEb2VzIHRoZSBwcm90b2NvbCBwcm9oaWJpdCB0 aGF0PyBIb3c/IEZvciBhbGwgdXNhZ2VzIGluIGFsbCBpbXBsZW1lbnRhdGlvbnM/PGJyPg0KJmd0 Ozxicj4NCiZndDsgL088YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE1hcnRpbiBDIERvbGx5 PGJyPg0KJmd0OyZndDsgTGVhZCBNZW1iZXIgb2YgVGVjaG5pY2FsIFN0YWZmPGJyPg0KJmd0OyZn dDsgQ29yZSAmYW1wOyBHb3Zlcm5tZW50L1JlZ3VsYXRvcnkgU3RhbmRhcmRzIEFUJmFtcDtUPGJy Pg0KJmd0OyZndDsgQ2VsbDogPGEgaHJlZj0idGVsOjYwOS05MDMtMzM2MCI+NjA5LTkwMy0zMzYw PC9hPjxicj4NCiZndDsmZ3Q7IEVtYWlsOiA8YSBocmVmPSJtYWlsdG86bWQzMTM1QGF0dC5jb20i Pm1kMzEzNUBhdHQuY29tPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIEp1 bCAxOCwgMjAxNiwgYXQgMTo0MiBQTSwgUGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86 cGt5eml2YXRAYWx1bS5taXQuZWR1Ij5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhlIGtleSBxdWVzdGlvbiB0 byBhbnN3ZXIgaXM6IEhvdyBjYW4gYSAqdXNlcioga25vdyBpdCB3b24ndCBiZSBlbmFibGVkIG9u IGhpcyBkZXZpY2U/PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZu YnNwO1RoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7UGF1bDxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgT24gNy8xOC8xNiAxOjM2IFBNLCBPbGxlIEUu IEpvaGFuc3NvbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgT24gMTggSnVsIDIwMTYsIGF0IDE4OjU5LCBBbmRyZXcgQWxsZW4gJmx0OzxhIGhy ZWY9Im1haWx0bzphYWxsZW5AYmxhY2tiZXJyeS5jb20iPmFhbGxlbkBibGFja2JlcnJ5LmNvbTwv YT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzph YWxsZW5AYmxhY2tiZXJyeS5jb20iPmFhbGxlbkBibGFja2JlcnJ5LmNvbTwvYT4mZ3Q7Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgRWtyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNQ1BUVCB1c2VzIFJGQyA1MzczIGZvciBhdXRvIGFu c3dlciB0cmlnZ2VyaW5nIGFuZCBpcyB3aGF0IGVuYWJsZXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyB0aGUgZmVhdHVyZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFRoYXQgUkZDIGRlc2NyaWJlcyBpbiBkZXRhaWwgdGhlIHNlY3VyaXR5L3By aXZhY3kgY29uY2VybnMgd2l0aDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGF1dG8gYW5zd2Vy aW5nIGFuZCB0aGUgJnF1b3Q7YnVnIG15IHBob25lJnF1b3Q7IGF0dGFjay48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBhbWJpZW50IGxpc3Rl bmluZyBtb2RlIGlzIGZvciBmaXJzdCByZXNwb25kZXJzIHN1Y2ggYXMgcG9saWNlPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgYW5kIGZpcmUgZmlnaHRlcnMgaW4gc2l0dWF0aW9ucyB3aGVuIHRo ZXkgYXJlIGluanVyZWQgZXRjLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgVGhpcyBtb2RlIHdvdWxkIG5vdCBiZSBlbmFibGVkIGluIGNvbW1lcmNp YWwgYXBwbGljYXRpb25zLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSG93IGNhbiB5b3UgYmUgc3Vy ZSB0aGF0IG5vIG9uZSB3aWxsIGZpbmQgYW55IHVzZSBjYXNlIGZvciB0aGF0PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBtb2RlIG91dHNpZGUgYmx1ZSBsaWdodCBhcmVhcz88YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAvTzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQW5kcmV3PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqRnJvbToqIGRpc3BhdGNoIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmciPmRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSAqT24gQmVoYWxmIE9mPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgKkRP TExZLCBNQVJUSU4gQzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpTZW50OiogTW9uZGF5LCBK dWx5IDE4LCAyMDE2IDExOjAwIEFNPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgKlRvOiogRXJp YyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29t PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNv bTwvYT4mZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICpDYzoqIERJU1BBVENIICZs dDs8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciPmRpc3BhdGNoQGlldGYub3JnPC9h PiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZyI+ZGlzcGF0Y2hA aWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAqU3ViamVjdDoq IFJlOiBbZGlzcGF0Y2hdPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtaG9sbWJlcmct ZGlzcGF0Y2gtbWNwdHQtcnAtbmFtZXNwYWNlLTAxPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNQyBpcyBmb3IgTWlzc2lvbiBDcml0aWNhbCBjb21t dW5pY2F0aW9ucywgbm90IGZvciBjb21tZXJjaWFsIHVzZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBXZSB3b3VsZCBuZXZlciBleHBlY3QgdGhpcyBmcm9tIGEgY29uc3VtZXIgVUUuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNYXJ0aW4gQyBE b2xseTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IExlYWQgTWVtYmVyIG9mIFRlY2huaWNhbCBT dGFmZjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENvcmUgJmFtcDsgR292ZXJubWVudC9SZWd1 bGF0b3J5IFN0YW5kYXJkcyBBVCZhbXA7VDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENlbGw6 IDxhIGhyZWY9InRlbDo2MDktOTAzLTMzNjAiPjYwOS05MDMtMzM2MDwvYT48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBFbWFpbDogPGEgaHJlZj0ibWFpbHRvOm1kMzEzNUBhdHQuY29tIj5tZDMx MzVAYXR0LmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bWQzMTM1QGF0dC5jb20i Pm1kMzEzNUBhdHQuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgT24gSnVsIDE4LCAy MDE2LCBhdCAxMDo0NyBBTSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBy dGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsm Z3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7ICZuYnNwO09uIE1vbiwgSnVsIDE4LCAyMDE2IGF0IDQ6MTYgUE0sIERhbGUgUi4gV29y bGV5PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Im1h aWx0bzp3b3JsZXlAYXJpYWRuZS5jb20iPndvcmxleUBhcmlhZG5lLmNvbTwvYT4gJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86d29ybGV5QGFyaWFkbmUuY29tIj53b3JsZXlAYXJpYWRuZS5jb208 L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0VyaWMgUmVzY29ybGEgJmx0 OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT4gJmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0OyZndDsg d3JpdGVzOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbmUgb2YgdGhlICZxdW90O2Zl YXR1cmVzJnF1b3Q7IHRoYXQgdGhpcyBjbGFpbXMgdG8gYmUgZW5hYmxlIGlzOjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmcXVvdDtBbWJpZW50IExpc3RlbmluZyZxdW90Oywgd2hpY2gg c2VlbXMgdG8gYmUgaGF2aW5nIHRoZSBkZXZpY2U8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N0YXJ0IHJlY29yZGluZzxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB0aGUgZW52aXJvbm1lbnQgd2l0aG91dCB1c2VyIGNvbnNlbnQgb3IgaW5k aWNhdGlvbi4gVGhpczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7c2VlbXMgbGlrZSBhbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbnRp LWZlYXR1cmUsIGVzcGVjaWFsbHkgaW4gY29uc3VtZXIgZGV2aWNlcy48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7QXMgZmFyIGFzIEkgY2FuIHRlbGwsICZxdW90O0FtYmllbnQgTGlzdGVuaW5nJnF1b3Q7 IGlzIGEgZmVhdHVyZSBvZjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7TUNQVFQsIGFuZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7d2hpbGUgdGhlIHdvcmsgaW4gZHJhZnQtaG9sbWJlcmctZGlzcGF0 Y2gtbWNwdHQtcnAtbmFtZXNwYWNlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtpcyBuZWVkZWQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2J5IE1DUFRULCB0aGUgZHJhZnQgaXMgbm90IHN1ZmZpY2ll bnQgdG8gZW5hYmxlICZxdW90O0FtYmllbnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0xpc3RlbmluZyZxdW90Oy48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZSBvbmx5IGFyZ3VtZW50IEkgY2Fu IHNlZSBhZ2FpbnN0IHByb2NlZWRpbmcgd2l0aCB0aGUgZHJhZnQ8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lzIGlmIHdlPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3YW50ZWQgdG8gcmVqZWN0IHRo ZSBkcmFmdCBzcGVjaWZpY2FsbHkgdG8gcHJldmVudCBNQ1BUVCBmcm9tPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZWluZzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW1wbGVtZW50ZWQgYmVjYXVz ZSB3ZSBkaWRuJ3QgbGlrZSB0aGUgJnF1b3Q7QW1iaWVudCBMaXN0ZW5pbmcmcXVvdDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ZlYXR1cmUgb2Y8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01DUFRU Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDtZZXMsIHRoYXQncyB3aGF0IEknbSBz dWdnZXN0aW5nLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QW5kIGl0IGRvZXMgYXBwZWFyIHRoYXQgM0dQUCBp cyBhd2FyZSBvZiB0aGUgcHJpdmFjeTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7aW1wbGljYXRpb25zIG9mPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtBbWJpZW50IExpc3RlbmluZyZxdW90 Ozo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNQ1BUVCBpcyBwcmltYXJpbHkgdGFyZ2V0 aW5nIHRvIHByb3ZpZGUgYSBwcm9mZXNzaW9uYWwgUHVzaDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VG8gVGFsazxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzZXJ2aWNlIHRvIGUuZy4s IHB1YmxpYyBzYWZldHksIHRyYW5zcG9ydCBjb21wYW5pZXMsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1dGlsaXRpZXMgb3I8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5kdXN0cmlh bCBhbmQgbnVjbGVhciBwbGFudHMuJm5ic3A7IEluIGFkZGl0aW9uIHRvIHRoaXMgYTxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29tbWVyY2lhbCBQ VFQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgc2VydmljZSBmb3Igbm9uLXByb2Zlc3Npb25hbCB1c2UgKGUuZy4sIGdyb3VwcyBvZiBw ZW9wbGUgb248YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2hvbGlkYXkpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IG1heSBiZSBkZWxpdmVyZWQgdGhyb3VnaCBhbiBNQ1BUVCBzeXN0ZW0u Jm5ic3A7IEJhc2VkIG9uIHRoZWlyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtvcGVyYXRpb25hbDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtb2RlbCwgdGhlIHBlcmZvcm1hbmNlIGFu ZCBNQ1BUVCBmZWF0dXJlcyBpbiB1c2UgdmFyeSBwZXIgdXNlcjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvcmdhbml6YXRpb24sIHdo ZXJlIGZ1bmN0aW9uYWxpdHkgd2hpY2ggaXMgbW9yZSBtaXNzaW9uPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjcml0aWNhbDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzcGVjaWZpYyAo ZS5nLiwgQW1iaWVudCBMaXN0ZW5pbmcgYW5kIEltbWluZW50IFBlcmlsIENhbGwpPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttaWdodCBub3Q8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg YmUgYXZhaWxhYmxlIHRvIGNvbW1lcmNpYWwgY3VzdG9tZXJzLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDtJIGZvdW5kIHRoaXMgc2VjdGlvbiBmYWlybHkgdW5jbGVhciBhcyB0byB3 aGVuIHRoZXNlIGZlYXR1cmVzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7 d291bGQgYmUgYWxsb3dlZC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOy1Fa3I8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RhbGU8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDtfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwO2Rpc3BhdGNoIG1haWxpbmcgbGlzdDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRm Lm9yZyI+ZGlzcGF0Y2hAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmRp c3BhdGNoQGlldGYub3JnIj5kaXNwYXRjaEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaXNwYXRjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRpc3BhdGNoIG1h aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpkaXNw YXRjaEBpZXRmLm9yZyI+ZGlzcGF0Y2hAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIj5kaXNwYXRjaEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaXNwYXRjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciPmRpc3BhdGNoQGlldGYub3Jn PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyZndDsmZ3Q7IGRpc3BhdGNoIG1haWxpbmcgbGlzdDxicj4NCiZndDsm Z3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciPmRpc3BhdGNoQGlldGYu b3JnPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaDwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyZndDsgZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0i bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIj5kaXNwYXRjaEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3Bh dGNoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kaXNwYXRjaDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgZGlzcGF0Y2ggbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmciPmRpc3BhdGNoQGll dGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kaXNwYXRjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGRpc3Bh dGNoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmRpc3BhdGNoQGlldGYu b3JnIj5kaXNwYXRjaEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2giIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPC9hPjxicj4NCiZndDs8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCmRpc3BhdGNoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkaXNwYXRj aEBpZXRmLm9yZyI+ZGlzcGF0Y2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8L2E+PGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpk aXNwYXRjaCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5v cmciPmRpc3BhdGNoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpUaGlzIGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgYnkgdGhlIFN5bWFudGVjIEVtYWls IFNlY3VyaXR5LmNsb3VkIHNlcnZpY2UuPGJyPg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gcGxlYXNl IHZpc2l0IDxhIGhyZWY9Imh0dHA6Ly93d3cuc3ltYW50ZWNjbG91ZC5jb20iPmh0dHA6Ly93d3cu c3ltYW50ZWNjbG91ZC5jb208L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cD4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqPGJyIC8+VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRy YW5zbWl0dGVkIHdpdGggaXQgYXJlIHByaXZhdGUgYW5kIGludGVuZGVkPGJyIC8+c29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFk ZHJlc3NlZC48YnIgLz5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBs ZWFzZSByZXR1cm4gaXQgdG8gdGhlIGFkZHJlc3M8YnIgLz5pdCBjYW1lIGZyb20gdGVsbGluZyB0 aGVtIGl0IGlzIG5vdCBmb3IgeW91IGFuZCB0aGVuIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVt LjxiciAvPlRoaXMgZW1haWwgbWVzc2FnZSBoYXMgYmVlbiBzd2VwdCBmb3IgY29tcHV0ZXIgdmly dXNlcy48L3A+PHA+KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjxiciAvPjwvcD48cD4qKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9wPgo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_1E80BA6F6526374AA13EF37036BEEDBA9303F04Bsdccmm8017Poise_-- From nobody Wed Jul 20 09:14:00 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E7812D83D; Wed, 20 Jul 2016 09:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 DUk2kHO-iw4X; Wed, 20 Jul 2016 09:13:56 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C3712D52F; Wed, 20 Jul 2016 09:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4336; q=dns/txt; s=iport; t=1469031236; x=1470240836; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GS/kQQT6TAspEGDCVR0d2PbEaUmD7SYraby7s32bTnY=; b=J2hr7Kv+MrZ98R97SU/oyop/NbDAIY0G+blJwAhS01XWutOBqlKsqcuy yBes42WYH15K+DIr3VwCZTeNAXvCDAJf3zxuQJGt9MLR47UMlZjYxxjr9 EpmvylUtbm9A8WMJVuv1FfmyQWXvZHM5LhiT/KNRZsK3hXXdqlsQDbgSA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAgDXoo9X/5xdJa1dgz9WfAa4VoF6I?= =?us-ascii?q?oUuSgIcgRc4FAEBAQEBAQFlJ4RcAQEEAQEBIRE3AwsFCwIBCBgCAiYCAgIlCxU?= =?us-ascii?q?QAgQOBYgoCA6vV41gAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYUpgXgIgk2EK?= =?us-ascii?q?haDASuCLwWZJgGOYYFsiAmFRJAfAR42g3Nuhih/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,395,1464652800"; d="scan'208";a="300229741" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 16:13:42 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6KGDgNK025547 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 16:13:42 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 11:13:42 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 11:13:42 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Ben Campbell Thread-Topic: [dispatch] Ops Directorate review of draft-pd-dispatch-msrp-websocket-12 Thread-Index: AQHR0vjWEmY7TvkZWUWZFVDYVLHs4KACsFqAgB9A4QA= Date: Wed, 20 Jul 2016 16:13:42 +0000 Message-ID: <6830AF63-9640-43D2-9728-8AD876D29D9B@cisco.com> References: <71C83619-87E7-4C92-83A0-3834A6B6931C@cisco.com> <527B64C7-DB2C-49DA-9AD5-5DE420513816@nostrum.com> In-Reply-To: <527B64C7-DB2C-49DA-9AD5-5DE420513816@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.171.33] Content-Type: text/plain; charset="utf-8" Content-ID: <4380C44B93FDDA499FFB22099A4E8FCD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ops-dir@ietf.org" , "dispatch@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@ietf.org" , "Fred Baker \(fred\)" Subject: Re: [dispatch] Ops Directorate review of draft-pd-dispatch-msrp-websocket-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:13:58 -0000 SGkgQmVuIC0gDQoNCkhhdmVu4oCZdCBoZWFyZCBmcm9tIEFsZXhleSBvbiB0aGlzLCBidXQgd2Ug YXJlIGluIGFncmVlbWVudCB3aXRoIHlvdSwgQmVuLiAgSSBzZWUgbm8gbmVlZCB0byBtYWtlIHJl ZmVyZW5jZXMgdG8gVExTIDEuMyBvciBIVFRQLzIuICBJbiBmYWN0LCBJIGRvbuKAmXQgc2VlIGEg bmVlZCB0byB0d2VhayB0aGUgdGV4dC4NCg0KR29uemFsbw0KDQoNCj4gT24gSnVuIDMwLCAyMDE2 LCBhdCA4OjU3IFBNLCBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4gd3JvdGU6DQo+IA0K PiBIaSBGcmVkLCB0aGFua3MgZm9yIHlvdXIgcmV2aWV3IQ0KPiANCj4gSSB0aGluayB0aGVyZSBt YXkgYmUgcm9vbSBmb3IgdHVuaW5nIHRoZSBsYW5ndWFnZSBhbmQgY2l0YXRpb25zIGEgYml0IChJ IHdpbGwgbGV0IHRoZSBhdXRob3JzIGFkZHJlc3MgZGV0YWlscyksIGJ1dCB0aGUgdGV4dCB0aGF0 IHlvdSBxdW90ZSBpcyBpbnRlbmRlZCBhcyBhbiBvdmVydmlldyBvZiBXZWJTb2NrZXQsIG5vdCBu b3JtYXRpdmUgdGV4dCBhYm91dCBob3cgeW91IGRvIE1TUlAgb3ZlciBXZWJTb2NrZXQuIEkgdGhp bmsgdGhlIGJlc3QgdGhhdCBfdGhpc18gZHJhZnQgY2FuIGRvIGlzIGRlc2NyaWJlIFdlYlNvY2tl dCBhcyBpdCBleGlzdHMgbm93LiBOb3RoaW5nIGluIHRob3NlIHNlY3Rpb25zIHNob3VsZCBiZSB0 YWtlbiB0byBjb25zdHJhaW4gaG93IFdlYlNvY2tldCBtaWdodCBiZSB1cGRhdGVkIHRvIGFkYXB0 IHRvIHRoaW5ncyBsaWtlIFRMUyAxLjMgb3IgSFRUUC8yLg0KPiANCj4gQWxleGV5OiBBbnkgdGhv dWdodHMgb24gdGhpcyBmcm9tIHRoZSBwZXJwZWN0aXZlIG9mIGFuIFJGQyA2NDU1IGF1dGhvcj8N Cj4gDQo+IFRoYW5rcyENCj4gDQo+IEJlbi4NCj4gDQo+IE9uIDMwIEp1biAyMDE2LCBhdCAxMjo1 NywgRnJlZCBCYWtlciAoZnJlZCkgd3JvdGU6DQo+IA0KPj4gSSBhbSByZXZpZXdpbmcgdGhpcyBk b2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBPcGVyYXRpb25hbCBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcg ZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRo ZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9mIGlt cHJvdmluZyB0aGUgb3BlcmF0aW9uYWwgYXNwZWN0cyBvZiB0aGUgSUVURiBkcmFmdHMuIENvbW1l bnRzIHRoYXQgYXJlIG5vdCBhZGRyZXNzZWQgaW4gbGFzdCBjYWxsIG1heSBiZSBpbmNsdWRlZCBp biBBRCByZXZpZXdzIGR1cmluZyB0aGUgSUVTRyByZXZpZXcuIERvY3VtZW50IGVkaXRvcnMgYW5k IFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQo+PiANCj4+IEkgaGF2ZSBhIGZldyBxdWVzdGlvbnMgcmVn YXJkaW5nIHRoZSBkb2N1bWVudC4gTXkgcGVyY2VwdGlvbiwgd2hpY2ggbWF5IG9yIG1heSBub3Qg YmUgY29ycmVjdCwgaXMgdGhhdCBpdCB0YXJnZXRzIGRvd24tcmV2IHByb3RvY29scyAtIGh0dHAv cyAxLjEgYW5kIFRMUyAxLjIsIHRoZSBmb3JtZXIgb2Ygd2hpY2ggaGFzIGJlZW4gb2Jzb2xldGVk IGFuZCByZXBsYWNlZCBhbmQgdGhlIGxhdHRlciBpcyAoSSdtIHRvbGQpIGFib3V0IHRvIGJlLiBJ J20gZmluZSB3aXRoIGhhdmluZyB0aG9zZSBhcyBvcHRpb25zLCBidXQgaXQgc2VlbXMgbGlrZSBw dWJsaXNoaW5nIHRoaXMgd2l0aG91dCByZWZlcmVuY2VzIHRvIHRoZSBjdXJyZW50IHRlY2hub2xv Z3kgbWVhbnMgdGhhdCBpdCB3aWxsIG5lZWQgdG8gYmUgdXBkYXRlZCBvciByZXBsYWNlZCBzb29u IHdpdGggYSBkb2N1bWVudCB0aGF0IGRvZXMuDQo+PiANCj4+IE5vdGUgdGhhdCBJIGFtIG5vdCBy ZWdpc3RlcmluZyB0aGVzZSBhcyBvYmplY3Rpb25zOyBJIHRoaW5rIHRoaXMgaXMgYSBjb252ZXJz YXRpb24gdGhhdCBuZWVkcyB0byBiZSBoYWQsIGJ1dCBpZiB0aGUgY29uc2Vuc3VzIG9mIHBlb3Bs ZSBtb3JlIGV4cGVydCB0aGFuIG15c2VsZiBpbiB0aGlzIHRlY2hub2xvZ3kgaXMgdG8gc3RheSBk b3duLXJldiwgSSdtIE9LIHdpdGggaXQuDQo+PiANCj4+PiAxLiAgSW50cm9kdWN0aW9uDQo+Pj4g DQo+Pj4gICBUaGUgV2ViU29ja2V0IFtSRkM2NDU1XSBwcm90b2NvbCBlbmFibGVzIG1lc3NhZ2Ug ZXhjaGFuZ2UgYmV0d2Vlbg0KPj4+ICAgY2xpZW50cyBhbmQgc2VydmVycyBvbiB0b3Agb2YgYSBw ZXJzaXN0ZW50IFRDUCBjb25uZWN0aW9uIChvcHRpb25hbGx5DQo+Pj4gICBzZWN1cmVkIHdpdGgg VExTIFtSRkM1MjQ2XSkuICBUaGUgaW5pdGlhbCBwcm90b2NvbCBoYW5kc2hha2UgbWFrZXMNCj4+ PiAgIHVzZSBvZiBIVFRQIFtSRkM3MjMwXSBzZW1hbnRpY3MsIGFsbG93aW5nIHRoZSBXZWJTb2Nr ZXQgcHJvdG9jb2wgdG8NCj4+PiAgIHJldXNlIGV4aXN0aW5nIEhUVFAgaW5mcmFzdHJ1Y3R1cmUu DQo+PiANCj4+IEkgdW5kZXJzdGFuZCBIVFRQIDEuMSAod2hpY2ggaXMgdG8gc2F5ICJwaXBlbGlu ZWQgVENQIiksIGJ1dCBJIHdhcyBzdXJwcmlzZWQgdG8gbm90IHJlYWQgYWJvdXQgUkZDIDc1NDAg SFRUUCAyLjAgKFNlY3VyZSBUQ1ApLiBJcyB0aGVyZSBhIHJlYXNvbiB0byBub3QgYWxsb3cgZm9y IHRoZSBsYXR0ZXIsIGF0IGxlYXN0IGFzIGFuIG9wdGlvbj8NCj4+IA0KPj4+IDMuICBXZWJTb2Nr ZXQgUHJvdG9jb2wgT3ZlcnZpZXcNCj4+PiANCj4+PiAgIFRoZSBXZWJTb2NrZXQgcHJvdG9jb2wg W1JGQzY0NTVdIGlzIGEgdHJhbnNwb3J0IGxheWVyIG9uIHRvcCBvZiBUQ1ANCj4+PiAgIChvcHRp b25hbGx5IHNlY3VyZWQgd2l0aCBUTFMgW1JGQzUyNDZdKSBpbiB3aGljaCBib3RoIGNsaWVudCBh bmQNCj4+PiAgIHNlcnZlciBleGNoYW5nZSBtZXNzYWdlIHVuaXRzIGluIGJvdGggZGlyZWN0aW9u cy4NCj4+IA0KPj4gSXMgdGhpcyBleHRlbnNpYmxlIHRvIFRMUyAxLjMsIHdoaWNoIEknbSB0b2xk IGlzIGluIHRoZSBvZmZpbmc/IFRoYXQgd291bGQgb2Jzb2xldGUgUkZDIDUyNDYuDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBkaXNwYXRj aCBtYWlsaW5nIGxpc3QNCj4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KDQo= From nobody Fri Jul 22 02:19:58 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C26A12D1D8 for ; Fri, 22 Jul 2016 02:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=QDgmbBtU; dkim=pass (1536-bit key) header.d=taugh.com header.b=SfgmoNsF 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 fe-Gz0vCsfYc for ; Fri, 22 Jul 2016 02:19:55 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B544612DBCD for ; Fri, 22 Jul 2016 02:19:54 -0700 (PDT) Received: (qmail 4968 invoked from network); 22 Jul 2016 09:19:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=1366.5791e539.k1607; bh=fj2NkgaqARisHzQ3cCczko01mVuCKcrogGrUB8biIFo=; b=QDgmbBtUU2VZdUByuSboJEQELd1lnFpRRvaHSFYyQPSXY7PTSXSJ826e6U+w547s1cPGQgMOfoYGlQgghQRQQbvoMl3qamPrggPFpOq60VV6T7j4uzr1Z4vd8O39xcH6pWI/TWqQaqQ39y64FgCc67IOxOPDzMiSMbaG2g3gG+yS0Matxp9BNb5+UNvNaPF0Hdfyu8A7A7ILUhG3UKI+dtTL4IWTtyV4+0MujcHsK4qZaSMpXmImxJbo2gZadG/O DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=1366.5791e539.k1607; bh=fj2NkgaqARisHzQ3cCczko01mVuCKcrogGrUB8biIFo=; b=SfgmoNsFm5icLhpA+77z3dfsm8TRqE0XSmNuHpXWSGMt/rWLh+Cs1JESV1WSb70VqXFoAE7hn/aXVnyiiW3ga2jCqaU3BngV/OUpw05LuvNh9B3AZ6Gig5ltgINYBI4mIk0S3LubHMo7POi9aXRIuihDcRjkWXdUzy8GOGGsd4+FQQK22oUqDrv8sFbYP2LarthT/iYgB2mFcnL1t9PeBJGbhoR/s+lj/aZbtMQQZnGZK8vNqMGs0s1W5jNPMRxg Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 22 Jul 2016 09:19:53 -0000 Date: 22 Jul 2016 11:19:51 +0200 Message-ID: From: "John R Levine" To: "Dispatch WG" User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [dispatch] Please dispatch draft-levine-herkula-oneclick-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 09:19:56 -0000 We've made a few minor changes after talking to people who plan to implement this. I gather that AD sponsored seems the most plausible path, so could the powers that be nudge it that way? Thanks. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Jul 22 03:54:33 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DCC12DA1B for ; Fri, 22 Jul 2016 03:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=7VN9UeDA; dkim=pass (1536-bit key) header.d=taugh.com header.b=RVmISO0g 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 5oHJLEdZ9j4b for ; Fri, 22 Jul 2016 03:54:29 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E42912DC38 for ; Fri, 22 Jul 2016 03:54:29 -0700 (PDT) Received: (qmail 25241 invoked from network); 22 Jul 2016 10:54:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=6298.5791fb63.k1607; bh=ZEdw5OAYRULy4nsajY5xjRG+c4w9v0YDFOGm5uS7UsU=; b=7VN9UeDA6tNHMET+sTqZ/gXwUq+4eplcRXEZ1FLT9oSq5NjzN//Y/1/2euUN1a2zoRxzBDYZ7owUE6JUFDie4sRRBAUPa4GUnyX4s/m0NRIr7IcwKj9ySDOxNi1eJIUi3AM0RIVx3Qup55g9KR66avlx1i4wmf8LNHvEdG1T5g5h6sMQU+y5OUdvGPBvf4KJDcyPaeQ+81A9w44CnpEO2leeLaxnlQjLV5rJDXrOszx8YBj0m/CHYUZFtOKpZRwH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=6298.5791fb63.k1607; bh=ZEdw5OAYRULy4nsajY5xjRG+c4w9v0YDFOGm5uS7UsU=; b=RVmISO0glieHC1u4MP44JywXcyP9QFlkVUNrAsKgWXjNp5dFHcpLzjyoY3U2NiaLtNzJFLC2nwj3Li2UUXpXExWf00U4xcRANIrIyZS9KpJGvqNFx5JFBJPNd0tKmD65H8RXWTZ6aMtuDqvrxUnZdXDMwBTD78fZRLNKPJo1OojqIrzad0ZHsQWnm5EmuRs6xy4tyhFgbBL6w/R12Oa4X/BdHUKHD/keTTgHwl37FCnb4GwsE3bXE4nbah3u3+ge Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 22 Jul 2016 10:54:27 -0000 Date: 22 Jul 2016 12:54:26 +0200 Message-ID: From: "John R Levine" To: "Dispatch WG" User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 10:54:31 -0000 The WG seemed OK with it. After talking to people who plan to implement it I updated the draft with some editing fixes and a longer security section. This also seems appropriate for AD sponsored, please. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Jul 22 05:50:40 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5E812D192 for ; Fri, 22 Jul 2016 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tEYN3WJpTv0J for ; Fri, 22 Jul 2016 05:50:37 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 9C41612D75D for ; Fri, 22 Jul 2016 05:50:36 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id s63so100153216qkb.2 for ; Fri, 22 Jul 2016 05:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TjSCkQ5M94N15coV6pEu5tLc7hIvVvmm4P5uYeCwL68=; b=EzZh9J6k49zJP7MOyZySCTGGNmLSB/K/0SwR+7446oJTrar570bu7TtDOLYYfKTm5E Y5RfWo3Ens3vgSTpmAHzLsJ/2aP4BrLQXWW/8h7Z3oEwmW1ljHaH3kGxSk0p3xUH4+I2 nDqzUpEw4GQ3TPYoNud/fc3Zmpmegp5HpkzNQxtGExM8oyl8forJtG9Hkf6SPgiLrluX jvRxcTJCI7qtJgVgMGIO3BttLGEGXBQGfminT6+rPiVBY6//rC6ujtedHpUYHwySjtJO J0pVzgzbnsKuXGRyyLp+IPXbPqk1GVPKdwocJ1pCB1PYdx18twh1Fm9zgquc0H3MXHik xSZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TjSCkQ5M94N15coV6pEu5tLc7hIvVvmm4P5uYeCwL68=; b=JXGjG6kDoD53jQtPc5Zgb7f7G8fw3knL7F0js7Tyb74ETFjzRec7pLGpWR6+sLcYwL nuoCZ2PaGVnUxMz1N06N7Kkj1gIlbyQh2T3uyZ/znYh/mqCAhJOkCjNanjjPW4PMY7Pu /LhNk72evLYxL2cTLjaKCbN/qJ3CWiFnc3lJnymSCd5QVq7yy/7aiXWDcd1reKc18iro +jVm50RYcSkCY5La0lV3IxP6pSeVCn66KjzWhgekkJ6LygDBTWhjp/RrolL6s23mTaqo IT1o8Fa7lB9hsQUEcvlUDumGfnLRNfG5jNbHqphZvFiCODlKzQ2WUFxF1+nje2sWzzyd VHWw== X-Gm-Message-State: AEkooutWbvX+vCnjcVRKF76mjEr8AqdUHKFjIMdR7FhxIoxGkqZvgE2fwGrqRwHg/Wjdyb3rxYerfbzcGqGveg== X-Received: by 10.55.147.70 with SMTP id v67mr4407185qkd.32.1469191835866; Fri, 22 Jul 2016 05:50:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Fri, 22 Jul 2016 05:50:35 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 22 Jul 2016 14:50:35 +0200 Message-ID: To: John R Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Dispatch WG Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 12:50:39 -0000 On 22 July 2016 at 12:54, John R Levine wrote: > The WG seemed OK with it. After talking to people who plan to implement it > I updated the draft with some editing fixes and a longer security section. I would like to see some thorough review of this work. AD sponsorship is not appropriate in my opinion. Primarily, there needs to be adequate security review. There are several big risks that this draft skirts and good review, and maybe even analysis, of this is important. The draft appears to violate RFC 7320. That suggests that wider review of other areas of this is needed. From nobody Fri Jul 22 09:59:04 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB7412DE66 for ; Fri, 22 Jul 2016 09:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMW4HqyvPbkP for ; Fri, 22 Jul 2016 09:59:01 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3591A12DE5D for ; Fri, 22 Jul 2016 09:59:01 -0700 (PDT) Received: (qmail 4401 invoked from network); 22 Jul 2016 16:58:59 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Jul 2016 16:58:59 -0000 Date: 22 Jul 2016 16:58:37 -0000 Message-ID: <20160722165837.11498.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 16:59:03 -0000 More review is nice, but useful review needs to be more than "I don't trust this." >Primarily, there needs to be adequate security review. There are >several big risks that this draft skirts and good review, and maybe >even analysis, of this is important. This draft describes a way to publish and retrieve S/MIME and PGP keys. The keys are the exact same ones you can get in other ways now, and the draft goes to considerable lengths to say that, just like with keys you get any other way, it's up to the client to decide how much credence to give to them. Any security problems with bogus keys are the same ones we've already been dealing with as long as there have been PGP and S/MIME. If it appears that this draft is asserting that the keys are "real" because the domain says so, it's trying very hard not to say that, so it'd help to know what was confusing. (Attempting to specify the relationship between a domain and its users is a hopeless swamp of despair where we're not going.) >The draft appears to violate RFC 7320. That suggests that wider >review of other areas of this is needed. I presume this is a reference to the URL paths in section 3. They are imported verbatim from RFC 4387 which was published ten years ago. Since they're not new, it would be helpful to clarify under what circumstances we're not allowed to use specs from existing standards track RFCs. R's, John From nobody Sat Jul 23 02:39:57 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E2712D587 for ; Sat, 23 Jul 2016 02:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JX2WIoOXxwYD for ; Sat, 23 Jul 2016 02:39:54 -0700 (PDT) Received: from smtp80.ord1c.emailsrvr.com (smtp80.ord1c.emailsrvr.com [108.166.43.80]) (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 EE14B12D1A4 for ; Sat, 23 Jul 2016 02:39:53 -0700 (PDT) Received: from smtp3.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5D332A0091 for ; Sat, 23 Jul 2016 05:39:51 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 09BC1A0088 for ; Sat, 23 Jul 2016 05:39:50 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.61.167.19] ([UNAVAILABLE]. [173.38.220.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Sat, 23 Jul 2016 05:39:51 -0400 From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_C70DA868-633C-44CE-9394-72BEB7180C52" Message-Id: <97BA2FB1-1A0F-44E0-94E7-CB6993029AAE@iii.ca> Date: Sat, 23 Jul 2016 03:39:49 -0600 To: DISPATCH list Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dispatch] comments on draft-bhjl-x509-srv-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 09:39:55 -0000 --Apple-Mail=_C70DA868-633C-44CE-9394-72BEB7180C52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I like the general idea of this and it seems very good timing as we get = close to LetsEncrypt providing free certs for email. My preference would = be for this to be general enough that it worked for other things such = and xmpp and sip that use email style addresses. They face the same = problem of how to discover the recipients certificate.=20 In the end, the security seems like it has to be based on how the sender = trying to reach fluffy@example.com decides = the certificate retrieved is valid for that user or not. I=E2=80=99d = certainly want to be able to use it in a mode where I did not need to = trust the server that cached the cert (or the HTTPS or DNS leading to = that), but as long as I got a cert signed by a trusted CA for the = correct user, then it could be used to encrypt.=20 I=E2=80=99m also a fan of the approach where if the HTTPS server has a = cert for the domain example.com , then it can use = that cert to sign the actual email certs for fluffy@example.com = .=20 Cullen --Apple-Mail=_C70DA868-633C-44CE-9394-72BEB7180C52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I like = the general idea of this and it seems very good timing as we get close = to LetsEncrypt providing free certs for email. My preference would be = for this to be general enough that it worked for other things such and = xmpp and sip that use email style addresses. They face the same problem = of how to discover the recipients certificate. 

In the end, the security = seems like it has to be based on how the sender trying to reach fluffy@example.com decides the certificate retrieved = is valid for that user or not. I=E2=80=99d certainly want to be able to = use it in a mode where I did not need to trust the server that cached = the cert (or the HTTPS or DNS leading to that), but as long as I got a = cert signed by a trusted CA for the correct user, then it could be used = to encrypt. 

I=E2=80=99m also a fan of the approach where if the HTTPS = server has a cert for the domain example.com, then it can use that cert to sign the actual = email certs for fluffy@example.com. 

Cullen




= --Apple-Mail=_C70DA868-633C-44CE-9394-72BEB7180C52-- From nobody Sat Jul 23 05:32:59 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B600912D0C5 for ; Sat, 23 Jul 2016 05:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2PJJ_UGgiL4s for ; Sat, 23 Jul 2016 05:32:56 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 42D8312B025 for ; Sat, 23 Jul 2016 05:32:56 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id 52so75334846qtq.3 for ; Sat, 23 Jul 2016 05:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1ggXuJzvpNNAnfwswpPE23c1U5WTScNpCRLNoPQQHgM=; b=TKWexOU+wyFDuBuzrGKTH+xLTxxdbPYFqK0qbPzxXZQUFPDPhuggM8of/KWPgKGdAv qdKYktAm2Hdt96jPhJzhmqYKw4O78senHRTdd77QTZa6f1d3rYra+nNpraJ+pWlb/co6 SzII43sCXeKhgR7t54oNkpVWf+DDGDUyOt4O0V1FQyKd6+5QmmiQkXMBZrqyohuAsDja IhUqRyM2ByqWPb9X8LqvtCowqlsLmpvjqDwVGQfb8GMPO32FBHSV+RRMrkfmTXfwkcAX 3TWda0UA6wb/gi8LsNc6rriYL4o0GwKkZgOz8mGMvDRD7iXFzU0hol1qm4b+G//ex2xQ sF4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1ggXuJzvpNNAnfwswpPE23c1U5WTScNpCRLNoPQQHgM=; b=SfT0TrQ/Z50vzNer42bHUJM8sqxa+hD3dQz6XchD5d0A+2KCU6yEXqC4ufQgWjhQ2X YGHQbbOp1Pl22UWrgVQVhESGaYMEgl216u533i6LCoqHU0b/dlK9PgnxoFzbJFpyVMR5 HCkEJ8N4/5pLiGUoLJeEmmnIDCnVoe6eqf5m+b2jkK24YrO7qWW1ZpZ/DxFP/Hvl/+rt Gby2zxuFklA7V8bBP9KzXdcOmNqdFee3tVh2uEaZsiDpYiBWOThdeSwpFssARejv2MUq Q9V1wez3N9ceUlT3GxyV0Rh9JzDYCU5w5nC6Mzd3uujRewwMg1OJ4YUVnPlIYqUwpkoX HONw== X-Gm-Message-State: AEkooutMXZbuQkGJtV79qjl5ZHzkIh2Xc4xlDMUvcSH5Y3OMX3t+w/KzSDWzM16OcIt464B8TEF11bW+ASw2UA== X-Received: by 10.200.50.199 with SMTP id a7mr14663945qtb.43.1469277175380; Sat, 23 Jul 2016 05:32:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sat, 23 Jul 2016 05:32:54 -0700 (PDT) In-Reply-To: <20160722165837.11498.qmail@ary.lan> References: <20160722165837.11498.qmail@ary.lan> From: Martin Thomson Date: Sat, 23 Jul 2016 14:32:54 +0200 Message-ID: To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] please dispatch draft-bhjl-x509-srv-02.xml X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 12:32:58 -0000 On 22 July 2016 at 18:58, John Levine wrote: > More review is nice, but useful review needs to be more than "I don't > trust this." I was merely reacting to the implication that this was good enough. It may well be. Consider this a promise to look at this a little more closely than I have already. From nobody Sat Jul 23 08:53:49 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC0912D501 for ; Sat, 23 Jul 2016 08:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBoB5Tcj9GnT for ; Sat, 23 Jul 2016 08:53:46 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8ECA12B050 for ; Sat, 23 Jul 2016 08:53:45 -0700 (PDT) Received: (qmail 70869 invoked from network); 23 Jul 2016 15:53:44 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jul 2016 15:53:44 -0000 Date: 23 Jul 2016 15:53:22 -0000 Message-ID: <20160723155322.14219.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org In-Reply-To: <97BA2FB1-1A0F-44E0-94E7-CB6993029AAE@iii.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: fluffy@iii.ca Subject: Re: [dispatch] comments on draft-bhjl-x509-srv-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2016 15:53:48 -0000 >I like the general idea of this and it seems very good timing as we get close to LetsEncrypt >providing free certs for email. My preference would be for this to be general enough that it worked >for other things such and xmpp and sip that use email style addresses. They face the same problem of >how to discover the recipients certificate. The cert lookup in the draft has little to do with e-mail beyond the fact that the lookup keys are (or look like) e-mail addresses. RFC 4387 only provides for S/MIME and PGP cert lookups. If you can use an S/MIME cert for xmpp or sip, perhaps that's all you need. >I’m also a fan of the approach where if the HTTPS server has a cert for the domain example.com >, then it can use that cert to sign the actual email certs for >fluffy@example.com . This is the semantic pit of despair I mentioned a few messages ago. Some domains are authoritative sources of information for their e-mail users, some aren't, and I don't see any mechanical way to tell the difference. For e-mail, the main use of a cert lookup would be to send encrypted mail to someone who's never written to you. In that scenario, between sending plain text and encrypting to a cert that might be the user's or might be a MITM from his e-mail provider, even the latter doesn't make things worse. R's, John From nobody Mon Jul 25 01:51:42 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E860712D14D for ; Mon, 25 Jul 2016 01:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3AcDWlPL1zTo for ; Mon, 25 Jul 2016 01:51:40 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 72B2D12D106 for ; Mon, 25 Jul 2016 01:51:40 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id ks6so59487773pab.0 for ; Mon, 25 Jul 2016 01:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=JQfxBkKELOoyNCnuTKQE5AHszhuEZUgBAcLUiI0nxvc=; b=nPMOmRyzZK3uPIgXimW/aezwvVd/VMoWm/YAXkMhI7p5Y95kOr4FcTTUD1NXkHM/wp 6KQw+OfMuvL1i20GkgUpjfJX6I/r3sjxo8oPPMqIB/JL7WlZVSokMjVHJQmjyr499QY8 +FdjgSAybMPV872nP5kUGwNXXIWujwMoneamsnRTkJ2b3Ia+JMn6n/5MO1T8bnEpyOG9 ds/kPe6PBrHIvJEHmXZVMmuDbaZqR/DN/SDvQJvnywQsCQ7abLNxd4NnVbTtJLH7yYdu fITEKfX0bsASTgLBrVCxsGvVhUd2Bq2jptDYJR5FfFxylBVlIyV5+zepCabbzS+F5DAt iWDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=JQfxBkKELOoyNCnuTKQE5AHszhuEZUgBAcLUiI0nxvc=; b=XLjKaBpEfkS18qcZTgOLO0GGTSGAIXTjh5H+ZCw2dcfj9jm0tZVx17Xy3Lk89iAJHS x43g1C2qAMLfisqKMb0b3dh0j8A7wn/otzrpHXhQ4FpVwfsMpv9nfqe7WMJgVxrJfjCy 5VuCbwqmPmqhc3kjbMElhwJt7QeLMz1otCk8Q6zWlnCVeOiP1fo4Z7hpCillzsYPju09 eSMjHTNzs0xtALt9PSqoUq30BC6dDaCSEqPCQp0+iNnFvyI9a4gwqYrXRaSIvrEYQWYw r71EzhvWYTcPTK5p9Ynap4nqkUknEeK+3lC8Ut0ZyaNj5axQrvZdtwZeYFsMSaErpzal ZoqQ== X-Gm-Message-State: AEkoousvCOlYqunUBfpHGlgx+HxdaeBNYzXdcafNEIy+DwZq+tYiaotTmclj57yo/T64zg== X-Received: by 10.66.144.200 with SMTP id so8mr27478604pab.94.1469436699628; Mon, 25 Jul 2016 01:51:39 -0700 (PDT) Received: from [192.168.0.13] ([1.42.251.142]) by smtp.gmail.com with ESMTPSA id an13sm38162156pac.42.2016.07.25.01.51.37 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jul 2016 01:51:38 -0700 (PDT) From: James Winterbottom Content-Type: multipart/alternative; boundary="Apple-Mail=_C5E874C4-1BF1-434A-93F1-338045F33655" Message-Id: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> Date: Mon, 25 Jul 2016 18:51:34 +1000 To: DISPATCH list Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 08:51:42 -0000 --Apple-Mail=_C5E874C4-1BF1-434A-93F1-338045F33655 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul and Henning, I was reading through your draft but had to have a double take in = Section 11.4, it says the following: " > location information MUST be conveyed with a "geo:" URI in a > Geolocation header field, as defined in [RFC5870 = ]. >=20 > (While section=C2=A04.1 of [RFC6442] = prohibits this usage, = the reasons > for doing so do not apply to emergency calls.) =E2=80=9C The problem here that this is an illegal used of the encoding in RFC = 5870. The reason is that the way it is being used directly identifies as = device or user and so it falls subject to the requirements of a Geopriv = using protocol. =46rom section 9.2 of RFC 5870: " > A 'geo' URI by itself is just an opaque reference to a physical > location, expressed by a set of spatial coordinates. This does not > fit the "Location Information" definition according to Section 5.2 = of > GEOPRIV Requirements [RFC3693 = ], because there is not necessarily = a > "Device" involved. >=20 > Because there is also no way to specify the identity of a "Target" > within the confines of a 'geo' URI, it also does not fit the > specification of a "Location Object" (Section=C2=A05.2 of RFC 3693 = ). >=20 > However, if a 'geo' URI is used in a context where it identifies = the > location of a Target, it becomes part of a Location Object and is > therefore subject to GEOPRIV rules. >=20 > Therefore, when 'geo' URIs are put into such contexts, the privacy > requirements of RFC 3693 MUST = be met. =E2=80=9C In order for encoding of location to proceed in this form for the VRS = application I think far better rationale needs to be provided and it = needs to be demonstrated why the use case falls outside of the = constraints imposed by RFC 3693. Cheers James --Apple-Mail=_C5E874C4-1BF1-434A-93F1-338045F33655 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Paul and Henning,

I was reading through your draft but had to have a double = take in Section 11.4, it says the following:

"
location information MUST be conveyed =
with a "geo:" URI in a
      Geolocation header field, as defined in [RFC5870].

      (While section 4.1 of [RFC6442] prohibits this usage, the =
reasons
      for doing so do not apply to emergency =
calls.)
=E2=80=9C

The problem here that = this is an illegal used of the encoding in RFC 5870. The reason is that = the way it is being used directly identifies as device or user and so it = falls subject to the requirements of a Geopriv using protocol. =46rom = section 9.2 of RFC 5870:
"
A 'geo' URI by itself is =
just an opaque reference to a physical
   location, expressed by a set of spatial coordinates.  This does not
   fit the "Location Information" definition according to Section 5.2 of
   GEOPRIV Requirements [RFC3693], =
because there is not necessarily a
   "Device" involved.

   Because there is also no way to specify the identity of a "Target"
   within the confines of a 'geo' URI, it also does not fit the
   specification of a "Location Object" (Section 5.2 of RFC 3693).

   However, if a 'geo' URI is used in a context where it identifies the
   location of a Target, it becomes part of a Location Object and is
   therefore subject to GEOPRIV rules.

   Therefore, when 'geo' URIs are put into such contexts, the privacy
   requirements of RFC 3693 MUST be met.
=E2=80=9C
In order for encoding of = location to proceed in this form for the VRS application I think far = better rationale needs to be provided and it needs to be demonstrated = why the use case falls outside of the constraints imposed by RFC = 3693.

Cheers
James


= --Apple-Mail=_C5E874C4-1BF1-434A-93F1-338045F33655-- From nobody Tue Jul 26 08:48:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC90912D83C for ; Tue, 26 Jul 2016 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qbw2sKELk-79 for ; Tue, 26 Jul 2016 08:48:47 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 DB1ED12DD86 for ; Tue, 26 Jul 2016 08:20:10 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-05v.sys.comcast.net with SMTP id S46Lb8Y5C2FGMS49RbOZR3; Tue, 26 Jul 2016 15:20:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id S49RbtlR1AwlPS49RboAgP; Tue, 26 Jul 2016 15:20:09 +0000 To: dispatch@ietf.org References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> From: Paul Kyzivat Message-ID: Date: Tue, 26 Jul 2016 11:20:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfPOO9LRhIgtH7p2yh+WSd9AZGIjxVNjZ2LXRZBPEiZ918ceJb901TF5heqL/Nhz+18Xkq3s9fCDouVxJrhSTc9V6b8y/YICdFcCAAToeO9U8/tXGQTqN aHUe4IOsXEQJT/wkUNbu+Sz00M4PiKJlcVV0nK/k0MbM/f8XoztqyrdVWi8ibO3owrXH0Q1h7E9Ilg== Archived-At: Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 15:48:49 -0000 James, Henning is traveling, so we may not hear from him for a bit. Using geo: was not my first choice, precisely because it isn't included among the permissible ways of conveying the information. But it is a hard sell among the VRS community. For this use the alternative would be putting the location in the body, which is felt to be complex. Note that the context for this usage is only 911 calls. I got the following private comment from Henning: > Privacy indicators in US 911 SIP requests are both meaningless and > possibly disruptive. Since US VRS and 911 retention and disclosure > policies are given by law and custom and not subject to user control, > there are only two options: > > (1) Ignore the settings in PIDF-LO, i.e., the user believes one thing > that's happening, but reality is something else. > > (2) Reject the 911 call, since the VRS provider and 911 provider cannot > and will not honor the requested privacy policy. Clearly not acceptable. (I'm not personally familiar with the US regulations - I trust Henning on this.) The current situation is that VRS users *are* using mobile devices for 911 calls, and the location initially communicated for those calls is currently *static*. The actual location must be provided within the call by the deaf caller, using ASL. We are trying to improve on that. Thanks, Paul On 7/25/16 4:51 AM, James Winterbottom wrote: > Hi Paul and Henning, > > I was reading through your draft but had to have a double take in > Section 11.4, it says the following: > > " >> location information MUST be conveyed with a "geo:" URI in a >> Geolocation header field, as defined in [RFC5870 ]. >> >> (While section 4.1 of [RFC6442] prohibits this usage, the reasons >> for doing so do not apply to emergency calls.) > > > The problem here that this is an illegal used of the encoding in RFC > 5870. The reason is that the way it is being used directly identifies as > device or user and so it falls subject to the requirements of a Geopriv > using protocol. From section 9.2 of RFC 5870: > " >> A 'geo' URI by itself is just an opaque reference to a physical >> location, expressed by a set of spatial coordinates. This does not >> fit the "Location Information" definition according to Section 5.2 of >> GEOPRIV Requirements [RFC3693 ], because there is not necessarily a >> "Device" involved. >> >> Because there is also no way to specify the identity of a "Target" >> within the confines of a 'geo' URI, it also does not fit the >> specification of a "Location Object" (Section 5.2 of RFC 3693 ). >> >> However, if a 'geo' URI is used in a context where it identifies the >> location of a Target, it becomes part of a Location Object and is >> therefore subject to GEOPRIV rules. >> >> Therefore, when 'geo' URIs are put into such contexts, the privacy >> requirements of RFC 3693 MUST be met. > > In order for encoding of location to proceed in this form for the VRS > application I think far better rationale needs to be provided and it > needs to be demonstrated why the use case falls outside of the > constraints imposed by RFC 3693. > > Cheers > James > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Jul 26 09:17:41 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFE312B054 for ; Tue, 26 Jul 2016 09:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com 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 uMMskoABrUSj for ; Tue, 26 Jul 2016 09:17:38 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6822128B44 for ; Tue, 26 Jul 2016 09:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xF5wNQOjLwHeNOkBMms1IfB2VVDr8uDEJG2ea9gJWjQ=; b=MCrURABmA60/YNSEIE2StKXUmU8xuvOWlm9tJm6sNvZrHTUw012xurTL43BULScDRlPIfro+YBcc9HDy8hzV5q+49v5bygjMiLF3tjPheCh46pWtH5oqlhSMCTjDiQyvjuIfdsa/lDJLSsyqz1F16IT8GIc1LgJxueHY/nD2ZTo= From: Henning Schulzrinne To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 Thread-Index: AQHR51VEgyILayASIku+zCFUmD7d/KAq3u2P Date: Tue, 26 Jul 2016 16:17:33 +0000 Message-ID: References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Henning.Schulzrinne@fcc.gov; x-ms-office365-filtering-correlation-id: 10ae6b59-d37c-435d-de9c-08d3b57059bd x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 6:R9bq7YFR7KjU6KHGu3rogc/SOFrGZUkr0a8WSPumD4EZ+zKbL14C+F3PpiP5+qdo89jmFmkjW1jjwkMZh4C5IstAhep2ckJdQw5UoE4/PvOCDZQY17Q5sx3qvEHKLRYdO3p94igkviEIa+Xmwl/BFJFZQ78dALod/FP6qJm30KLC8tWOIzAIlCjVWY5F/0ZLf9jT7CH9eBYb0etSuY4MpgI3w6AAlT2FWXm1jWZUCRA4gtO5pt9mch5IdhF18nBkmtsVqSUcX7qbCY62tuy1Ke+Sb0ItHhz3/qllNsBCR64=; 5:xnz0AKJsLRAjIZ/T9dtCKcohcZmZX/S3snxaTatdaU7LFbKDSmwgHpxLWqmZSnvSTffepPo4G5eczCEksKDkjFcGhO7ErOiDy8YZpofYlbM9RQ0MKElrPLQV6wyY1FHdYBdZzxdA/5nzblrzxUSy6Q==; 24:44r02XorlQPNDb75UYvdfTMeJk4FY7DSH3RhbfcPAUZ7eVxJk0PGKNh7BH9++0Dwfs6eiGeMpVBKAlxfWGoEKFAKhuBsbtAoY8RbTI/Wtog=; 7:C+wk4n0nW/mv8Vbg/jvRQZoPj9HwJUOrdw0V6RcR64dtEMu52YmtjJQRrrhiMr6MRsSSxkghJXYMk3zommybzvGDhOrtzLxAhrjeS1yZEyP56zSRRCttsdJmxXarRH7qX7osSJzeIu5ADMVRpJQPKMxSPP0hYUNe1GaLsSLqSMrmPVb7mYVwKka/hg8pvWYufoZ//cgR3b3+zkHsndHURqflnS/mx6wgc+Wp2Ni8JKdJoXS3iEysOCghISMuIRRL x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(377454003)(24454002)(106356001)(122556002)(19625215002)(8676002)(3846002)(92566002)(16236675004)(81156014)(81166006)(5002640100001)(19580405001)(106116001)(87936001)(586003)(8936002)(76176999)(189998001)(7846002)(6116002)(102836003)(54356999)(68736007)(107886002)(7736002)(11100500001)(19580395003)(2950100001)(2171001)(86362001)(15975445007)(2900100001)(7696003)(101416001)(7906003)(77096005)(5001770100001)(97736004)(74316002)(5003600100003)(50986999)(10400500002)(76576001)(3660700001)(230783001)(3280700002)(307094003)(105586002)(66066001)(5890100001)(2501003)(19617315012)(2906002)(9686002)(99286002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB063414AC41B6BCE401BB5DCEEA0E0CY1PR09MB0634namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 16:17:33.1018 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-OriginatorOrg: fcc.gov Archived-At: Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 16:17:41 -0000 --_000_CY1PR09MB063414AC41B6BCE401BB5DCEEA0E0CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [Typing this from the Athen's airport] Adding to this: In this particular use case, there is indeed a "device location" - the only= location reported is what the handset (Android/IOS) device believes the lo= cation is - and this better be the location of the device, not something el= se. Anything else would be a bug or malicious location spoofing. There is n= o HELD or other external reference involved. Given that the privacy indicators convey no information in this case (and t= hus would have to be hard-coded to the no-restrictions values to avoid emer= gency call failures), I fail to see the substantive, as opposed to protocol= -lawyering, difference. The information is going to be exactly the same, wh= ether I do this by cdata PIDF-LO attachment "legally" or by geo URL "illega= lly". Also, the VRS 911 situation is somewhat unique in that there are three enti= ties involved in the call: the VRS provider and its communication assistant= (the person translating between voice and ASL), a third-party emergency se= rvice provider and the PSAP with related system service providers. Until na= tive NG911/i3 is common, the most likely case is that the VRS provider will= pick apart the SIP request and inject the location via a proprietary API. All three entities have their own data retention and disclosure rules, whic= h may vary by state, and are likely unknown upstream. Given the absence of HELD in this environment, at least for the foreseeable= future, insisting on carrying the same information in an XML attachment in= stead of a header, means that the emergency calls need a completely differe= nt code path since they are the only ones with multi-part. This is seen as = a really bad trade-off of reliability and simplicity vs. formal requirement= s that serve no obvious privacy or functionality purpose. If there's a technical argument, rather than a legalistic one, please expla= in in more detail, as I'm obviously missing it. I assume you mean "illegal" figuratively, as I might need to get a protocol= lawyer otherwise :-) Henning ________________________________ From: dispatch on behalf of Paul Kyzivat Sent: Tuesday, July 26, 2016 11:20:08 AM To: dispatch@ietf.org Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs= -rue-dispatch-00 James, Henning is traveling, so we may not hear from him for a bit. Using geo: was not my first choice, precisely because it isn't included among the permissible ways of conveying the information. But it is a hard sell among the VRS community. For this use the alternative would be putting the location in the body, which is felt to be complex. Note that the context for this usage is only 911 calls. I got the following private comment from Henning: > Privacy indicators in US 911 SIP requests are both meaningless and > possibly disruptive. Since US VRS and 911 retention and disclosure > policies are given by law and custom and not subject to user control, > there are only two options: > > (1) Ignore the settings in PIDF-LO, i.e., the user believes one thing > that's happening, but reality is something else. > > (2) Reject the 911 call, since the VRS provider and 911 provider cannot > and will not honor the requested privacy policy. Clearly not acceptable. (I'm not personally familiar with the US regulations - I trust Henning on this.) The current situation is that VRS users *are* using mobile devices for 911 calls, and the location initially communicated for those calls is currently *static*. The actual location must be provided within the call by the deaf caller, using ASL. We are trying to improve on that. Thanks, Paul On 7/25/16 4:51 AM, James Winterbottom wrote: > Hi Paul and Henning, > > I was reading through your draft but had to have a double take in > Section 11.4, it says the following: > > " >> location information MUST be conveyed with a "geo:" URI in a >> Geolocation header field, as defined in [RFC5870 ]. >> >> (While section 4.1 of [RFC6442] prohibits this usage, the reasons >> for doing so do not apply to emergency calls.) > =93 > > The problem here that this is an illegal used of the encoding in RFC > 5870. The reason is that the way it is being used directly identifies as > device or user and so it falls subject to the requirements of a Geopriv > using protocol. From section 9.2 of RFC 5870: > " >> A 'geo' URI by itself is just an opaque reference to a physical >> location, expressed by a set of spatial coordinates. This does not >> fit the "Location Information" definition according to Section 5.2 of >> GEOPRIV Requirements [RFC3693 ],= because there is not necessarily a >> "Device" involved. >> >> Because there is also no way to specify the identity of a "Target" >> within the confines of a 'geo' URI, it also does not fit the >> specification of a "Location Object" (Section 5.2 of RFC 3693 ). >> >> However, if a 'geo' URI is used in a context where it identifies the >> location of a Target, it becomes part of a Location Object and is >> therefore subject to GEOPRIV rules. >> >> Therefore, when 'geo' URIs are put into such contexts, the privacy >> requirements of RFC 3693 MUST b= e met. > =93 > In order for encoding of location to proceed in this form for the VRS > application I think far better rationale needs to be provided and it > needs to be demonstrated why the use case falls outside of the > constraints imposed by RFC 3693. > > Cheers > James > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_CY1PR09MB063414AC41B6BCE401BB5DCEEA0E0CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

[Typing this from the Athen's airport]


Adding to this:


In this particular use case, there is indeed a "device location&quo= t; - the only location reported is what the handset (Android/IOS) device be= lieves the location is - and this better be the location of the device, not= something else. Anything else would be a bug or malicious location spoofing. There is no HELD or other external ref= erence involved.


Given that the privacy indicators convey no information in this cas= e (and thus would have to be hard-coded to the no-restrictions values to av= oid emergency call failures), I fail to see the substantive, as opposed to = protocol-lawyering, difference. The information is going to be exactly the same, whether I do this by cdata PIDF-LO a= ttachment "legally" or by geo URL "illegally".


Also, the VRS 911 situation is somewhat unique in that there are three e= ntities involved in the call: the VRS provider and its communication assist= ant (the person translating between voice and ASL), a third-party emer= gency service provider and the PSAP with related system service providers. Until native NG911/i3 is common, the mos= t likely case is that the VRS provider will pick apart the SIP request and = inject the location via a proprietary API.


All three entities have their own data retention and disclosure rul= es, which may vary by state, and are likely unknown upstream.


Given the absence of HELD in this environment, at least for the foreseea= ble future, insisting on carrying the same information in an XML attachment= instead of a header, means that the emergency calls need a completely diff= erent code path since they are the only ones with multi-part. This is seen as a really bad trade-off of relia= bility and simplicity vs. formal requirements that serve no obvious privacy= or functionality purpose.


If there's a technical argument, rather than a legalistic one, please ex= plain in more detail, as I'm obviously missing it.


I assume you mean "illegal" figuratively, as I might need to g= et a protocol lawyer otherwise :-) 


Henning


From: dispatch <dispat= ch-bounces@ietf.org> on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu= >
Sent: Tuesday, July 26, 2016 11:20:08 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] Strong concerns with location encoding in dr= aft-vrs-rue-dispatch-00
 
James,

Henning is traveling, so we may not hear from him for a bit.

Using geo: was not my first choice, precisely because it isn't included among the permissible ways of conveying the information. But it is a
hard sell among the VRS community. For this use the alternative would be putting the location in the body, which is felt to be complex.

Note that the context for this usage is only 911 calls. I got the
following private comment from Henning:

> Privacy indicators in US 911 SIP requests are both meaningless and
> possibly disruptive. Since US VRS and 911 retention and disclosure
> policies are given by law and custom and not subject to user control,<= br> > there are only two options:
>
> (1) Ignore the settings in PIDF-LO, i.e., the user believes one thing<= br> > that's happening, but reality is something else.
>
> (2) Reject the 911 call, since the VRS provider and 911 provider canno= t
> and will not honor the requested privacy policy. Clearly not acceptabl= e.

(I'm not personally familiar with the US regulations - I trust Henning
on this.)

The current situation is that VRS users *are* using mobile devices for
911 calls, and the location initially communicated for those calls is
currently *static*. The actual location must be provided within the call by the deaf caller, using ASL. We are trying to improve on that.

        Thanks,
        Paul

On 7/25/16 4:51 AM, James Winterbottom wrote:
> Hi Paul and Henning,
>
> I was reading through your draft but had to have a double take in
> Section 11.4, it says the following:
>
> "
>> location information MUST be conveyed with a "geo:" URI = in a
>>       Geolocation header field, as d= efined in [RFC5870 <http= s://tools.ietf.org/html/rfc5870>].
>>
>>       (While section 4.1 of [RFC6442= ] <https://t= ools.ietf.org/html/rfc6442#section-4.1> prohibits this usage, the re= asons
>>       for doing so do not apply to e= mergency calls.)
> =93
>
> The problem here that this is an illegal used of the encoding in RFC > 5870. The reason is that the way it is being used directly identifies = as
> device or user and so it falls subject to the requirements of a Geopri= v
> using protocol. From section 9.2 of RFC 5870:
> "
>> A 'geo' URI by itself is just an opaque reference to a physical >>    location, expressed by a set of spatial coordina= tes.  This does not
>>    fit the "Location Information" definit= ion according to Section 5.2 <https://tools.ietf.org/html/rfc5870#section-5.2> o= f
>>    GEOPRIV Requirements [RFC3693 <https://tools.ietf.org/html/rfc3693&g= t;], because there is not necessarily a
>>    "Device" involved.
>>
>>    Because there is also no way to specify the iden= tity of a "Target"
>>    within the confines of a 'geo' URI, it also does= not fit the
>>    specification of a "Location Object" (= Section 5.2 of RFC 3693 <https://tools.ietf.org/html/rfc3693#section-5.2>).
>>
>>    However, if a 'geo' URI is used in a context whe= re it identifies the
>>    location of a Target, it becomes part of a Locat= ion Object and is
>>    therefore subject to GEOPRIV rules.
>>
>>    Therefore, when 'geo' URIs are put into such con= texts, the privacy
>>    requirements of RFC 3693 <https://tools.ietf.org/html/rfc3693> MU= ST be met.
> =93
> In order for encoding of location to proceed in this form for the VRS<= br> > application I think far better rationale needs to be provided and it > needs to be demonstrated why the use case falls outside of the
> constraints imposed by RFC 3693.
>
> Cheers
> James
>
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

 --_000_CY1PR09MB063414AC41B6BCE401BB5DCEEA0E0CY1PR09MB0634namp_-- From nobody Tue Jul 26 12:21:11 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5635B12B056 for ; Tue, 26 Jul 2016 12:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iUmJ7SfNRERU for ; Tue, 26 Jul 2016 12:21:08 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 E78BA12D57B for ; Tue, 26 Jul 2016 12:21:03 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id q128so185463348wma.1 for ; Tue, 26 Jul 2016 12:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=JObInu6sYbyyfqbsgSCnW08/Dqzyyb+GdCG8noHhmIQ=; b=eDiaGXBp1gnDqRL7eboK2GhrHWPWRcdCwU6QflajJ1NsWgf3HzSXvdpPypwLmoXFBl m+uzJEVUQwAHP8MuK7jaH8nXW/1tWp8mGbLa3cz6CrXZpII6wrc0+nkTsNmk/mSbI5Hh jVaLfdvYLChHj1XTJosG8JsF1ercor3qLNzXojMPHCTCZXQBFpKZnikmy+67ltFFaPQL KluUdTGB5GuTvBKpisZ98mTIS1q/XPaJ86ATxGtKcLGfm6CGTBSwGdlRQd/IrESuCE3x q54G3jkEYcdYMp0Si/9emAXrhvBdWO4xFFKxtzT7k/x9NWWYBNwbNpuljNV6CdipIKST tRFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JObInu6sYbyyfqbsgSCnW08/Dqzyyb+GdCG8noHhmIQ=; b=ETK7kls0X+NblNJFEkAzwcbDMiV1sFlMeqdeRHsGQuTeDSw6FlA6j22wRioXM2vJPW iocMDpaHnOUXb7Lsn6XQvvnWtfF8VIJLQFouvZHNOhbkv8jnuDSIepzWvt8i6GSUEWL7 uzKCzxnNNUjZnRztCCXdw/jeDqmwdNMfy5AtVbo5iNoNNu0Kfc1ebKTIBAqvUBGTfHUW zdRuOfn7LPHWfnx6KiUs9Fn/9qe0fQ3Ojq/41Sots3ZyM5TYp0woxOwv/iJOveVRTGnC UK89wZSsptSNwH3DBsGFEAHjIGwATEDpzvRRftGRjJpC3mSBcXfhWY9touf4W/tFdNfT OTrA== X-Gm-Message-State: AEkoouvzNV8mKcgP9ENh1NoZkrrKpX5qmX5Jto6G7ytZU5kYJxhHrN6MupGDVh4aP9Ll7XKYNCJPGI4Q7q/UJA== X-Received: by 10.194.185.202 with SMTP id fe10mr21743323wjc.93.1469560861840; Tue, 26 Jul 2016 12:21:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.96.139 with HTTP; Tue, 26 Jul 2016 12:21:01 -0700 (PDT) From: Ranjit Avasarala Date: Tue, 26 Jul 2016 14:21:01 -0500 Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=047d7b8749b4255a0105388ecd3a Archived-At: Subject: [dispatch] Query on SIP 380 response for emergency service X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 19:21:10 -0000 --047d7b8749b4255a0105388ecd3a Content-Type: text/plain; charset=UTF-8 Hi There was an emergency outage sometime back and the emergency service returned a 380 Alternate Service response. But the wireshark call traces do not capture 380, but always show 300 Multiple Choices response. Though 380 is considered a success case along with 300, I am curious why the call trace does not show 380 but shows 300. any comments? Thanks Ranjit --047d7b8749b4255a0105388ecd3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

There was an eme= rgency outage sometime back and the emergency service returned a 380 Altern= ate Service response.=C2=A0 But the wireshark call traces do not capture 38= 0, but always show 300 Multiple Choices response.=C2=A0

Thoug= h 380 is considered a success case along with 300, I am curious why the cal= l trace does not show 380 but shows 300.

any comments?

=
Thanks
Ranjit
--047d7b8749b4255a0105388ecd3a-- From nobody Tue Jul 26 14:07:22 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5DA412D982 for ; Tue, 26 Jul 2016 14:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 X2SgEi-XI9qx for ; Tue, 26 Jul 2016 14:07:17 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 B321912D987 for ; Tue, 26 Jul 2016 14:07:17 -0700 (PDT) Received: by mail-pa0-x22b.google.com with SMTP id iw10so3068285pac.2 for ; Tue, 26 Jul 2016 14:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ugCP9glwvzF7WMY7BzykDoiodgxNEBP4bU7ftR9uARo=; b=S59ZWbJscFb39+NKCDKD0ziv0tKFUyaWvWNglPIwZ+xENqEQu2mmUXoEAMu/hrHVDN gXRVtoYeQXzacQrlemBVBxllATGBef/3rNQ2DgjwMeDcSKZtPVOTG0YClDDVi0HAUk8P IRtxL/Sp39VLw4ssmOVZQ6TX25AhxZf/8Cd3XzNcM0/1+O54HLIdAB2rusK9AIIys2Fj OweQ9H/ZLbvEERxGTWDCGebi9bqfyVEa5Xv2FR+nCCDt0cbD0K5LsiFwX8gK/MBLnp4i pZY+bv7n/kwo/6jmyCX9NhJGJxUv6qKQnCnJ7EVni76KAweurrXhRkaHRubPu7VdvLtC w0BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ugCP9glwvzF7WMY7BzykDoiodgxNEBP4bU7ftR9uARo=; b=FVffc69kg9MMEzGg0tag9u4YZoTWGSCaMzQvclX70AGiFecONRjGDZI2IFevq+0UoG KnObtVjulc/92rzLwpfpzEmsOIe5ttohhd8Fc1djhoIJ5sayXjAwzAZo4MtYvXlCAofs eTOYyD0A3+sjrl//iHWM3KG+DJjJiGJQgVX3qIDscySPUI5sFeDm4mTx3CtSw3jXH8Gy viAcip6ptFuShmuhCTR8fZhzjeV8q5+G49h31Ke3Puw0UtbidXldtCT5apbB7iuJ0F4c NbKHdKUmg6ZYTBqXERohPULPEPLLMSBsxXYcj73HRV5ZCo1yasaQGSS43NISHHqUSSIj IPNw== X-Gm-Message-State: AEkoousZKrsoCZT2wVQb7m4gMF67Zm2Me0bzzIGLhke2stUEjNt/VoUI8Rdy05dq5oVVag== X-Received: by 10.66.232.37 with SMTP id tl5mr42786659pac.13.1469567237046; Tue, 26 Jul 2016 14:07:17 -0700 (PDT) Received: from [192.168.0.13] ([1.42.251.142]) by smtp.gmail.com with ESMTPSA id s23sm3676621pfd.23.2016.07.26.14.07.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jul 2016 14:07:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_266F8A4F-0010-4A11-981B-0FEBC25A9F49" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: James Winterbottom In-Reply-To: Date: Wed, 27 Jul 2016 07:07:10 +1000 Message-Id: References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 21:07:21 -0000 --Apple-Mail=_266F8A4F-0010-4A11-981B-0FEBC25A9F49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Henning and Paul, The argument still feels a bit like =93we don=92t have anything today, = HELD is too heavy weight, give us encoded location in the header=94. I = guess my worry with this is two fold: 1) providing this means there is never an incentive to move towards a = more standardised location approach, I will cite the eCall MSD is a good = example of where this has occurred. 2) It gives the first push down the very long slide of =93geo URIs are = fine for conveying target location=94. My strongest preference would be to find someway for this to provide a = serious stepping-stone towards NG formats and protocols, rather than = providing a mechanism that once implemented gives no incentive to move = mainstream.=20 It would be good to hear if anyone else on the list has similar = concerns. Cheers James > On 27 Jul 2016, at 2:17 AM, Henning Schulzrinne = wrote: >=20 > [Typing this from the Athen's airport] >=20 > Adding to this: >=20 > In this particular use case, there is indeed a "device location" - the = only location reported is what the handset (Android/IOS) device believes = the location is - and this better be the location of the device, not = something else. Anything else would be a bug or malicious location = spoofing. There is no HELD or other external reference involved. >=20 > Given that the privacy indicators convey no information in this case = (and thus would have to be hard-coded to the no-restrictions values to = avoid emergency call failures), I fail to see the substantive, as = opposed to protocol-lawyering, difference. The information is going to = be exactly the same, whether I do this by cdata PIDF-LO attachment = "legally" or by geo URL "illegally". >=20 > Also, the VRS 911 situation is somewhat unique in that there are three = entities involved in the call: the VRS provider and its communication = assistant (the person translating between voice and ASL), a third-party = emergency service provider and the PSAP with related system service = providers. Until native NG911/i3 is common, the most likely case is that = the VRS provider will pick apart the SIP request and inject the location = via a proprietary API. >=20 > All three entities have their own data retention and disclosure rules, = which may vary by state, and are likely unknown upstream. >=20 > Given the absence of HELD in this environment, at least for the = foreseeable future, insisting on carrying the same information in an XML = attachment instead of a header, means that the emergency calls need a = completely different code path since they are the only ones with = multi-part. This is seen as a really bad trade-off of reliability and = simplicity vs. formal requirements that serve no obvious privacy or = functionality purpose. >=20 > If there's a technical argument, rather than a legalistic one, please = explain in more detail, as I'm obviously missing it. >=20 > I assume you mean "illegal" figuratively, as I might need to get a = protocol lawyer otherwise :-)=20 >=20 > Henning >=20 > From: dispatch on behalf of Paul Kyzivat = > Sent: Tuesday, July 26, 2016 11:20:08 AM > To: dispatch@ietf.org > Subject: Re: [dispatch] Strong concerns with location encoding in = draft-vrs-rue-dispatch-00 > =20 > James, >=20 > Henning is traveling, so we may not hear from him for a bit. >=20 > Using geo: was not my first choice, precisely because it isn't = included=20 > among the permissible ways of conveying the information. But it is a=20= > hard sell among the VRS community. For this use the alternative would = be=20 > putting the location in the body, which is felt to be complex. >=20 > Note that the context for this usage is only 911 calls. I got the=20 > following private comment from Henning: >=20 > > Privacy indicators in US 911 SIP requests are both meaningless and > > possibly disruptive. Since US VRS and 911 retention and disclosure > > policies are given by law and custom and not subject to user = control, > > there are only two options: > > > > (1) Ignore the settings in PIDF-LO, i.e., the user believes one = thing > > that's happening, but reality is something else. > > > > (2) Reject the 911 call, since the VRS provider and 911 provider = cannot > > and will not honor the requested privacy policy. Clearly not = acceptable. >=20 > (I'm not personally familiar with the US regulations - I trust Henning=20= > on this.) >=20 > The current situation is that VRS users *are* using mobile devices for=20= > 911 calls, and the location initially communicated for those calls is=20= > currently *static*. The actual location must be provided within the = call=20 > by the deaf caller, using ASL. We are trying to improve on that. >=20 > Thanks, > Paul >=20 > On 7/25/16 4:51 AM, James Winterbottom wrote: > > Hi Paul and Henning, > > > > I was reading through your draft but had to have a double take in > > Section 11.4, it says the following: > > > > " > >> location information MUST be conveyed with a "geo:" URI in a > >> Geolocation header field, as defined in [RFC5870 = >]. > >> > >> (While section 4.1 of [RFC6442] = > prohibits this usage, = the reasons > >> for doing so do not apply to emergency calls.) > > =93 > > > > The problem here that this is an illegal used of the encoding in RFC > > 5870. The reason is that the way it is being used directly = identifies as > > device or user and so it falls subject to the requirements of a = Geopriv > > using protocol. =46rom section 9.2 of RFC 5870: > > " > >> A 'geo' URI by itself is just an opaque reference to a physical > >> location, expressed by a set of spatial coordinates. This does = not > >> fit the "Location Information" definition according to Section = 5.2 > of > >> GEOPRIV Requirements [RFC3693 = >], because there is not = necessarily a > >> "Device" involved. > >> > >> Because there is also no way to specify the identity of a = "Target" > >> within the confines of a 'geo' URI, it also does not fit the > >> specification of a "Location Object" (Section 5.2 of RFC 3693 = >). > >> > >> However, if a 'geo' URI is used in a context where it identifies = the > >> location of a Target, it becomes part of a Location Object and = is > >> therefore subject to GEOPRIV rules. > >> > >> Therefore, when 'geo' URIs are put into such contexts, the = privacy > >> requirements of RFC 3693 > MUST be met. > > =93 > > In order for encoding of location to proceed in this form for the = VRS > > application I think far better rationale needs to be provided and it > > needs to be demonstrated why the use case falls outside of the > > constraints imposed by RFC 3693. > > > > Cheers > > James > > > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch = > > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_266F8A4F-0010-4A11-981B-0FEBC25A9F49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Thanks Henning and Paul,

The argument still feels = a bit like =93we don=92t have anything today, HELD is too heavy weight, = give us encoded location in the header=94. I guess my worry with this is = two fold:
1) providing this means there is never an = incentive to move towards a more standardised location approach, I will = cite the eCall MSD is a good example of where this has = occurred.
2) It gives the first push down the very = long slide of =93geo URIs are fine for conveying target = location=94.

My = strongest preference would be to find someway for this to provide a = serious stepping-stone towards NG formats and protocols, rather than = providing a mechanism that once implemented gives no incentive to move = mainstream. 

It would be good to hear if anyone else on the list has = similar concerns.

Cheers
James


On 27 Jul 2016, at 2:17 AM, Henning = Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

[Typing this from the Athen's = airport]

Adding to this:

In this particular use case, there is indeed a "device = location" - the only location reported is what the handset (Android/IOS) = device believes the location is - and this better be the location of the = device, not something else. Anything else would be a bug or malicious = location spoofing. There is no HELD or other external reference = involved.

Given that the privacy indicators convey = no information in this case (and thus would have to be hard-coded = to the no-restrictions values to avoid emergency call failures), I fail = to see the substantive, as opposed to protocol-lawyering, difference. = The information is going to be exactly the same, whether I do this by = cdata PIDF-LO attachment "legally" or by geo URL = "illegally".

Also, the VRS 911 situation is somewhat = unique in that there are three entities involved in the call: the VRS = provider and its communication assistant (the person translating between = voice and ASL), a third-party emergency service provider and the = PSAP with related system service providers. Until native NG911/i3 is = common, the most likely case is that the VRS provider will pick apart = the SIP request and inject the location via a proprietary API.

All three entities have their own data retention and = disclosure rules, which may vary by state, and are likely unknown = upstream.

Given the absence of HELD in this = environment, at least for the foreseeable future, insisting on carrying = the same information in an XML attachment instead of a header, means = that the emergency calls need a completely different code path since = they are the only ones with multi-part. This is seen as a really bad = trade-off of reliability and simplicity vs. formal requirements that = serve no obvious privacy or functionality purpose.

If there's a technical argument, rather than a legalistic = one, please explain in more detail, as I'm obviously missing = it.

I assume you mean "illegal" = figuratively, as I might need to get a protocol lawyer = otherwise :-) 


Henning

From: dispatch <dispatch-bounces@ietf.org> on behalf of Paul Kyzivat = <pkyzivat@alum.mit.edu>
Sent: Tuesday, July 26, 2016 = 11:20:08 AM
To: dispatch@ietf.org
Subject: Re: [dispatch] Strong = concerns with location encoding in draft-vrs-rue-dispatch-00
 
James,

Henning is traveling, so we may not hear from = him for a bit.

Using geo: was not my first = choice, precisely because it isn't included 
among the = permissible ways of conveying the information. But it is a 
hard sell = among the VRS community. For this use the alternative would be 
putting the = location in the body, which is felt to be complex.

Note that the context for this usage is only 911 calls. I got = the 
following private comment from Henning:

> Privacy indicators in US 911 SIP requests are both = meaningless and
> possibly disruptive. Since US VRS and = 911 retention and disclosure
> policies are given by = law and custom and not subject to user control,
> there = are only two options:
>
> (1) Ignore = the settings in PIDF-LO, i.e., the user believes one thing
> that's happening, but reality is something else.
>
> (2) Reject the 911 call, since the = VRS provider and 911 provider cannot
> and will not = honor the requested privacy policy. Clearly not acceptable.

(I'm not personally familiar with the US = regulations - I trust Henning 
on this.)

The current situation is that VRS users *are* = using mobile devices for 
911 calls, = and the location initially communicated for those calls is 
currently = *static*. The actual location must be provided within the call 
by the deaf = caller, using ASL. We are trying to improve on that.

        Thanks,
        Paul

On 7/25/16 4:51 AM, James Winterbottom = wrote:
> Hi Paul and Henning,
>
> I was reading through your draft but had to have a = double take in
> Section 11.4, it says the = following:
>
> "
>> = location information MUST be conveyed with a "geo:" URI in a
>>       Geolocation = header field, as defined in [RFC5870 <https://tools.ietf.org/html/rfc5870>].
>>
>>       (While section = 4.1 of [RFC6442] <https://tools.ietf.org/html/rfc6442#section-4.1> = prohibits this usage, the reasons
>>       for doing so do = not apply to emergency calls.)
> =93
>
> The problem here that this is an = illegal used of the encoding in RFC
> 5870. The reason = is that the way it is being used directly identifies as
>= device or user and so it falls subject to the requirements of a = Geopriv
> using protocol. =46rom section 9.2 of RFC = 5870:
> "
>> A 'geo' URI by itself = is just an opaque reference to a physical
>>    location, expressed by a set of = spatial coordinates.  This does not
>>    fit the "Location Information" = definition according to Section 5.2 <https://tools.ietf.org/html/rfc5870#section-5.2> of
>>    GEOPRIV Requirements [RFC3693 = <https://tools.ietf.org/html/rfc3693>], because there = is not necessarily a
>>    "Device" = involved.
>>
>>    = Because there is also no way to specify the identity of a "Target"
>>    within the confines of a 'geo' = URI, it also does not fit the
>>    = specification of a "Location Object" (Section 5.2 of RFC 3693 <https://tools.ietf.org/html/rfc3693#section-5.2>).
>>
>>    However, if = a 'geo' URI is used in a context where it identifies the
>>    location of a Target, it becomes = part of a Location Object and is
>>    = therefore subject to GEOPRIV rules.
>>
>>    Therefore, when 'geo' URIs are put = into such contexts, the privacy
>>    = requirements of RFC 3693 <https://tools.ietf.org/html/rfc3693> MUST be met.
> =93
> In order for encoding of location = to proceed in this form for the VRS
> application I = think far better rationale needs to be provided and it
> = needs to be demonstrated why the use case falls outside of the
> constraints imposed by RFC 3693.
>
> Cheers
> James
>
>
>
>
> = _______________________________________________
> = dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

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

_______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_266F8A4F-0010-4A11-981B-0FEBC25A9F49-- From nobody Tue Jul 26 14:32:32 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A479112D9AA for ; Tue, 26 Jul 2016 14:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.488 X-Spam-Level: X-Spam-Status: No, score=-5.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FRpNCFTwEUe for ; Tue, 26 Jul 2016 14:32:28 -0700 (PDT) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1188912D9AE for ; Tue, 26 Jul 2016 14:32:27 -0700 (PDT) X-AuditID: 1207440d-be3ff700000008af-84-5797d6e91511 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id ED.A0.02223.9E6D7975; Tue, 26 Jul 2016 17:32:27 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u6QLWO7l023759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 Jul 2016 17:32:25 -0400 To: James Winterbottom , Henning Schulzrinne References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> From: Paul Kyzivat Message-ID: <7a228246-90f0-3fc0-58f0-dc014897a6e4@alum.mit.edu> Date: Tue, 26 Jul 2016 17:32:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixO6iqPv62vRwg78LuS3ubfrJYrF00gJW i59HdrM6MHvcvv2GzWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyuj+vZW54LljxccP81gb GP+YdDFyckgImEjc+n2EsYuRi0NIYCujxKvDK1khnKdMEi96TrJ0MXJwCAvESnStZgVpEBEo lrjUOIUFouYHo0TzvgUsIAlmAW2JS7O3MoHYbAJaEnMO/Qfr5RWwl1j7QhokzCKgKrH13BJm EFtUIE1i+uF+RhCbV0BQ4uTMJ2BjOAVsJaYcvgk10lbiztzdzBC2vETz1tnMExj5ZyFpmYWk bBaSsgWMzKsY5RJzSnN1cxMzc4pTk3WLkxPz8lKLdI30cjNL9FJTSjcxQoKUdwfj/3UyhxgF OBiVeHgfbJ8eLsSaWFZcmXuIUZKDSUmUV20xUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIbxQw NoR4UxIrq1KL8mFS0hwsSuK8akvU/YQE0hNLUrNTUwtSi2CyMhwcShK8v68CNQoWpaanVqRl 5pQgpJk4OEGG8wANDwap4S0uSMwtzkyHyJ9iVJQS51UG2SoAksgozYPrhSWRV4ziQK8I814C aecBJiC47ldAg5mABi/gmQwyuCQRISXVwFheK/T71qXZRwK+zlu89dvUj6LcFfW+YVtsxXa1 r314+8GPBYsz23PWXI4raL7LtY7n5G9b5Z+vGGpvdWexL408YBjgfsODK/TrtQYlzlk/GS3v n1ta//mW6YpF014KaYgFW97ZIDUnL+rXh4/xmxKrrklncE8703DOdM1U8cxL1pznr5YuWLda iaU4I9FQi7moOBEAnkm4+P0CAAA= Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 21:32:30 -0000 On 7/26/16 5:07 PM, James Winterbottom wrote: > Thanks Henning and Paul, > > The argument still feels a bit like we dont have anything today, HELD > is too heavy weight, give us encoded location in the header. I guess my > worry with this is two fold: > 1) providing this means there is never an incentive to move towards a > more standardised location approach, I will cite the eCall MSD is a good > example of where this has occurred. > 2) It gives the first push down the very long slide of geo URIs are > fine for conveying target location. I think the incentive to move will be NG911. Also, this is a small community that operates under rules set by the FCC. > My strongest preference would be to find someway for this to provide a > serious stepping-stone towards NG formats and protocols, rather than > providing a mechanism that once implemented gives no incentive to move > mainstream. Just including location is a big step. And currently the VRS providers handle their 911 calls via separate providers, using static location information. Working through moving to dynamic location information will also be a step. Thanks, Paul > It would be good to hear if anyone else on the list has similar concerns. > > Cheers > James > > >> On 27 Jul 2016, at 2:17 AM, Henning Schulzrinne >> > wrote: >> >> [Typing this from the Athen's airport] >> >> Adding to this: >> >> In this particular use case, there is indeed a "device location" - the >> only location reported is what the handset (Android/IOS) device >> believes the location is - and this better be the location of the >> device, not something else. Anything else would be a bug or malicious >> location spoofing. There is no HELD or other external reference involved. >> >> Given that the privacy indicators convey no information in this case >> (and thus would have to be hard-coded to the no-restrictions values to >> avoid emergency call failures), I fail to see the substantive, as >> opposed to protocol-lawyering, difference. The information is going to >> be exactly the same, whether I do this by cdata PIDF-LO attachment >> "legally" or by geo URL "illegally". >> >> Also, the VRS 911 situation is somewhat unique in that there are three >> entities involved in the call: the VRS provider and its communication >> assistant (the person translating between voice and ASL), a >> third-party emergency service provider and the PSAP with related >> system service providers. Until native NG911/i3 is common, the most >> likely case is that the VRS provider will pick apart the SIP request >> and inject the location via a proprietary API. >> >> All three entities have their own data retention and disclosure rules, >> which may vary by state, and are likely unknown upstream. >> >> Given the absence of HELD in this environment, at least for the >> foreseeable future, insisting on carrying the same information in an >> XML attachment instead of a header, means that the emergency calls >> need a completely different code path since they are the only ones >> with multi-part. This is seen as a really bad trade-off of reliability >> and simplicity vs. formal requirements that serve no obvious privacy >> or functionality purpose. >> >> If there's a technical argument, rather than a legalistic one, please >> explain in more detail, as I'm obviously missing it. >> >> I assume you mean "illegal" figuratively, as I might need to get a >> protocol lawyer otherwise :-) >> >> >> Henning >> >> ------------------------------------------------------------------------ >> *From:* dispatch > > on behalf of Paul Kyzivat >> > >> *Sent:* Tuesday, July 26, 2016 11:20:08 AM >> *To:* dispatch@ietf.org >> *Subject:* Re: [dispatch] Strong concerns with location encoding in >> draft-vrs-rue-dispatch-00 >> >> James, >> >> Henning is traveling, so we may not hear from him for a bit. >> >> Using geo: was not my first choice, precisely because it isn't included >> among the permissible ways of conveying the information. But it is a >> hard sell among the VRS community. For this use the alternative would be >> putting the location in the body, which is felt to be complex. >> >> Note that the context for this usage is only 911 calls. I got the >> following private comment from Henning: >> >> > Privacy indicators in US 911 SIP requests are both meaningless and >> > possibly disruptive. Since US VRS and 911 retention and disclosure >> > policies are given by law and custom and not subject to user control, >> > there are only two options: >> > >> > (1) Ignore the settings in PIDF-LO, i.e., the user believes one thing >> > that's happening, but reality is something else. >> > >> > (2) Reject the 911 call, since the VRS provider and 911 provider cannot >> > and will not honor the requested privacy policy. Clearly not acceptable. >> >> (I'm not personally familiar with the US regulations - I trust Henning >> on this.) >> >> The current situation is that VRS users *are* using mobile devices for >> 911 calls, and the location initially communicated for those calls is >> currently *static*. The actual location must be provided within the call >> by the deaf caller, using ASL. We are trying to improve on that. >> >> Thanks, >> Paul >> >> On 7/25/16 4:51 AM, James Winterbottom wrote: >> > Hi Paul and Henning, >> > >> > I was reading through your draft but had to have a double take in >> > Section 11.4, it says the following: >> > >> > " >> >> location information MUST be conveyed with a "geo:" URI in a >> >> Geolocation header field, as defined in [RFC5870 ]. >> >> >> >> (While section 4.1 of [RFC6442] prohibits this usage, >> the reasons >> >> for doing so do not apply to emergency calls.) >> > >> > >> > The problem here that this is an illegal used of the encoding in RFC >> > 5870. The reason is that the way it is being used directly identifies as >> > device or user and so it falls subject to the requirements of a Geopriv >> > using protocol. From section 9.2 of RFC 5870: >> > " >> >> A 'geo' URI by itself is just an opaque reference to a physical >> >> location, expressed by a set of spatial coordinates. This does not >> >> fit the "Location Information" definition according to Section 5.2 of >> >> GEOPRIV Requirements [RFC3693 ], because there is not necessarily a >> >> "Device" involved. >> >> >> >> Because there is also no way to specify the identity of a "Target" >> >> within the confines of a 'geo' URI, it also does not fit the >> >> specification of a "Location Object" (Section 5.2 of RFC 3693 ). >> >> >> >> However, if a 'geo' URI is used in a context where it identifies the >> >> location of a Target, it becomes part of a Location Object and is >> >> therefore subject to GEOPRIV rules. >> >> >> >> Therefore, when 'geo' URIs are put into such contexts, the privacy >> >> requirements of RFC 3693 MUST be met. >> > >> > In order for encoding of location to proceed in this form for the VRS >> > application I think far better rationale needs to be provided and it >> > needs to be demonstrated why the use case falls outside of the >> > constraints imposed by RFC 3693. >> > >> > Cheers >> > James >> > >> > >> > >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Jul 27 10:39:35 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D785412D0FD for ; Wed, 27 Jul 2016 10:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dsr6-UG2naFt for ; Wed, 27 Jul 2016 10:39:34 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 2230112D0E6 for ; Wed, 27 Jul 2016 10:39:34 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-10v.sys.comcast.net with SMTP id SSnXb4vYNRingSSntbzlBe; Wed, 27 Jul 2016 17:39:33 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id SSnsbnsKyDgDkSSntb8uze; Wed, 27 Jul 2016 17:39:33 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6RHdVNZ009026; Wed, 27 Jul 2016 13:39:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6RHdVA4009023; Wed, 27 Jul 2016 13:39:31 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ranjit Avasarala In-Reply-To: (ranjitkav0811@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 27 Jul 2016 13:39:31 -0400 Message-ID: <87bn1jnfos.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfC2fEjE1Hb2OOFSdh9lkJBJKYGfWP7KgdDjUdpP/52yZR5YqlkdsfU9V9tEWwh9tEyEWndnayk9N00NkFZP99aFllpbrMQ2dMKG93S/tMcU01rqId0sT wTY/FHnxD2AjMylfR2yt0lBPHKMWYTyHs2fmgbKcvAjg+p5xGipZ6SWCg1ub/7pvfIqN0dEq+otu093KXVF5GAYg016fwGjQ0Hk= Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Query on SIP 380 response for emergency service X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 17:39:35 -0000 Ranjit Avasarala writes: > There was an emergency outage sometime back and the emergency service > returned a 380 Alternate Service response. But the wireshark call traces > do not capture 380, but always show 300 Multiple Choices response. > > Though 380 is considered a success case along with 300, I am curious why > the call trace does not show 380 but shows 300. I suspect the reason is that 380 is being intercepted and acted upon by a proxy that is downstream of the point that you are watching with Wireshark, much as a 301 response would be. By contrast, 300 cannot be acted upon automatically. RFC 3261 section 21.3.1: The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location. Dale From nobody Wed Jul 27 10:48:24 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D313512D108 for ; Wed, 27 Jul 2016 10:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gma55n8rQpkf for ; Wed, 27 Jul 2016 10:48:22 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 A44F712D0FD for ; Wed, 27 Jul 2016 10:48:21 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id q128so7549521wma.1 for ; Wed, 27 Jul 2016 10:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IjGuSjDEdHA0kAws0jzKL3ka0QFgDYyW6Qww0sVTCY4=; b=W/Mt0yuqJn3sA4ANx0miF9693nuQph3b+b+eAQT/tRoYD+oXw0dHHG9Mh/JXX1S0P4 19G9FUC/1WkjfheW3lkqdHfQAt6q38yg4DfZvUKANI3b6hq1O3s/ltqlWjzynAVLmwEf LNLdNwj6P6ACfIG4VbX9RpjIAZYEWZExDcmywLjMI8Up+koHce83dfjea7XfUPGzZcx+ hEWTCrkZdKrVKNqRJOWFxFJsLKL50ZH8vZb1/4gB8SvNwwOhNmS/tf0v4O857CvgCaaM Iy4Gybhsr9Dd9hPpamWAaZHACNFA0yMFZZViNf4EjjXn8GwSaia0ZJPw3y0rSy3Wk/kq loTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IjGuSjDEdHA0kAws0jzKL3ka0QFgDYyW6Qww0sVTCY4=; b=XrFzku/p0F87jwG1OwzCMRRI58rHmg1KSs7q5j6ez8kuXukA8TTYo8cFHGeBlUjuC6 dn4BMHF09gbCSd9M7s+aVRoGavRkxzmJBomUou6sg+s1nMKureTgmgkLAhsW5MC7O2kw Pmyd86B94it6KYruzeUP6fB1I+AibNHllgePlWpNHvhgyAB1M+PH945stCM3FzWxGTiE xGljDBev48j4DM9QLZAtO7ClO71933VlXxeZ7UAhTIe9NZ2wVzvenBYIekRA3yIVtooa PzzAWSV6F+3rWeXLW+s/bhcpRNNf35AhO/IOHlqOhVCaoVweLSFBv/SefqSrNgCTA+53 F8lQ== X-Gm-Message-State: AEkoouuPaHEoaLqRWutvQg5bZQEVqwnVq3Yx9RZaHrpKTZI/Her8pQHIPiTGvSH48Juyc3FQ8Im+beN8UAOaiw== X-Received: by 10.194.11.72 with SMTP id o8mr31215174wjb.10.1469641699929; Wed, 27 Jul 2016 10:48:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.96.139 with HTTP; Wed, 27 Jul 2016 10:48:19 -0700 (PDT) In-Reply-To: <87bn1jnfos.fsf@hobgoblin.ariadne.com> References: <87bn1jnfos.fsf@hobgoblin.ariadne.com> From: Ranjit Avasarala Date: Wed, 27 Jul 2016 12:48:19 -0500 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=e89a8f234d4978f2600538a19f38 Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Query on SIP 380 response for emergency service X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 17:48:24 -0000 --e89a8f234d4978f2600538a19f38 Content-Type: text/plain; charset=UTF-8 True. so does this mean that all 380 responses would be intercepted as 300 responses? Regards Ranjit On Wed, Jul 27, 2016 at 12:39 PM, Dale R. Worley wrote: > Ranjit Avasarala writes: > > There was an emergency outage sometime back and the emergency service > > returned a 380 Alternate Service response. But the wireshark call traces > > do not capture 380, but always show 300 Multiple Choices response. > > > > Though 380 is considered a success case along with 300, I am curious why > > the call trace does not show 380 but shows 300. > > I suspect the reason is that 380 is being intercepted and acted upon by > a proxy that is downstream of the point that you are watching with > Wireshark, much as a 301 response would be. By contrast, 300 cannot be > acted upon automatically. RFC 3261 section 21.3.1: > > The address in the request resolved to several choices, each with its > own specific location, and the user (or UA) can select a preferred > communication end point and redirect its request to that location. > > Dale > --e89a8f234d4978f2600538a19f38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
True. so does this mean that all 380 responses w= ould be intercepted as 300 responses?

Regards
Ranjit=

On Wed,= Jul 27, 2016 at 12:39 PM, Dale R. Worley <worley@ariadne.com> wrote:
Ranjit Avasarala <ranjitkav0811@gmail.com> writes:=
> There was an emergency outage sometime back and the emergency service<= br> > returned a 380 Alternate Service response.=C2=A0 But the wireshark cal= l traces
> do not capture 380, but always show 300 Multiple Choices response.
>
> Though 380 is considered a success case along with 300, I am curious w= hy
> the call trace does not show 380 but shows 300.

I suspect the reason is that 380 is being intercepted and acted upon by
a proxy that is downstream of the point that you are watching with
Wireshark, much as a 301 response would be.=C2=A0 By contrast, 300 cannot b= e
acted upon automatically.=C2=A0 RFC 3261 section 21.3.1:

=C2=A0 =C2=A0The address in the request resolved to several choices, each w= ith its
=C2=A0 =C2=A0own specific location, and the user (or UA) can select a prefe= rred
=C2=A0 =C2=A0communication end point and redirect its request to that locat= ion.

Dale

--e89a8f234d4978f2600538a19f38-- From nobody Thu Jul 28 12:41:20 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB18312E081 for ; Thu, 28 Jul 2016 12:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oETPQylKv4OF for ; Thu, 28 Jul 2016 12:41:18 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 1194A12D08C for ; Thu, 28 Jul 2016 12:41:18 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-10v.sys.comcast.net with SMTP id Sr9mb6kY1RingSrBFb3QGO; Thu, 28 Jul 2016 19:41:17 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id SrBEbzpMkMJgPSrBEbLcOB; Thu, 28 Jul 2016 19:41:17 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u6SJfFEO006135; Thu, 28 Jul 2016 15:41:15 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u6SJfFso006132; Thu, 28 Jul 2016 15:41:15 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Ranjit Avasarala In-Reply-To: (ranjitkav0811@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 28 Jul 2016 15:41:15 -0400 Message-ID: <87popxlfdw.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfBk8lc9ngtqIbeVY/fj61Jp/jvQLeKbkZzJuC710CaRO9q7Rx643qglgCFKUQnzp67ZV0OwTAme7Olsdmnze7a/I8Uu7+z9Qj8baOzmaQBvpQp68xoHN rBbExPcfEJcaQz6ckf4wPdDWwpyAu8fVjJdIJ/9M9PTOJ+gGI83FXpw8XjT3n4gaHo86I5XIny8NUb0WoSRO61mmMWFmiijp3Zg= Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Query on SIP 380 response for emergency service X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 19:41:19 -0000 Ranjit Avasarala writes: > True. so does this mean that all 380 responses would be intercepted as 300 > responses? A proxy may intercept and act on 3xx (RFC 3261 section 16.7 item 4), but is not required to. Dale From nobody Sun Jul 31 23:43:53 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5329E12D12D for ; Sun, 31 Jul 2016 23:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTKozmoRsczb for ; Sun, 31 Jul 2016 23:43:46 -0700 (PDT) Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 B5A7412D0B2 for ; Sun, 31 Jul 2016 23:43:45 -0700 (PDT) X-Halon-ID: 42e15049-57b3-11e6-8d74-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.136] (unknown [85.238.221.179]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 1 Aug 2016 08:43:31 +0200 (CEST) To: Paul Kyzivat , James Winterbottom , Henning Schulzrinne References: <7BB6D8A6-86E4-48BE-A526-B8963791009A@gmail.com> <7a228246-90f0-3fc0-58f0-dc014897a6e4@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Mon, 1 Aug 2016 08:43:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7a228246-90f0-3fc0-58f0-dc014897a6e4@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------C2B1F5DBE83FEF7C4E351061" Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Strong concerns with location encoding in draft-vrs-rue-dispatch-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 06:43:50 -0000 This is a multi-part message in MIME format. --------------C2B1F5DBE83FEF7C4E351061 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Den 2016-07-26 kl. 23:32, skrev Paul Kyzivat: > On 7/26/16 5:07 PM, James Winterbottom wrote: >> Thanks Henning and Paul, >> >> The argument still feels a bit like we dont have anything today, HELD >> is too heavy weight, give us encoded location in the header. I guess my >> worry with this is two fold: >> 1) providing this means there is never an incentive to move towards a >> more standardised location approach, I will cite the eCall MSD is a good >> example of where this has occurred. >> 2) It gives the first push down the very long slide of geo URIs are >> fine for conveying target location. > > I think the incentive to move will be NG911. > > Also, this is a small community that operates under rules set by the FCC. > >> My strongest preference would be to find someway for this to provide a >> serious stepping-stone towards NG formats and protocols, rather than >> providing a mechanism that once implemented gives no incentive to move >> mainstream. > > Just including location is a big step. And currently the VRS providers > handle their 911 calls via separate providers, using static location > information. Working through moving to dynamic location information > will also be a step. > > Thanks, > Paul > >> It would be good to hear if anyone else on the list has similar >> concerns. GH: I see this as a step towards eternal interoperability problems and finally requirements for geo: location acceptance in the NGxxx services. Some reasons: When the services get direct interface with NG9-1-1, they will be required to deliver location according to RFC 6442. Then it will be tempting to force the terminals to do so from the source. But then the terminals may need to deliver GEO: to some vrs services and PIDF-LO in other calls, depending on at what step the services are in adaptation to NG9-1-1. Further delaying proper multipart body handling in UEs and servers is not good. More and more RFCs are appearing that require multipart body handling. Support of RUE:s could instead be a good incentive to get multipart body support implemented. In the introduction, it is stated: " This RUE profile supports the requirements of relay services in the United States, as described in 47 CFR 64.601 et seq., but may be applicable to similar uses elsewhere." " This limitation to USA should be stated in the scope as well. There are many US-specific aspects in the draft that need to be modified before applied elsewhere. The MUST for use of GEO: is likely one of them. If not, the conflict between use of geo: and rfc 6442 compliant location will spread. What is the goal for the draft? Does it have ambitions to be dispatched and accepted as a WG document? Regards Gunnar >> >> Cheers >> James >> >> >>> On 27 Jul 2016, at 2:17 AM, Henning Schulzrinne >>> > >>> wrote: >>> >>> [Typing this from the Athen's airport] >>> >>> Adding to this: >>> >>> In this particular use case, there is indeed a "device location" - the >>> only location reported is what the handset (Android/IOS) device >>> believes the location is - and this better be the location of the >>> device, not something else. Anything else would be a bug or malicious >>> location spoofing. There is no HELD or other external reference >>> involved. >>> >>> Given that the privacy indicators convey no information in this case >>> (and thus would have to be hard-coded to the no-restrictions values to >>> avoid emergency call failures), I fail to see the substantive, as >>> opposed to protocol-lawyering, difference. The information is going to >>> be exactly the same, whether I do this by cdata PIDF-LO attachment >>> "legally" or by geo URL "illegally". >>> >>> Also, the VRS 911 situation is somewhat unique in that there are three >>> entities involved in the call: the VRS provider and its communication >>> assistant (the person translating between voice and ASL), a >>> third-party emergency service provider and the PSAP with related >>> system service providers. Until native NG911/i3 is common, the most >>> likely case is that the VRS provider will pick apart the SIP request >>> and inject the location via a proprietary API. >>> >>> All three entities have their own data retention and disclosure rules, >>> which may vary by state, and are likely unknown upstream. >>> >>> Given the absence of HELD in this environment, at least for the >>> foreseeable future, insisting on carrying the same information in an >>> XML attachment instead of a header, means that the emergency calls >>> need a completely different code path since they are the only ones >>> with multi-part. This is seen as a really bad trade-off of reliability >>> and simplicity vs. formal requirements that serve no obvious privacy >>> or functionality purpose. >>> >>> If there's a technical argument, rather than a legalistic one, please >>> explain in more detail, as I'm obviously missing it. >>> >>> I assume you mean "illegal" figuratively, as I might need to get a >>> protocol lawyer otherwise :-) >>> >>> >>> Henning >>> >>> ------------------------------------------------------------------------ >>> >>> *From:* dispatch >> > on behalf of Paul Kyzivat >>> > >>> *Sent:* Tuesday, July 26, 2016 11:20:08 AM >>> *To:* dispatch@ietf.org >>> *Subject:* Re: [dispatch] Strong concerns with location encoding in >>> draft-vrs-rue-dispatch-00 >>> >>> James, >>> >>> Henning is traveling, so we may not hear from him for a bit. >>> >>> Using geo: was not my first choice, precisely because it isn't included >>> among the permissible ways of conveying the information. But it is a >>> hard sell among the VRS community. For this use the alternative >>> would be >>> putting the location in the body, which is felt to be complex. >>> >>> Note that the context for this usage is only 911 calls. I got the >>> following private comment from Henning: >>> >>> > Privacy indicators in US 911 SIP requests are both meaningless and >>> > possibly disruptive. Since US VRS and 911 retention and disclosure >>> > policies are given by law and custom and not subject to user control, >>> > there are only two options: >>> > >>> > (1) Ignore the settings in PIDF-LO, i.e., the user believes one thing >>> > that's happening, but reality is something else. >>> > >>> > (2) Reject the 911 call, since the VRS provider and 911 provider >>> cannot >>> > and will not honor the requested privacy policy. Clearly not >>> acceptable. >>> >>> (I'm not personally familiar with the US regulations - I trust Henning >>> on this.) >>> >>> The current situation is that VRS users *are* using mobile devices for >>> 911 calls, and the location initially communicated for those calls is >>> currently *static*. The actual location must be provided within the >>> call >>> by the deaf caller, using ASL. We are trying to improve on that. >>> >>> Thanks, >>> Paul >>> >>> On 7/25/16 4:51 AM, James Winterbottom wrote: >>> > Hi Paul and Henning, >>> > >>> > I was reading through your draft but had to have a double take in >>> > Section 11.4, it says the following: >>> > >>> > " >>> >> location information MUST be conveyed with a "geo:" URI in a >>> >> Geolocation header field, as defined in [RFC5870 >>> ]. >>> >> >>> >> (While section 4.1 of [RFC6442] >>> prohibits this usage, >>> the reasons >>> >> for doing so do not apply to emergency calls.) >>> > >>> > >>> > The problem here that this is an illegal used of the encoding in RFC >>> > 5870. The reason is that the way it is being used directly >>> identifies as >>> > device or user and so it falls subject to the requirements of a >>> Geopriv >>> > using protocol. From section 9.2 of RFC 5870: >>> > " >>> >> A 'geo' URI by itself is just an opaque reference to a physical >>> >> location, expressed by a set of spatial coordinates. This >>> does not >>> >> fit the "Location Information" definition according to Section >>> 5.2 of >>> >> GEOPRIV Requirements [RFC3693 >>> ], because there is not >>> necessarily a >>> >> "Device" involved. >>> >> >>> >> Because there is also no way to specify the identity of a >>> "Target" >>> >> within the confines of a 'geo' URI, it also does not fit the >>> >> specification of a "Location Object" (Section 5.2 of RFC 3693 >>> ). >>> >> >>> >> However, if a 'geo' URI is used in a context where it >>> identifies the >>> >> location of a Target, it becomes part of a Location Object and is >>> >> therefore subject to GEOPRIV rules. >>> >> >>> >> Therefore, when 'geo' URIs are put into such contexts, the >>> privacy >>> >> requirements of RFC 3693 >>> MUST be met. >>> > >>> > In order for encoding of location to proceed in this form for the VRS >>> > application I think far better rationale needs to be provided and it >>> > needs to be demonstrated why the use case falls outside of the >>> > constraints imposed by RFC 3693. >>> > >>> > Cheers >>> > James >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > dispatch mailing list >>> > dispatch@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dispatch >>> > >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- ----------------------------------------- Gunnar Hellstrm Omnitor gunnar.hellstrom@omnitor.se --------------C2B1F5DBE83FEF7C4E351061 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Den 2016-07-26 kl. 23:32, skrev Paul Kyzivat:

On 7/26/16 5:07 PM, James Winterbottom wrote:
Thanks Henning and Paul,

The argument still feels a bit like we dont have anything today, HELD
is too heavy weight, give us encoded location in the header. I guess my
worry with this is two fold:
1) providing this means there is never an incentive to move towards a
more standardised location approach, I will cite the eCall MSD is a good
example of where this has occurred.
2) It gives the first push down the very long slide of geo URIs are
fine for conveying target location.

I think the incentive to move will be NG911.

Also, this is a small community that operates under rules set by the FCC.

My strongest preference would be to find someway for this to provide a
serious stepping-stone towards NG formats and protocols, rather than
providing a mechanism that once implemented gives no incentive to move
mainstream.

Just including location is a big step. And currently the VRS providers handle their 911 calls via separate providers, using static location information. Working through moving to dynamic location information will also be a step.

Thanks,
Paul

It would be good to hear if anyone else on the list has similar concerns.
GH: I see this as a step towards eternal interoperability problems and finally requirements for geo: location acceptance in the NGxxx services.

Some reasons:

When the services get direct interface with NG9-1-1, they will be required to deliver location according to RFC 6442. Then it will be tempting to force the terminals to do so from the source. But then the terminals may need to deliver GEO: to some vrs services and PIDF-LO in other calls, depending on at what step the services are in adaptation to NG9-1-1.

Further delaying proper multipart body handling in UEs and servers is not good. More and more RFCs are appearing that require multipart body handling. Support of RUE:s could instead be a good incentive to get multipart body support implemented.

In the introduction, it is stated:
"
   This RUE profile supports the requirements of relay services in the
   United States, as described in 47 CFR 64.601 et seq., but may be
   applicable to similar uses elsewhere."
"
This limitation to USA should be stated in the scope as well. There are many US-specific aspects in the draft that need to be modified before applied elsewhere. The MUST for use of GEO: is likely one of them. If not, the conflict between use of geo: and rfc 6442 compliant location will spread.

What is the goal for the draft? Does it have ambitions to be dispatched and accepted as a WG document?

Regards
Gunnar


Cheers
James


On 27 Jul 2016, at 2:17 AM, Henning Schulzrinne
<Henning.Schulzrinne@fcc.gov <mailto:Henning.Schulzrinne@fcc.gov>> wrote:

[Typing this from the Athen's airport]

Adding to this:

In this particular use case, there is indeed a "device location" - the
only location reported is what the handset (Android/IOS) device
believes the location is - and this better be the location of the
device, not something else. Anything else would be a bug or malicious
location spoofing. There is no HELD or other external reference involved.

Given that the privacy indicators convey no information in this case
(and thus would have to be hard-coded to the no-restrictions values to
avoid emergency call failures), I fail to see the substantive, as
opposed to protocol-lawyering, difference. The information is going to
be exactly the same, whether I do this by cdata PIDF-LO attachment
"legally" or by geo URL "illegally".

Also, the VRS 911 situation is somewhat unique in that there are three
entities involved in the call: the VRS provider and its communication
assistant (the person translating between voice and ASL), a
third-party emergency service provider and the PSAP with related
system service providers. Until native NG911/i3 is common, the most
likely case is that the VRS provider will pick apart the SIP request
and inject the location via a proprietary API.

All three entities have their own data retention and disclosure rules,
which may vary by state, and are likely unknown upstream.

Given the absence of HELD in this environment, at least for the
foreseeable future, insisting on carrying the same information in an
XML attachment instead of a header, means that the emergency calls
need a completely different code path since they are the only ones
with multi-part. This is seen as a really bad trade-off of reliability
and simplicity vs. formal requirements that serve no obvious privacy
or functionality purpose.

If there's a technical argument, rather than a legalistic one, please
explain in more detail, as I'm obviously missing it.

I assume you mean "illegal" figuratively, as I might need to get a
protocol lawyer otherwise :-)


Henning

------------------------------------------------------------------------
*From:* dispatch <dispatch-bounces@ietf.org
<mailto:dispatch-bounces@ietf.org>> on behalf of Paul Kyzivat
<pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>
*Sent:* Tuesday, July 26, 2016 11:20:08 AM
*To:* dispatch@ietf.org <mailto:dispatch@ietf.org>
*Subject:* Re: [dispatch] Strong concerns with location encoding in
draft-vrs-rue-dispatch-00

James,

Henning is traveling, so we may not hear from him for a bit.

Using geo: was not my first choice, precisely because it isn't included
among the permissible ways of conveying the information. But it is a
hard sell among the VRS community. For this use the alternative would be
putting the location in the body, which is felt to be complex.

Note that the context for this usage is only 911 calls. I got the
following private comment from Henning:

> Privacy indicators in US 911 SIP requests are both meaningless and
> possibly disruptive. Since US VRS and 911 retention and disclosure
> policies are given by law and custom and not subject to user control,
> there are only two options:
>
> (1) Ignore the settings in PIDF-LO, i.e., the user believes one thing
> that's happening, but reality is something else.
>
> (2) Reject the 911 call, since the VRS provider and 911 provider cannot
> and will not honor the requested privacy policy. Clearly not acceptable.

(I'm not personally familiar with the US regulations - I trust Henning
on this.)

The current situation is that VRS users *are* using mobile devices for
911 calls, and the location initially communicated for those calls is
currently *static*. The actual location must be provided within the call
by the deaf caller, using ASL. We are trying to improve on that.

Thanks,
Paul

On 7/25/16 4:51 AM, James Winterbottom wrote:
> Hi Paul and Henning,
>
> I was reading through your draft but had to have a double take in
> Section 11.4, it says the following:
>
> "
>> location information MUST be conveyed with a "geo:" URI in a
>> Geolocation header field, as defined in [RFC5870 <https://tools.ietf.org/html/rfc5870>].
>>
>> (While section 4.1 of [RFC6442] <https://tools.ietf.org/html/rfc6442#section-4.1> prohibits this usage,
the reasons
>> for doing so do not apply to emergency calls.)
>
>
> The problem here that this is an illegal used of the encoding in RFC
> 5870. The reason is that the way it is being used directly identifies as
> device or user and so it falls subject to the requirements of a Geopriv
> using protocol. From section 9.2 of RFC 5870:
> "
>> A 'geo' URI by itself is just an opaque reference to a physical
>> location, expressed by a set of spatial coordinates. This does not
>> fit the "Location Information" definition according to Section 5.2 <https://tools.ietf.org/html/rfc5870#section-5.2> of
>> GEOPRIV Requirements [RFC3693 <https://tools.ietf.org/html/rfc3693>], because there is not necessarily a
>> "Device" involved.
>>
>> Because there is also no way to specify the identity of a "Target"
>> within the confines of a 'geo' URI, it also does not fit the
>> specification of a "Location Object" (Section 5.2 of RFC 3693 <https://tools.ietf.org/html/rfc3693#section-5.2>).
>>
>> However, if a 'geo' URI is used in a context where it identifies the
>> location of a Target, it becomes part of a Location Object and is
>> therefore subject to GEOPRIV rules.
>>
>> Therefore, when 'geo' URIs are put into such contexts, the privacy
>> requirements of RFC 3693 <https://tools.ietf.org/html/rfc3693> MUST be met.
>
> In order for encoding of location to proceed in this form for the VRS
> application I think far better rationale needs to be provided and it
> needs to be demonstrated why the use case falls outside of the
> constraints imposed by RFC 3693.
>
> Cheers
> James
>
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org <mailto:dispatch@ietf.org>
> https://www.ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org <mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org <mailto:dispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/dispatch


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

-- 
-----------------------------------------
Gunnar Hellstrm
Omnitor
gunnar.hellstrom@omnitor.se
--------------C2B1F5DBE83FEF7C4E351061--