From nobody Mon Mar 2 08:26:19 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6432F1A1B80 for ; Mon, 2 Mar 2015 08:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMJkXcequcik for ; Mon, 2 Mar 2015 08:26:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46AF1A1AE8 for ; Mon, 2 Mar 2015 08:26:10 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id DEC2126415F; Mon, 2 Mar 2015 17:26:08 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A47A427C138; Mon, 2 Mar 2015 17:26:08 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Mon, 2 Mar 2015 17:26:08 +0100 From: To: Parthasarathi R , "dispatch@ietf.org" Thread-Topic: [dispatch] PCP for SIP Deployments Thread-Index: AdBRpv5w7XTmu/weRVKc3+vCrIJ62gBNLj+AAIpjqiA= Date: Mon, 2 Mar 2015 16:26:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049185EA@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300491577E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <023901d052df$6056f2c0$2104d840$@co.in> In-Reply-To: <023901d052df$6056f2c0$2104d840$@co.in> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049185EAOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.73920 Archived-At: Subject: Re: [dispatch] PCP for SIP Deployments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:26:18 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049185EAOPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Partha, Many thanks for the review and the comments. I integrated almost all your suggestion, except the one about the ICE discu= ssion. The reason for that is ICE is not deployed in the managed context; a= s such I'm afraid there is no value in having such discussion in the I-D. Please check the diff and let me know if you have further comments. URL: http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip= -ipv6-04.txt Status: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ip= v6/ Htmlized: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-= ipv6-04 Thank you. Cheers, Med De : Parthasarathi R [mailto:partha@parthasarathi.co.in] Envoy=E9 : vendredi 27 f=E9vrier 2015 23:47 =C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org Objet : RE: [dispatch] PCP for SIP Deployments Hi Med, It is a interesting draft. The current writing provides PCP advantages in S= IP managed network and particularly cellular. The following information has= to be added to provide more clarity about this work: 1) Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP client, = PCP server 2) Basic callflow to show how the dialog is established in case P2P is= used 3) The draft title mentions IPv6. My understanding is that this shall = be used for IPv4 network as well. 4) Add more details about how SIP, PCP, ICE interworking happens as th= e current reference is related to PCP with rtcweb only. 5) Security implication w.r.t SIP usage of PCP has to be mentioned. 6) Advantage of using PCP over TURN in SIP network shall be provided i= n the introduction section for better comparison. Regards Partha From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of mohamed.bouc= adair@orange.com Sent: Thursday, February 26, 2015 3:02 PM To: dispatch@ietf.org Subject: [dispatch] PCP for SIP Deployments Hi all, I would like to share with this group a short document that explains how PC= P can be of great use in the context SIP-based services: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03 As indicated in the I-D, the main benefits include (but not limited to): o Avoid embedding an ALG in the middleboxes. Note, ALGs are not recommended since the evolution of the service would depend on the ALG maintenance. o Not require any Hosted NAT Traversal function (e.g., [RFC7362]) to be embedded in the SIP server. Intermediate NATs and firewalls are transparent to the SIP service platform. o Avoid overloading the network with keepalive message to maintain the mapping in intermediate middleboxes. o Work without requiring symmetric RTP/RTCP [RFC4961]. o Not require symmetric SIP to work (i.e., rport [RFC3581]). o Easily support unidirectional sessions. When this document was first presented in the PCP WG, I was suggested that = it is better to publish it in RAI with a review from the PCP WG. Hence, thi= s message to the list. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B9330049185EAOPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Partha,

 

Many thanks for the review and = the comments.

 

I integrated almost all your su= ggestion, except the one about the ICE discussion. The reason for that is I= CE is not deployed in the managed context; as such I’m afraid there is no value in having such discussion in the I-D. <= o:p>

 

Please check the diff and let m= e know if you have further comments.

 

URL:    =         http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-ipv6-04.tx= t

Status:   &nb= sp;     https://datatracker= .ietf.org/doc/draft-boucadair-pcp-sip-ipv6/=

Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-= boucadair-pcp-sip-ipv6-04=

Diff:    = ;       http:= //www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-ipv6-04

 

Thank you.

 

Cheers,

Med

 

 

De : Parthasarathi R [mailto:partha@parthasarathi.co.i= n]
Envoy=E9 : vendredi 27 f=E9vrier 2015 23:47<= br> =C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org
Objet : RE: [dispatch] PCP for SIP Deployments

 

Hi Med,=

&n= bsp;

It is a= interesting draft. The current writing provides PCP advantages in SIP mana= ged network and particularly cellular. The following information has to be = added to provide more clarity about this work:

&n= bsp;

= 1)      Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP client, PCP ser= ver

= 2)      Basic callflow to show how the dialog is established in case P2P is used

= 3)      The draft title mentions IPv6. My understanding is that this shall be used= for IPv4 network as well.

= 4)      Add more details about how SIP, PCP, ICE interworking happens as the curre= nt reference is related to PCP with rtcweb only.

= 5)      Security implication w.r.t SIP usage of PCP has to be mentioned.

= 6)      Advantage of using PCP over TURN in SIP network shall be provided in the i= ntroduction section for better comparison.

&n= bsp;

Regards=

Partha<= o:p>

&n= bsp;

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Thursday, February 26, 2015 3:02 PM
To: dispatch@ietf.org
Subject: [dispatch] PCP for SIP Deployments

 

Hi all,

 

I would like to share with this group a sho= rt document that explains how PCP can be of great use in the context SIP-ba= sed services:

http://tools.ietf.org/html/draft-boucadair-pcp-= sip-ipv6-03

 

As indicated in the I-D, the main benefits = include (but not limited to):

 

   o  Avoid embedding an ALG in the middleboxe=
s.  Note, ALGs are not
      recommended since the evolutio=
n of the service would depend on the
      ALG maintenance.
   o  Not require any Hosted NAT Traversal fun=
ction (e.g., [RFC7362]) to
      be embedded in the SIP server.=
  Intermediate NATs and firewalls
      are transparent to the SIP ser=
vice platform.
   o  Avoid overloading the network with keepa=
live message to maintain
      the mapping in intermediate mi=
ddleboxes.
   o  Work without requiring symmetric RTP/RTC=
P [RFC4961].
   o  Not require symmetric SIP to work (i.e.,=
 rport [RFC3581]).
   o  Easily support unidirectional sessions.<=
o:p>

 

When this document was first presented in t= he PCP WG, I was suggested that it is better to publish it in RAI with a re= view from the PCP WG. Hence, this message to the list.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B9330049185EAOPEXCLILM23corp_-- From nobody Tue Mar 3 13:12:55 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE371AC449 for ; Tue, 3 Mar 2015 13:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 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, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSgnE0kAKozo for ; Tue, 3 Mar 2015 13:12:53 -0800 (PST) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::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 58CEF1AC447 for ; Tue, 3 Mar 2015 13:12:53 -0800 (PST) Received: by labge10 with SMTP id ge10so40248508lab.12 for ; Tue, 03 Mar 2015 13:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=XoSMivCkbX6L4AhTPK9YbtVO5vkAyN36p7DjQvW7fqM=; b=eEh9pYQKVShzGCM8FJH9WyJqGLaZJoUZwPX957U6ZeqCUwZkEEWgi7zawXBVpkMf0O 8KksEEDtXgdgg50LAxwEjW3RZR0wYPIhATOematLg603PB2/013Y8dbyxvmhzW07N0gH PRRnxlWBF3cPJgwn1xRhSX6+kDY/4h8ecWhRUbKrRZAqI7MncSx+ItLjcg5j1LsYMzE2 r07Mq+0glU/4qIQzJvQOGAUIHVI+0jLqGVVzgtTWiQeFlvYQTsZZn2D/xybAlSJ4yZUY VXJ04YOjlMGSonnFhk2513DEH7I5UPSamrGmCtLHSUb3UgYAFyQcD/Z+euqgiOtR1oPZ E51g== MIME-Version: 1.0 X-Received: by 10.152.28.233 with SMTP id e9mr681323lah.3.1425417171832; Tue, 03 Mar 2015 13:12:51 -0800 (PST) Received: by 10.25.17.222 with HTTP; Tue, 3 Mar 2015 13:12:51 -0800 (PST) Date: Tue, 3 Mar 2015 15:12:51 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=089e0158c7cc2f1490051068cc4f Archived-At: Cc: Cullen Jennings Subject: [dispatch] Topics: DISPATCH WG IETF-92 Timeframe X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 21:12:55 -0000 --089e0158c7cc2f1490051068cc4f Content-Type: text/plain; charset=UTF-8 Hi all, The following summarizes the proposed handling of the documents submitted in the pre-IETF-92 timeframe per the deadlines: http://trac.tools.ietf.org/wg/dispatch/trac/wiki We'll shortly update the wiki with this information and submit a detailed agenda. As a reminder to the proponents/authors, the deadline for document submissions is March 9th, 2015 @ 23:59 UTC. Please include -dispatch- in the draftname as that makes it much easier to track as it will then show up in the list for the WG: http://datatracker.ietf.org/wg/dispatch/documents/ Note that continued discussion of these topics on the WG mailing list will allow us to make more progress during the WG session. Regards, Mary and Cullen ====================================================================== The following topics/documents will be allocated agenda time. DISPATCH meets on Monday afternoon from 13:00-15:00. 1) Routing out of dialog requests (Andrew Allen): Document: http://www.ietf.org/id/draft-allen-dispatch-routing-out-of-dialog-request-01.txt 2) GEOJson Charter proposal: https://github.com/geojson/draft-geojson/blob/master/charter.md Document: https://datatracker.ietf.org/doc/draft-butler-geojson/ 3) Calling name identity Trust (CNIT) Charter proposal: http://www.ietf.org/mail-archive/web/cnit/current/msg00178.html 4) VRS purpose for the Call Info header Document: http://www.ietf.org/id/draft-kyzivat-dispatch-trs-call-info-purpose-01.txt The following document is being proposed to be progressed as an individual/AD sponsored document. 5) Cause URI for service number translation Document: http://tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-number-01 The following document is not being allocated agenda time nor is it believed to be ready to progress: 6) Remote Call control and call pick-up with SIP(Anton Tveretin) http://www.ietf.org/internet-drafts/draft-tveretin-dispatch-remote-00.txt --089e0158c7cc2f1490051068cc4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

The following summarizes = the proposed handling of the documents submitted in the pre-IETF-92 timefra= me per the deadlines: =C2=A0 http://trac.tools.ietf.org/wg/dispatch/trac/wiki=C2=A0

We'll shortly update the wiki with this informa= tion and submit a detailed agenda.=C2=A0

As a remi= nder to the proponents/authors, the deadline for document submissions is Ma= rch 9th, 2015 @ 23:59 UTC. =C2=A0 Please include -dispatch- in the draftnam= e as that makes it much easier to track as it will then show up in the list= for the WG:
=

Note that continued discussion of these topics on the W= G mailing list will allow us to make more progress during the WG session.= =C2=A0

Regards,
Mary and Cullen=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

The following topics/documents will be a= llocated agenda time.=C2=A0 DISPATCH meets on Monday afternoon from 13:00-1= 5:00.

1) Routing out of dialog requests (= Andrew Allen):

=C2=A0 =C2=A0 Document: =C2=A0http:/= /www.ietf.org/id/draft-allen-dispatch-routing-out-of-dialog-request-01.txt<= /a>

2) GEOJson

=C2=A0 =C2=A0 Charter proposal: =C2=A0https://github.= com/geojson/draft-geojson/blob/master/charter.md

=C2=A0 =C2=A0 Do= cument: =C2=A0https://datatracker.ietf.org/doc/draft-butler-geojson/

3) C= alling name identity Trust (CNIT)

=C2=A0 =C2=A0 Charter proposal:=C2=A0 http://www.ietf= .org/mail-archive/web/cnit/current/msg00178.html

4) VRS purpose for the Call Info header

=C2=A0 =C2=A0 Document= :=C2=A0http://www.ietf.org/id/draft-kyzivat-d= ispatch-trs-call-info-purpose-01.txt


The following doc= ument is being proposed to be progressed as an individual/AD sponsored docu= ment.=C2=A0

5)=C2=A0 Cause URI for service number translation

=

=C2=A0 =C2=A0 =C2=A0Document:=C2=A0http:= //tools.ietf.org/html/draft-mohali-dispatch-cause-for-service-number-01=


The following document is not being allocated agenda time= nor is it believed to be ready to progress:

=

6) Remote Call con= trol and call pick-up with SIP(Anton=C2=A0Tveretin)

=C2=A0 =C2=A0 =C2= =A0http://www.ietf.org/internet-drafts/draft-t= veretin-dispatch-remote-00.txt

<= /div> --089e0158c7cc2f1490051068cc4f-- From nobody Tue Mar 3 22:59:31 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8433F1A038E for ; Tue, 3 Mar 2015 22:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOXmugp6W-wG for ; Tue, 3 Mar 2015 22:59:28 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38FF1A016C for ; Tue, 3 Mar 2015 22:59:26 -0800 (PST) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail41.telekom.de with ESMTP; 04 Mar 2015 07:59:24 +0100 X-IronPort-AV: E=Sophos;i="5.09,686,1418079600"; d="scan'208";a="628664914" Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 04 Mar 2015 07:59:24 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Wed, 4 Mar 2015 07:59:24 +0100 From: To: Date: Wed, 4 Mar 2015 07:59:23 +0100 Thread-Topic: New Version Notification for draft-jesske-dispatch-forking-answer-correlation-03.txt Thread-Index: AdBVoUlWmx3gUPWmSD+lgLnqU4lI4AApe/oQ Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E83E7BE660@HE113667.emea1.cds.t-internal.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [dispatch] WG: New Version Notification for draft-jesske-dispatch-forking-answer-correlation-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 06:59:30 -0000 RGVhciBhbGwsDQphIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5n LWFuc3dlci1jb3JyZWxhdGlvbiBpcyBub3cgYXZhaWxhYmxlLg0KDQpUaGlzIGlzc3VlIHdhcyBk aXNjdXNzZWQgYXQgdGhlIGxhc3QgSUVURiBtZWV0aW5nIGFuZCBJIHdhcyBhc2tlZCBmb3IgbW9y ZSByZWFzb25pbmcgYW5kIGNvbnNpZGVyYXRpb24gb2YgdGhlIGV4aXN0aW5nIHByb2NlZHVyZXMg aW4gUkZDJ3MuIEkgaGF2ZSB0b3RhbGx5IHJld29ya2VkIHRoZSBkcmFmdCB3aXRoIGEgZGV0YWls ZWQgZGVzY3JpcHRpb24gb2YgdGhlIHByb2JsZW0gc3RhdGVtZW50LiBBZGRlZCBtb3JlIGRldGFp bCBpbiB0aGUgY29uc2lkZXJhdGlvbiBvZiB0aGUgZXhpc3RpbmcgUkZDJ3MgYW5kIHRoZSByZWdh cmRpbmcgZGVzY3JpcHRpb24gb2YgZm9ya2luZyAgcmVsZXZhbnQgcHJvY2VkdXJlcyhtdWx0aXBs ZXMgZWFybHkgcmVzcG9uc2VzL2RpYWxvZ3Mvc2Vzc2lvbnMpLg0KQWxzbyA3IFVzZSBDYXNlcyBv biBGb3JraW5nIGluY2x1ZGluZyBjYWxsIGZvcndhcmRpbmcgYXJlIHNob3duIGFuZCB0aGVpciBj b3JyZWxhdGlvbi9tdWx0aXBsZXhpbmcgb2YgZWFybHkgZGlhbG9ncyBhcmUgZGVzY3JpYmVkLg0K DQpXaXRoIGluY3JlYXNpbmcgcmVhbCBsaWZlIHNlcnZpY2VzIGFuZCBpbnRlcmNvbm5lY3Rpb24g d2Ugc2VlIHRoZSBuZWVkIGZvciBzdWNoIGNvcnJlbGF0aW9uL211bHRpcGxleGluZyBmdW5jdGlv bmFsaXR5IGluIGEgQjJCVUEuDQoNCkNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpUaGFuayB5b3Ug YW5kIEJlc3QgUmVnYXJkcw0KDQpSb2xhbmQNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmlj aHQtLS0tLQ0KVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddIA0KR2VzZW5kZXQ6IERpZW5zdGFnLCAzLiBNw6RyeiAyMDE1IDEyOjAx DQpBbjogSmVzc2tlLCBSb2xhbmQ7IEplc3NrZSwgUm9sYW5kDQpCZXRyZWZmOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5nLWFuc3dlci1j b3JyZWxhdGlvbi0wMy50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtamVzc2tl LWRpc3BhdGNoLWZvcmtpbmctYW5zd2VyLWNvcnJlbGF0aW9uLTAzLnR4dA0KaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2xhbmQgSmVzc2tlIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5nLWFu c3dlci1jb3JyZWxhdGlvbg0KUmV2aXNpb246CTAzDQpUaXRsZToJCUNvcnJlbGF0aW9uIG9mIG11 bHRpcGxlIHJlc3BvbnNlcyBvZiBmb3JrZWQgSU5WSVRFUyBpbiBCYWNrIHRvIEJhY2sgVXNlciBB Z2VudHMNCkRvY3VtZW50IGRhdGU6CTIwMTUtMDMtMDMNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTMwDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtamVzc2tlLWRpc3BhdGNoLWZvcmtpbmctYW5zd2VyLWNvcnJl bGF0aW9uLTAzLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWplc3NrZS1kaXNwYXRjaC1mb3JraW5nLWFuc3dlci1jb3JyZWxhdGlvbi8N Ckh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qZXNza2Ut ZGlzcGF0Y2gtZm9ya2luZy1hbnN3ZXItY29ycmVsYXRpb24tMDMNCkRpZmY6ICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qZXNza2UtZGlzcGF0Y2gtZm9y a2luZy1hbnN3ZXItY29ycmVsYXRpb24tMDMNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50 IGRlc2NyaWJlIHRoZSBzY2VuYXJpb3Mgd2hlcmUgbXVsdGlwbGVzIGVhcmx5IGRpYWxvZ3MNCiAg IGNhbiBiZSBjcmVhdGVkLiAgVGhlIG1haW4gdXNlIGNhc2UgaXMgYmFzZWQgb24gZm9ya2luZy4g IEJ1dCBhbHNvDQogICBmb3J3YXJkaW5nIG9mIFNJUCBJbnZpdGVzIGFuZCBvdGhlciBhcHBsaWNh dGlvbnMgbWF5IGNyZWF0ZSBlYXJseQ0KICAgZGlhbG9ncy4gIFRoZSBzY2VuYXJpb3Mgc2hvd24g ZGVzY3JpYmUgaG93IGEgY29ycmVsYXRpb24vbXVsdGlwbGV4aW5nDQogICBvZiBtdWx0aXBsZSBl YXJseSBkaWFsb2dzIGNhdXNlZCBieSBmb3JrZWQgb3IgZm9yd2FyZGVkIElOVklURXMgaW4NCiAg IEJhY2sgdG8gQmFjayBVc2VyIEFnZW50cyBjYW4gYXBwbHkuICBFeGlzdGluZyBSRkMncyBhcmUg YW5hbHl6ZWQgaG93DQogICBmb3JraW5nIGlzIGRlc2NyaWJlZCBhbmQgcG9pbnRzIHRvIGZhY3Rz IHdoaWNoIG1heSBiZSB0YWtlbiBpbiB0bw0KICAgY29uc2lkZXJhdGlvbi4NCg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Mar 4 13:31:05 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125F31A1BDE; Wed, 4 Mar 2015 13:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.299 X-Spam-Level: X-Spam-Status: No, score=-99.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPYk6DF-gC8E; Wed, 4 Mar 2015 13:31:01 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (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 D0AB41A1ABF; Wed, 4 Mar 2015 13:31:00 -0800 (PST) Received: by labmn12 with SMTP id mn12so11277486lab.2; Wed, 04 Mar 2015 13:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+VNF/mTVoB0RsnIdDEyXaByTKaOr2NXdwo3Prf7sEkE=; b=cTb6sGJ70O724w6fCSpxMegmTLyd5GAGhkkKqX41V0Hotrh4XMNr11MYhGQYYJ4/pV 72E8rB/2ylUQhqfeKOF1foXLd4u+95Q3PNoYSei+DWZug9REZSx7F2AavZ5oxZRPV2km HlvmYGUp1+PuLBmtw8Rvw8Y/e1Naqq7MIpS7jcBfhrQBaE+WixtFUh7Yewe251l3MSos wVNBVVeKlZxPw9CHEHgM8YncpC6YRiamOAZA61TVBM5nsqNM1MDxdpOZSG29pM6nSJ0P RG+P3CFiEJ9Y7VdEhtN9TD4FstK8Jb/ro3khdQFh6uwoNkGrBs4ZUI9sVksVZwwKdVAw kgvw== MIME-Version: 1.0 X-Received: by 10.112.8.68 with SMTP id p4mr5080341lba.37.1425504659262; Wed, 04 Mar 2015 13:30:59 -0800 (PST) Received: by 10.25.17.222 with HTTP; Wed, 4 Mar 2015 13:30:59 -0800 (PST) In-Reply-To: <54f7745d.c53cec0a.266a.ffffc20aSMTPIN_ADDED_BROKEN@mx.google.com> References: <54f7745d.c53cec0a.266a.ffffc20aSMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 4 Mar 2015 15:30:59 -0600 Message-ID: From: Mary Barnes To: DISPATCH , SIPCORE Content-Type: multipart/alternative; boundary=001a1135e3d2d7550505107d2acb Archived-At: Subject: [dispatch] Fwd: [SIPForum-techwg] Submit Your SIPNOC 2015 Speaking Proposal Today! X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 21:31:04 -0000 --001a1135e3d2d7550505107d2acb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I thought this might be of interest to folks in these WGs. If you've not been to SIPNOC, this might be a good opportunity to submit a proposal and/or attend and hear what the folks that deploy SIP networks are dealing with. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Wed, Mar 4, 2015 at 3:06 PM Subject: [SIPForum-techwg] Submit Your SIPNOC 2015 Speaking Proposal Today! To: techwg@sipforum.org SIP Forum TechWG Members: There=E2=80=99s still time to submit your proposal for SIPNOC 2015 workshop= s, panels, speaker presentations and =E2=80=9CBirds of a Feather=E2=80=9D sess= ions addressing the deployment of SIP in service provider environments. To view the official call for presentations, which includes instructions on submitting material and specific SIPNOC policies, please visit www.sipforum.org/content/view/374/275/. To submit, visit https://www.easychair.org/conferences/?conf=3Dsipnoc2015. Topics can include SIP peering, SIP trunking, Emergency Services, Congestion Control, Scaling and Capacity Issues, SIP-based applications, Routing, Security, SIP-Network Operations Center Best Practices, IPv6 deployment challenges, User-agent Configuration, Standardization Issues and Progress, HD voice deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deployment, Testing or other issues facing SIP network operations. SIPNOC 2015 offers several different types of speaking opportunities including: - General Session Talks: A General Session presentation should be on a topic of interest to the general SIPNOC audience, and may be up to 30 minutes long (including time for Q&A). - General Session Panel Discussions: Panels are sessions with a moderator and a team of experts. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will= be organized. Panel selection is based on the importance, originality, focu= s and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. - Special Workshops: These are workshops that run for 1-2 hours, providing time to focus in-depth on a variety of issues important to the SIPNOC community. Topics can include a review of SIP RFCs and standards development, the regulatory environment, etc. - Research Topics: Researchers are invited to present short summaries of their work for operator feedback. Topics may include call routing, netwo= rk performance, statistical measurement and analysis and protocol developme= nt and implementation. Studies presented may be works in progress. Research= ers from academia, government, and industry are encouraged to present. - BOFs: BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the SIPNOC community. BOFs = may be held in break=E2=80=90out areas or in an unscheduled room. Requests f= or scheduled BOFs can be made at any time, including on site at the confere= nce. ------------------------------ *SIPNOC 2015 General Info* The SIPNOC 2015 event website is located at www.sipnoc.org. Registration for SIPNOC 2015 is officially open! Special pricing for SIPNOC 2015 is now in effect! Take advantage of special early-bird pricing now through March 15, 2015. The regular SIPNOC 2015 conference registration fee is $995, but for a limited time regular attendees can save $100 and pay only $895 for three days of conference proceedings. This fee includes a special SIP Training Day the first day of the event on June 23, a Welcome Reception that evening with food and drink; breakfast, lunch and break refreshments and snacks during the conference; and a special dinner =E2=80=9CBeer and Gear=E2=80=9D networking reception t= he second night of the event. *Individuals from SIP Forum Full Member companies save even more ($245 off the regular price to be exact with special early-bird pricing)! Please contact Marc Robins, SIP Forum President and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full Member discount code.* Register today at http://www.regonline.com/sipnoc2015. ------------------------------ *SIPNOC 2015 Sponsorship Information* There are still a number of great sponsorship opportunities remaining. For information about corporate sponsorship opportunities at SIPNOC 2015, please contact Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 or marc.robins@sipforum.org. ------------------------------ All best, Marc ************************* Marc Robins President and Managing Director SIP Forum http://www.sipforum.org Mobile: 203-829-6307 SkypeMe! marcrobins ************************* _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --001a1135e3d2d7550505107d2acb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I thought this might be of interest to folks in these WGs.= =C2=A0 If you've not been to SIPNOC, this might be a good opportunity t= o submit a proposal and/or attend and hear what the folks that deploy SIP n= etworks are dealing with.=C2=A0

Regards,
Mary.= =C2=A0

---------- Forwarded messag= e ----------
From: Marc Robins <marc.robins@sipf= orum.org>
Date: Wed, Mar 4, 2015 at 3:06 PM
Subject: [S= IPForum-techwg] Submit Your SIPNOC 2015 Speaking Proposal Today!
To: techwg@sipforum.org


SIP Forum TechWG Members= :

There=E2=80=99s still time to submit your proposal for SIPNOC 2015 workshops, panels, sp= eaker presentations and =E2=80=9CBirds of a Feather=E2=80=9D sessions addre= ssing the deployment of SIP in service provider environments.=

To view the official call for presentations, which includes instr= uctions on submitting material and specific SIPNOC policies, please visit <= a href=3D"http://www.sipforum.org/content/view/374/275/" target=3D"_blank">= www.sipforum.org/content/view/374/275/. To submit, visit ht= tps://www.easychair.org/conferences/?conf=3Dsipnoc2015.

Topics can include SIP peering, SIP trunking, Emergency Services, C= ongestion Control, Scaling and Capacity Issues, SIP-based applications, Rou= ting, Security, SIP-Network Operations Center Best Practices, IPv6 deployme= nt challenges, User-agent Configuration, Standardization Issues and Progres= s, HD voice deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 = Deployment, Testing or other issues facing SIP network operations. <= u>

SIPNOC 2015 offers several different types of speaking oppo= rtunities including:

  • General Session Talks: A Gener= al Session presentation should be on a topic of interest to the general SIP= NOC audience, and may be up to 30 minutes long (including time for Q&A)= .
  • General Session Panel Discussions: Panels are sessions with a mod= erator and a team of experts. The panel moderator should submit an abstract= on the panel topic, a list of panelists, and how the panel will be organiz= ed. Panel selection is based on the importance, originality, focus and time= liness of the topic, expertise of proposed panelists, as well as the potent= ial for informative and controversial discussion.
    • =
  • Special Workshops:= These are workshops that run for 1-2 hours, providing time to focus in-dep= th on a variety of issues important to the SIPNOC community. Topics can inc= lude a review of SIP RFCs and standards development, the regulatory environ= ment, etc.
  • Research Topics: Researchers are invited to present short= summaries of their work for operator feedback. Topics may include call rou= ting, network performance, statistical measurement and analysis and protoco= l development and implementation. Studies presented may be works in progres= s. Researchers from academia, government, and industry are encouraged to pr= esent.
  • BOFs: BOFs (Birds of a Feather sessions) are informal session= s on topics which are of interest to a portion of the SIPNOC community. BOF= s may be held in break=E2=80=90out areas or in an unscheduled room. Request= s for scheduled BOFs can be made at any time, including on site at the conf= erence.

SIPNOC 2015 General Info<= /span>

The SIPNOC 2015 event website is located at www.sipnoc.org.<= /p>

Registration for SIPNOC 2015 is officially open!

=

S= pecial pricing for SIPNOC 2015 is now in effect! Take advantage of special = early-bird pricing now through March 15, 2015. The regular SIPNOC 2015 conf= erence registration fee is $995, but for a limited time regular attendees c= an save $100 and pay only $895 for three days of conference proceedings. Th= is fee includes a special SIP Training Day the first day of the event on Ju= ne 23, a Welcome Reception that evening with food and drink; breakfast, lun= ch and break refreshments and snacks during the conference; and a special d= inner =E2=80=9CBeer and Gear=E2=80=9D networking reception the second night= of the event.

Individuals from SIP = Forum Full Member companies save even more ($245 off the regular price to b= e exact with special early-bird pricing)! Please contact Marc Robins, SIP F= orum President and Managing Director, at marc.robins@sipforum.org to obtain the excl= usive Full Member discount code.

Register today = at http:/= /www.regonline.com/sipnoc2015.=C2=A0

SIPNOC 2015 Sponsorship Information

There a= re still a number of great sponsorship opportunities remaining. For informa= tion about corporate sponsorship opportunities at SIPNOC 2015, please conta= ct Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 o= r marc.robins= @sipforum.org.

=C2=A0

=C2=A0

All best,

= =C2=A0

Marc

=C2=A0<= /p>

*******************= ******

Marc Robins

President and Managing Director=

SIP Forum

http://www.sipforum.org

Mobile: 203-829-6307

SkypeMe! marcrobins

=C2=A0=

******************= *******

=C2=A0=


_______________________________________________
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at:=C2=A0 http://sipforum.org/mailman/listinfo/t= echwg


--001a1135e3d2d7550505107d2acb-- From nobody Wed Mar 4 16:21:39 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B461A01F0 for ; Wed, 4 Mar 2015 16:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.678 X-Spam-Level: X-Spam-Status: No, score=0.678 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIeX2LVtQo0l for ; Wed, 4 Mar 2015 16:21:35 -0800 (PST) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA7A1A01D6 for ; Wed, 4 Mar 2015 16:21:34 -0800 (PST) Received: from userPC (unknown [122.167.227.42]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 2A10F868E87; Thu, 5 Mar 2015 00:21:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1425514893; bh=NKXZQ3W5Fxlg1m1GjeLrtTOXJt3WI+EXRSJ5h7WtYtQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Aik5HL1QHrVIOiSalmDCL1KQ+xMS/oDjl5l5e37QUu2iTHWq9GsO13zPU17Zmi0ZN 7RRuI12e8Z4Jc8zSVBthhfNHgTCDypzBxxSmoquo5rjn+Xcz73VFRd3ql58wFXcF8U AHc2XwWpX3ADtgZJOp6jKqBA6YIQ7jlXTW0riXUo= From: "Parthasarathi R" To: , References: <787AE7BB302AE849A7480A190F8B93300491577E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <023901d052df$6056f2c0$2104d840$@co.in> <787AE7BB302AE849A7480A190F8B9330049185EA@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049185EA@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Thu, 5 Mar 2015 05:51:24 +0530 Message-ID: <01c401d056da$537bdcb0$fa739610$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C5_01D05708.6D3418B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBRpv5w7XTmu/weRVKc3+vCrIJ62gBNLj+AAIpjqiAAdNLnYA== Content-Language: en-us X-CTCH-RefID: str=0001.0A020205.54F7A18D.0089, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: Subject: Re: [dispatch] PCP for SIP Deployments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 00:21:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C5_01D05708.6D3418B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 Thanks for incorporating the comments.=20 =20 ICE is used in the context of SIP over WebSocket (RFC 7118) & WebRTC SDP profile within managed networks. TURN has its own limitation in = traversing NAT/FW using UDP transport in case of managed networks. PCP server in = NAT &FW resolves these issues. Of course, the current implementations = (WebRTC devices) have challenges in using ICE + PCP but IMO, it is good have for future works. =20 Thanks Partha =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Monday, March 02, 2015 9:56 PM To: Parthasarathi R; dispatch@ietf.org Subject: RE: [dispatch] PCP for SIP Deployments =20 Hi Partha, =20 Many thanks for the review and the comments.=20 =20 I integrated almost all your suggestion, except the one about the ICE discussion. The reason for that is ICE is not deployed in the managed context; as such I=92m afraid there is no value in having such = discussion in the I-D.=20 =20 Please check the diff and let me know if you have further comments.=20 =20 URL: = http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-ipv6-04.txt Status: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6/ Htmlized: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-ipv6-04 =20 Thank you. =20 Cheers, Med =20 =20 De : Parthasarathi R [mailto:partha@parthasarathi.co.in]=20 Envoy=E9 : vendredi 27 f=E9vrier 2015 23:47 =C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org Objet : RE: [dispatch] PCP for SIP Deployments =20 Hi Med, =20 It is a interesting draft. The current writing provides PCP advantages = in SIP managed network and particularly cellular. The following information = has to be added to provide more clarity about this work: =20 1) Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP = client, PCP server 2) Basic callflow to show how the dialog is established in case P2P = is used 3) The draft title mentions IPv6. My understanding is that this = shall be used for IPv4 network as well. 4) Add more details about how SIP, PCP, ICE interworking happens as = the current reference is related to PCP with rtcweb only. 5) Security implication w.r.t SIP usage of PCP has to be mentioned. 6) Advantage of using PCP over TURN in SIP network shall be = provided in the introduction section for better comparison. =20 Regards Partha =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Thursday, February 26, 2015 3:02 PM To: dispatch@ietf.org Subject: [dispatch] PCP for SIP Deployments =20 Hi all, =20 I would like to share with this group a short document that explains how = PCP can be of great use in the context SIP-based services: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03=20 =20 As indicated in the I-D, the main benefits include (but not limited to): = =20 o Avoid embedding an ALG in the middleboxes. Note, ALGs are not recommended since the evolution of the service would depend on the ALG maintenance. o Not require any Hosted NAT Traversal function (e.g., [ RFC7362]) to be embedded in the SIP server. Intermediate NATs and firewalls are transparent to the SIP service platform. o Avoid overloading the network with keepalive message to maintain the mapping in intermediate middleboxes. o Work without requiring symmetric RTP/RTCP [ RFC4961]. o Not require symmetric SIP to work (i.e., rport [ RFC3581]). o Easily support unidirectional sessions. =20 When this document was first presented in the PCP WG, I was suggested = that it is better to publish it in RAI with a review from the PCP WG. Hence, = this message to the list.=20 =20 Cheers, Med ------=_NextPart_000_01C5_01D05708.6D3418B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Med,

 

Thanks for = incorporating the comments.

 

ICE is used in the = context of SIP over WebSocket (RFC 7118) & WebRTC SDP profile within managed = networks. TURN has its own limitation in traversing NAT/FW using UDP transport in case = of managed networks. PCP server in NAT &FW resolves these issues. Of = course, the current implementations (WebRTC devices) have challenges in using = ICE + PCP but IMO, it is good have for future works.

 

Thanks

Partha

 

From:= = mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, March 02, 2015 9:56 PM
To: Parthasarathi R; dispatch@ietf.org
Subject: RE: [dispatch] PCP for SIP = Deployments

 

Hi Partha,

 

Many thanks for the review and the comments. =

 

I integrated almost all your suggestion, except the one = about the ICE discussion. The reason for that is ICE is not deployed in the = managed context; as such I’m afraid there is no value in having such = discussion in the I-D.

 

Please check the diff and let me know if you have further comments.

 

URL:        =     http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-= ipv6-04.txt

Status:       &nb= sp; <= span lang=3DEN-US>https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv= 6/

Htmlized:       = http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-04

Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-i= pv6-04

 

Thank you.

 

Cheers,

Med

 

 

De : = Parthasarathi R [mailto:partha@parthasarathi.co.in]
Envoy=E9 : vendredi 27 f=E9vrier 2015 23:47
=C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org
Objet : RE: [dispatch] PCP for SIP = Deployments

 

Hi = Med,

 

It is a interesting = draft. The current writing provides PCP advantages in SIP managed network and = particularly cellular. The following information has to be added to provide more = clarity about this work:

 

1)      Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP client, PCP = server

2)      Basic = callflow to show how the dialog is established in case P2P is = used

3)      The draft = title mentions IPv6. My understanding is that this shall be used for IPv4 = network as well.

4)      Add more = details about how SIP, PCP, ICE interworking happens as the current reference is related to PCP with rtcweb only.

5)      Security = implication w.r.t SIP usage of PCP has to be mentioned.

6)      Advantage = of using PCP over TURN in SIP network shall be provided in the introduction = section for better comparison.

 

Regards

Partha

 

From:= dispatch = [mailto:dispatch-bounces@ietf.or= g] On Behalf Of mohamed.boucadair@orange.com=
Sent: Thursday, February 26, 2015 3:02 PM
To: dispatch@ietf.org
Subject: [dispatch] PCP for SIP Deployments

 

Hi all,

 

I would like to share with this group a short document that explains how = PCP can be of great use in the context SIP-based services:

http:= //tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03

 

As indicated in the I-D, the main benefits include (but not limited to): =

 

   o  Avoid embedding an ALG in the =
middleboxes.  Note, ALGs are not
      recommended since the evolution of =
the service would depend on the
      ALG =
maintenance.
   =
o  Not require any Hosted NAT Traversal function (e.g., =
[RFC7362]) to
      be embedded in =
the SIP server.  Intermediate NATs and =
firewalls
      are transparent to the SIP service =
platform.
   =
o  Avoid overloading the network with keepalive message to =
maintain
      the mapping in intermediate =
middleboxes.
   =
o  Work without requiring symmetric RTP/RTCP [RFC4961].
   o  Not require symmetric =
SIP to work (i.e., rport [RFC3581]).
   o  Easily support =
unidirectional sessions.

 

When this document was first presented in the PCP WG, I was suggested that it = is better to publish it in RAI with a review from the PCP WG. Hence, this = message to the list.

 

Cheers,

Med

------=_NextPart_000_01C5_01D05708.6D3418B0-- From nobody Thu Mar 5 02:18:15 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A7E1A8748 for ; Thu, 5 Mar 2015 02:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjvHB0CwWI7H for ; Thu, 5 Mar 2015 02:18:09 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730A61A1A9C for ; Thu, 5 Mar 2015 02:18:08 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 691C11B80AB; Thu, 5 Mar 2015 11:18:06 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 3F677C8179; Thu, 5 Mar 2015 11:18:06 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.181]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Thu, 5 Mar 2015 11:18:06 +0100 From: To: Parthasarathi R , "dispatch@ietf.org" Thread-Topic: [dispatch] PCP for SIP Deployments Thread-Index: AdBXLaVKHLIA7f4lSRmkPUaU5jCunw== Date: Thu, 5 Mar 2015 10:18:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004924E01@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004924E01OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Subject: Re: [dispatch] PCP for SIP Deployments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 10:18:13 -0000 --_000_787AE7BB302AE849A7480A190F8B933004924E01OPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Partha, Thank you for the feedback. I understand more your comment about ICE. I updated the draft accordingly. Please check the new version and the diff: URL: http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip= -ipv6-05.txt Status: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ip= v6/ Htmlized: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-05 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-= ipv6-05 Thank you. Cheers, Med De : Parthasarathi R [mailto:partha@parthasarathi.co.in] Envoy=E9 : jeudi 5 mars 2015 01:21 =C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org Objet : RE: [dispatch] PCP for SIP Deployments Hi Med, Thanks for incorporating the comments. ICE is used in the context of SIP over WebSocket (RFC 7118) & WebRTC SDP pr= ofile within managed networks. TURN has its own limitation in traversing NA= T/FW using UDP transport in case of managed networks. PCP server in NAT &FW= resolves these issues. Of course, the current implementations (WebRTC devi= ces) have challenges in using ICE + PCP but IMO, it is good have for future= works. Thanks Partha From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, March 02, 2015 9:56 PM To: Parthasarathi R; dispatch@ietf.org Subject: RE: [dispatch] PCP for SIP Deployments Hi Partha, Many thanks for the review and the comments. I integrated almost all your suggestion, except the one about the ICE discu= ssion. The reason for that is ICE is not deployed in the managed context; a= s such I'm afraid there is no value in having such discussion in the I-D. Please check the diff and let me know if you have further comments. URL: http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip= -ipv6-04.txt Status: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ip= v6/ Htmlized: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-= ipv6-04 Thank you. Cheers, Med De : Parthasarathi R [mailto:partha@parthasarathi.co.in] Envoy=E9 : vendredi 27 f=E9vrier 2015 23:47 =C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org Objet : RE: [dispatch] PCP for SIP Deployments Hi Med, It is a interesting draft. The current writing provides PCP advantages in S= IP managed network and particularly cellular. The following information has= to be added to provide more clarity about this work: 1) Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP client, = PCP server 2) Basic callflow to show how the dialog is established in case P2P is= used 3) The draft title mentions IPv6. My understanding is that this shall = be used for IPv4 network as well. 4) Add more details about how SIP, PCP, ICE interworking happens as th= e current reference is related to PCP with rtcweb only. 5) Security implication w.r.t SIP usage of PCP has to be mentioned. 6) Advantage of using PCP over TURN in SIP network shall be provided i= n the introduction section for better comparison. Regards Partha From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of mohamed.bouc= adair@orange.com Sent: Thursday, February 26, 2015 3:02 PM To: dispatch@ietf.org Subject: [dispatch] PCP for SIP Deployments Hi all, I would like to share with this group a short document that explains how PC= P can be of great use in the context SIP-based services: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03 As indicated in the I-D, the main benefits include (but not limited to): o Avoid embedding an ALG in the middleboxes. Note, ALGs are not recommended since the evolution of the service would depend on the ALG maintenance. o Not require any Hosted NAT Traversal function (e.g., [RFC7362]) to be embedded in the SIP server. Intermediate NATs and firewalls are transparent to the SIP service platform. o Avoid overloading the network with keepalive message to maintain the mapping in intermediate middleboxes. o Work without requiring symmetric RTP/RTCP [RFC4961]. o Not require symmetric SIP to work (i.e., rport [RFC3581]). o Easily support unidirectional sessions. When this document was first presented in the PCP WG, I was suggested that = it is better to publish it in RAI with a review from the PCP WG. Hence, thi= s message to the list. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B933004924E01OPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Partha,

 

Thank you for the feedback.

 

I understand more your comment = about ICE. I updated the draft accordingly.

 

Please check the new version an= d the diff:

 

URL:    =         http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-ipv6-05.tx= t

Status:   &nb= sp;     https://datatracker= .ietf.org/doc/draft-boucadair-pcp-sip-ipv6/=

Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-= boucadair-pcp-sip-ipv6-05=

Diff:    = ;       http:= //www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-ipv6-05

 

 

Thank you.

 

Cheers,

Med

 

De : Parthasarathi R [mailto:partha@parthasarathi.co.i= n]
Envoy=E9 : jeudi 5 mars 2015 01:21
=C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org
Objet : RE: [dispatch] PCP for SIP Deployments

 

Hi Med,=

&n= bsp;

Thanks = for incorporating the comments.

&n= bsp;

ICE is = used in the context of SIP over WebSocket (RFC 7118) & WebRTC SDP profi= le within managed networks. TURN has its own limitation in traversing NAT/F= W using UDP transport in case of managed networks. PCP server in NAT &FW resolves these issues. Of course, the current im= plementations (WebRTC devices) have challenges in using ICE + PCP but I= MO, it is good have for future works.

&n= bsp;

Thanks<= o:p>

Partha<= o:p>

&n= bsp;

From: mohamed.boucadair@orange.com [= mailto:mohamed.boucadair@orange.com]
Sent: Monday, March 02, 2015 9:56 PM
To: Parthasarathi R; dispatch@ietf.org
Subject: RE: [dispatch] PCP for SIP Deployments

 

Hi Partha,

 

Many thanks for the review and = the comments.

 

I integrated almost all your su= ggestion, except the one about the ICE discussion. The reason for that is I= CE is not deployed in the managed context; as such I’m afraid there is no value in having such discussion in the I-D. <= o:p>

 

Please check the diff and let m= e know if you have further comments.

 

URL:    =         http://www.ietf.org/internet-drafts/draft-boucadai= r-pcp-sip-ipv6-04.txt

Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ip= v6/

Htmlized:   &= nbsp;   http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-04

Diff:    = ;       http://www.ietf.o= rg/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-ipv6-04

 

Thank you.

 

Cheers,

Med

 

 

De : Parthasarathi R [mailto:partha@parthasarathi= .co.in]
Envoy=E9 : vendredi 27 f=E9vrier 2015 23:47
=C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org
Objet : RE: [dispatch] PCP for SIP Deployments

 

Hi Med,=

&n= bsp;

It is a= interesting draft. The current writing provides PCP advantages in SIP mana= ged network and particularly cellular. The following information has to be = added to provide more clarity about this work:

&n= bsp;

= 1)      Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP client, PCP ser= ver

= 2)      Basic callflow to show how the dialog is established in case P2P is used

= 3)      The draft title mentions IPv6. My understanding is that this shall be used= for IPv4 network as well.

= 4)      Add more details about how SIP, PCP, ICE interworking happens as the curre= nt reference is related to PCP with rtcweb only.

= 5)      Security implication w.r.t SIP usage of PCP has to be mentioned.

= 6)      Advantage of using PCP over TURN in SIP network shall be provided in the i= ntroduction section for better comparison.

&n= bsp;

Regards=

Partha<= o:p>

&n= bsp;

From: dispatch [mailto:dispatch-bounces@ietf.org= ] On Behalf Of = mohamed.boucadair@orange.com
Sent: Thursday, February 26, 2015 3:02 PM
To: dispatch@ietf.org
Subject: [dispatch] PCP for SIP Deployments

 

Hi all,

 

I would like to share with this group a sho= rt document that explains how PCP can be of great use in the context SIP-ba= sed services:

http://tools.ietf.org/html/draft-boucadair-pcp-= sip-ipv6-03

 

As indicated in the I-D, the main benefits = include (but not limited to):

 

   o  Avoid embedding an ALG in the middleboxe=
s.  Note, ALGs are not
      recommended since the evolutio=
n of the service would depend on the
      ALG maintenance.
   o  Not require any Hosted NAT Traversal fun=
ction (e.g., [RFC7362]) to=

      be embedded in the SIP server.=
  Intermediate NATs and firewalls
      are transparent to the SIP ser=
vice platform.
   o  Avoid overloading the network with keepa=
live message to maintain
      the mapping in intermediate mi=
ddleboxes.
   o  Work without requiring symmetric RTP/RTC=
P [RFC4961].
   o  Not require symmetric SIP to work (i.e.,=
 rport [RFC3581]).
   o  Easily support unidirectional sessions.<=
o:p>

 

When this document was first presented in t= he PCP WG, I was suggested that it is better to publish it in RAI with a re= view from the PCP WG. Hence, this message to the list.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B933004924E01OPEXCLILM23corp_-- From nobody Mon Mar 9 10:48:11 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE2B1A8AA7 for ; Mon, 9 Mar 2015 10:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.919 X-Spam-Level: X-Spam-Status: No, score=-112.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAPpXg-yIiqG for ; Mon, 9 Mar 2015 10:48:08 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A307C1A90A9 for ; Mon, 9 Mar 2015 10:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2018; q=dns/txt; s=iport; t=1425923288; x=1427132888; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ht/G9d2HNgonOdJbZuRxTa60aC+trLZZ56O+3CJdEbQ=; b=B51syBlf+Zs5dBhQMxSptST2zMHMGo2zNJJk5XcvztHN+/Qp2LImYxt9 CzMquvQIhWjanXioYEdDnCYwgNdv/cKFtfUwfa7+jtyhs+K7KcmRreCnS uTYIoqaldLe71StAci31dJ7odL4SA3QMnHkRzIOMwDLYLiO2sLTrs+T1P Q=; X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208";a="398980583" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP; 09 Mar 2015 17:48:08 +0000 Received: from [127.0.0.1] (ssh-sjc-2.cisco.com [171.68.46.188]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t29Hm6hG026665; Mon, 9 Mar 2015 17:48:07 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <787AE7BB302AE849A7480A190F8B93300491577E@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Mon, 9 Mar 2015 08:34:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <787AE7BB302AE849A7480A190F8B93300491577E@OPEXCLILM23.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] PCP for SIP Deployments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:48:10 -0000 I read the draft and it seems like one of the issues is that you don't = know if the PCP nat is the only nat or firewall in path. So it seems = like a more robust solutions is to use PCP along with existing = solutions. So for SIP, one does the PCP to get a port but still relies = on things like rport and outbound to correctly set the return address = (IE use the PCP to open a pin whole but still use private address in = contact). Similarly with the RTP use PCP to get a address on the outside = of the NAT but just add that in as one of the ICE candidates.=20 > On Feb 26, 2015, at 2:31 AM, mohamed.boucadair@orange.com wrote: >=20 > Hi all, > =20 > I would like to share with this group a short document that explains = how PCP can be of great use in the context SIP-based services: > http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03 > =20 > As indicated in the I-D, the main benefits include (but not limited = to): > =20 > o Avoid embedding an ALG in the middleboxes. Note, ALGs are not > recommended since the evolution of the service would depend on = the > ALG maintenance. > o Not require any Hosted NAT Traversal function (e.g., [RFC7362]) = to > be embedded in the SIP server. Intermediate NATs and firewalls > are transparent to the SIP service platform. > o Avoid overloading the network with keepalive message to maintain > the mapping in intermediate middleboxes. > o Work without requiring symmetric RTP/RTCP [RFC4961]. > o Not require symmetric SIP to work (i.e., rport [RFC3581]). > o Easily support unidirectional sessions. > =20 > When this document was first presented in the PCP WG, I was suggested = that it is better to publish it in RAI with a review from the PCP WG. = Hence, this message to the list.=20 > =20 > Cheers, > Med > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Mar 9 10:48:27 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080AB1A90B2 for ; Mon, 9 Mar 2015 10:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmp1ZSm3kfLM for ; Mon, 9 Mar 2015 10:48:23 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2851A8AA7 for ; Mon, 9 Mar 2015 10:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3671; q=dns/txt; s=iport; t=1425923303; x=1427132903; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JZk+onv72jPlL2JWhc2fhCEPVu6B8mcWQ7d6cOtBcYQ=; b=fR/u4I5gnqPYd+9DWe9WPz6+so5ZdtumyAYwen8AAgRQE73c0UTyGEZC Sjmqi8IJue8dAH9rQoRKPp+EmgE3XduABRu3+0Xw8MsPu29a84BETIqui UU1g0rHouSnSSihf1zQi37pJN4uufGu7WIdQ2PZfmRX+wc0Bl7mx5r03J s=; X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208";a="130293972" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 09 Mar 2015 17:48:22 +0000 Received: from [127.0.0.1] (ssh-sjc-2.cisco.com [171.68.46.188]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t29Hm6hH026665; Mon, 9 Mar 2015 17:48:22 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <54B54462.8060308@alum.mit.edu> Date: Mon, 9 Mar 2015 08:58:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6F2A17BA-AE0D-4370-A613-9E28B052AF16@cisco.com> References: <20150113154647.9128.69519.idtracker@ietfa.amsl.com> <54B54462.8060308@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:48:26 -0000 The heart of this draft gives me, ah , heartburn. The issue is=20 For a provider to receive reimbursement for providing relay service on a call the FCC requires that the provider supply call detail including the IP address of the device the TRS user is using for the call.=20 First of all what IP. The IP of their phone behind their linksys nat? = the public IP of the TURN server? the VPN? None of these are a viable = way to authenticate that the user should receive this services and the = IETF should implicitly endorse that they are. Furthermore the IETF = should be just as concerned about privacy for people using a VRS as = people that do not need one and this sort of reveal my IP address even = if I want location privacy is not great.=20 Given the lack of any security around this and the TRS-5 requirement, I = wonder if one can just look at the via list and use that? If we do proceed with this, I don't think the call-info is the = appropriate place to put it. I think a new header would be the right = thing. Can you provide a pointer to the actually FCC rules for this? If the goal is purely to check the user is in the US, then having the = VRS check that they were sending media to an IP address inside the US = seems like it would be a better solution.=20 Thanks > On Jan 13, 2015, at 9:14 AM, Paul Kyzivat = wrote: >=20 > Dispatchers: >=20 > I have just submitted a new draft (see below) that needs to be = dispatched. It defines a new Call-Info 'purpose' parameter value. >=20 > The intended audience for this draft is quite limited - to the = providers of the Video Relay Service in the US, and to the FCC that = sponsors that service. The Intro section explains this. >=20 > I'm hoping this can be dispatched without causing a lot of bother for = anybody. I don't anticipate that it needs time in Dallas. IIUC documents = of this sort are often AD sponsored. >=20 > Thanks, > Paul >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-kyzivat-dispatch-trs-call-info-purpose-00.txt > Date: Tue, 13 Jan 2015 07:46:47 -0800 > From: internet-drafts@ietf.org > To: Paul Kyzivat , "Paul Kyzivat" = >=20 >=20 > A new version of I-D, = draft-kyzivat-dispatch-trs-call-info-purpose-00.txt > has been successfully submitted by Paul Kyzivat and posted to the > IETF repository. >=20 > Name: draft-kyzivat-dispatch-trs-call-info-purpose > Revision: 00 > Title: Telecommunications Relay Service Purpose for the = Call-Info Header Field in the Session Initiation Protocol (SIP) > Document date: 2015-01-13 > Group: Individual Submission > Pages: 4 > URL: = http://www.ietf.org/internet-drafts/draft-kyzivat-dispatch-trs-call-info-p= urpose-00.txt > Status: = https://datatracker.ietf.org/doc/draft-kyzivat-dispatch-trs-call-info-purp= ose/ > Htmlized: = http://tools.ietf.org/html/draft-kyzivat-dispatch-trs-call-info-purpose-00= >=20 >=20 > Abstract: > This document defines and registers a value of "original-identity" > for the "purpose" header field parameter of the Call-Info header > field in the Session Initiation Protocol (SIP). >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From nobody Mon Mar 9 10:48:41 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D341A90EA; Mon, 9 Mar 2015 10:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.811 X-Spam-Level: X-Spam-Status: No, score=-111.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ow2A9RI7c1x; Mon, 9 Mar 2015 10:48:26 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938301A90AD; Mon, 9 Mar 2015 10:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12203; q=dns/txt; s=iport; t=1425923304; x=1427132904; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=xCcSaWpeNQ2SL7a28mDM+vXYLXDrRJZvM2CM/MFEex0=; b=EVOS9o8aWX2r/DieMjowPe3fynuWjEwYb+blbGCUVX5Cr50Zyf68Z2/p 7sQc1nMIz4Pt/J75E/EsF/RokgbHzm7XHSJTmt7N85Lj1V/E77n2uf4/e uzWHNZgzDSjnBPGB1c3OJqkZi0cpMYJv8YGq8bXcVVE0fT4iTjFeC2KF8 8=; X-IronPort-AV: E=Sophos;i="5.11,368,1422921600"; d="scan'208";a="130242223" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP; 09 Mar 2015 17:48:23 +0000 Received: from [127.0.0.1] (ssh-sjc-2.cisco.com [171.68.46.188]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t29Hm6hI026665; Mon, 9 Mar 2015 17:48:22 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Cullen Jennings In-Reply-To: Date: Mon, 9 Mar 2015 09:10:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> References: To: cnit@ietf.org, "dispatch@ietf.org" , "modern@ietf.org" X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 17:48:29 -0000 On the particular CNAM like topic ... I'm not keen on moving forward with something like this unless we can = show the trust and human factors issues is an engineering problem not a = research problem. We have seen the difficulty with human readable names = in SPAM. Particularly when using UTF-8, how do we stop bad actor getting = names that look the same as someone they wish to impersonate? Who will = validate the names and issue some sort of trust token that says I can = use "Cullen Jennings" or whatever. Who else can use that name and what = about names visually similar to it.=20 On the flip side we are seeing most smart phones take the incoming phone = number, and look it up the personal address book of the user and display = the name that the user of the smartphone assigned. We are seeing = enterprise phones that do a similar things using the users social = networks as well as personal address book.=20 What would be bad is phone display a display name that some how claimed = to be trustable but was not. That would be worse that the current = situation. Perhaps people have a good way to solve this in mind but I'm = not seeing that that is.=20 Cullen (with my individual contribute hat on of course) > On Feb 25, 2015, at 10:05 AM, Richard Shockey = wrote: >=20 >=20 > Thanks Martin .. This is my very raw first cut at a charter. Its = hopefully simple and straight forward. >=20 > Send me any edits etc. >=20 > ***** >=20 > CNIT Charter [Calling Name Identity Trust] >=20 > WG Chairs TBD: >=20 > Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters = of information associated with a specific E.164 calling party number in = the Public Switched Telephone Network [PSTN]. In the PSTN this data is = sent by the originating network only at the specific request of the = terminating network via a SS7 Transaction Application Part [TCAP] = response message. In the Session Initiation Protocol [SIP] this = information can be inserted into the FROM: part of the originating = INVITE message or by other means. >=20 > As with the originating source telephone number, this data can be = altered in transit creating a variety of malicious abuses similar to the = ones identified by the IETF STIR working group. >=20 > The purpose of the CNIT working group will be to define a data = structure, a new SIP header or repurpose an existing SIP header to carry = an advanced form of CNAM as well as information from a STIR Validation = Authority. The purpose of this work is to present to the SIP called = party trusted information from the calling party in order that the = called party make a more reasoned and informed judgment on whether to = accept the INVITE or not. >=20 > The working group will not invalidate any existing SIP mechanism for = anonymous calling. =20 >=20 > The working group will, to the best of its ability, reuse existing = IETF protocols. >=20 > Full Internationalization of the Calling Name Identity Trust data = object(s) is a requirement. >=20 > The working group will closely work with the IETF STIR working group >=20 > The working group will immediately liaison with 3GPP SA-1 in order to = coordinate efforts. >=20 > The working group will coordinate with National Numbering Authorities = and National Regulatory Authorities as needed. >=20 > The working group will deliver the flowing. >=20 > =95 A problem statement and requirements detailing the current = deployment environment and situations that motivate work on Calling Name = Identity Trust. > =95 Define either a new SIP header or document a repurpose of an SIP = existing header for Calling Name Identify Trust data > =95 Define a data model for the Calling Name Identity Trust object = (s) which may include various forms of multimedia data > =95 Deliver an analysis of privacy implications of the proposed = Calling Name Identity Trust mechanism. >=20 >=20 > Milestones: >=20 >=20 > =97=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 > From: "DOLLY, MARTIN C" > Date: Tuesday, February 24, 2015 at 9:02 PM > To: Richard Shockey > Cc: "Holmes, David W [CTO]" , = "dispatch@ietf.org" , "modern@ietf.org" = , "Peterson, Jon" > Subject: Re: [Modern] [dispatch] draft charter >=20 > I support Richard on this=20 >=20 > Martin Dolly > Lead Member of Technical Staff > Core & Gov't/Regulatory Standards > AT&T Standards and=20 > Industry Alliances > +1-609-903-3390 > Sent from my iPhone >=20 > On Feb 24, 2015, at 6:36 PM, Richard Shockey = wrote: >=20 >>=20 >> Excellent points David. =20 >>=20 >> My concern here is charter overreach. I really want to keep = CNAM+/CNIT out of this. IMHO that is a very separate and highly focused = effort to define both the modification of the SIP headers necessary to = support some enhanced calling party identification and a very limited = effort to define the object and or the STIR validation data. =20 >>=20 >> I=92m violently opposed to =93end world hunger=94 WG=92s.=20 >>=20 >> If registries can be used fine but I certainly want to see how this = can be accomplished in bi lateral agreements between consenting service = providers and work with CUA vendors on how the data is displayed aka = Apple, Samsung, Microsoft in the context of a formal liaison with 3GPP. = Certainly the relevance of CNAM+/CNIT in enterprise and residential = access markets is important but we all know =93Money is the answer what = is the question ..=94 =20 >>=20 >> I=92ve asked for time in Dispatch to look at the CNAM/CNIT issue and = report on the JTF on NNI. As you well know we have made considerable = progress. >>=20 >> Last week I gave a talk on this to a panel that included many of our = friends among the national regulators. =20 >>=20 >> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>=20 >>=20 >>=20 >> From: "Holmes, David W [CTO]" >> Date: Tuesday, February 24, 2015 at 5:06 PM >> To: "Peterson, Jon" , "modern@ietf.org" = >> Subject: Re: [Modern] draft charter >>=20 >> Jon,=20 >> =20 >> Thank you for the work in assembling this draft of the charter for = MODERN. >> =20 >> We would like to suggest some minor clarifications to the bullets = describing the deliverables, to align them with the statement regarding = flexibility to support the needs of different regulatory regimes, & thus = to ensure that if quoted alone they are not taken out of context; i.e. = the group product will be the protocols to support the allocation etc. = activities, & it would not attempt to define the allocation processes. = We also would like the charter to note the relevant work that has = already been performed by both IETF & the ATIS/SIP Forum JTF, & = incorporate that into the output from the MODERN WG as appropriate. = These changes/additions are have been added to your text inline below. >> =20 >> We are hoping that the MODERN session at IETF#92 will have remote = access, to allow participation by those of us that cannot attend in = person due to other commitments that week. =20 >> =20 >> Regards,=20 >> =20 >> David/Sprint=20 >> = __________________________________________________________________________= ____ >> =20 >> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, = Jon >> Sent: Wednesday, February 11, 2015 9:19 AM >> To: modern@ietf.org >> Subject: [Modern] draft charter >> =20 >> =20 >> At the Dallas IETF meeting in March, we'd like to get together and = talk about what a working group for MODERN might look like. As an = initial input to the discussion, a few of us have put together a = proposed charter. While the TeRQ work was positively evaluated in the = DISPATCH process, we feel this is broader enough in scope to warrant its = own BoF. >> =20 >> Comments are welcome, this is just a starting point. >> =20 >> ------ >> =20 >> Modern charter text: >> =20 >> The MODERN working group will define a set of Internet-based = mechanisms for the purposes of managing and resolving telephone numbers = (TNs) in an IP environment. Existing mechanisms for these purposes face = obsolescence as the voice communications infrastructure evolves to IP = technology and new applications for TNs become possible. The = traditional model of a TN having an association to a single service = provider and a single application is breaking down. Its use as a = network locator is going away, but its use as an identifier for an = individual or an organization will remain for some time. Devices, = applications, and network tools increasingly need to manage TNs, = including requesting and acquiring TN delegations from authorities. >> =20 >> The working group will define a framework for the roles and functions = involved in managing and resolving TNs in an IP environment. This = includes a protocol mechanism for acquiring TNs, which will provide an = enrollment process for the individuals and entities that use and manage = TNs. TNs may either be managed in a hierarchical tree, or in a = distributed peer-to-peer architecture. Privacy of the enrollment data = and security of the resource will be primary considerations. >> =20 >> Additionally, the working group will deliver a protocol mechanism for = resolving TNs which will allow entities such as service providers, = devices, and applications to access data related to TNs, possibly = including caller name data (CNAM). Maintaining reliability, real time = application performance, security and privacy are primary = considerations. The working group will take into consideration existing = IETF work including ENUM, SPEERMINT, STIR, and DRINKS. >> =20 >> The work of this group is limited to specifying a solution for TNs = and covers any service that can be addressed using a TN. Expanding the = work to other identifiers is out of scope. Solutions and mechanisms = created by the working group will be flexible enough to accommodate = different policies, e.g., by different regulatory agencies. >> =20 >> The work group will deliver the following: >> =20 >> - An architecture overview document that includes high level = requirements and security/privacy considerationsbuilt on the work of = IETF & the ATIS/SIP Forum JTF, that included: >> o Call routing architecture=20 >> o Inter-carrier NNI >> o Cryptographically-enabled Anti-spoofing (STIR) >> o Enhanced Calling Name (CNIT/CNAM) >> - A document describing the protocols to support enrollment = processes for existing and new TNs including any modifications to = metadata related to those TNs >> - A document describing protocol mechanisms for accessing = contact information associated with enrollments >> - A document describing protocol mechanisms for resolving = information related to TNs >> =20 >> - =20 >>=20 >>=20 >> This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. >> _______________________________________________ Modern mailing list = Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ Modern mailing list = Modern@ietf.org = https://www.ietf.org/mailman/listinfo/modern______________________________= _________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Mar 9 12:18:59 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5532F1A92F1 for ; Mon, 9 Mar 2015 12:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8qxI6uLDQFO for ; Mon, 9 Mar 2015 12:18:55 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id D16441AC3B8 for ; Mon, 9 Mar 2015 12:18:12 -0700 (PDT) Received: (qmail 27652 invoked by uid 0); 9 Mar 2015 19:18:10 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 9 Mar 2015 19:18:10 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id 1XJ31q01X1MNPNq01XJ6K7; Mon, 09 Mar 2015 13:18:08 -0600 X-Authority-Analysis: v=2.1 cv=dKs1xopb c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=8nJEP1OIZ-IA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=emO1SXQWCLwA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=AUd_NHdVAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=Xhd6g13joJ8v_uGCjp8A:9 a=Vu6-KxiaqVVSVxxF:21 a=lCFXZdjJTCtpuC0h:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=FQAysFGhXhVCDWL2RX6RzKVZpqw+QEZjCdThsRKfntE=; b=etXm4WJVb5/43CljLFWDfmtr1XRSke/JpDMhpMzw7KMEYKx2CNnKMGrH+MTtQiY+hZEIHxj1YVYi9dlaQeaVLmmrjKvJx9qUHBWBGdhCiRG1fZGYtw/XQdZVlqz/gNPz; Received: from [108.56.131.201] (port=49716 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YV3Bl-0004CG-Kl; Mon, 09 Mar 2015 13:18:05 -0600 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Mon, 09 Mar 2015 15:18:01 -0400 From: Richard Shockey To: Cullen Jennings , , "dispatch@ietf.org" , "modern@ietf.org" Message-ID: Thread-Topic: [dispatch] CNIT and Modern Charter References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> In-Reply-To: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:18:58 -0000 The first order issue is properly defining what this looks like in SIP and where in the headers it should reside. There is ample evidence that any number of other SDO are looking at this and without some proper standardization there will be no interoperability at all especially even for STIR validation data at the CUA and IMHO doing nothing is not a viable option. The basic FROM and PAI usage is not helpful. We are all aware of how smart phones work. This is principally about sessions that would originate outside a select number of phone book entries and some display of whether that information has been validated though we don=B9t have to define policy at this stage and frankly I don=B9t think the IETF should try any more than it could try and establish the business model for how this would deploy. The purpose here is simply adding more information about who originated the session so the called party has more information than they currently have. We already have enough bad actors as it is impersonating tax authorities, banks, health care professionals and other governmental entities. The purpose is to try and bound those problems to a manageable level. There is no silver bullet here. I would appreciate any suggestions on charter text if you have them. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 3/9/15, 11:10 AM, "Cullen Jennings" wrote: > >On the particular CNAM like topic ... > >I'm not keen on moving forward with something like this unless we can >show the trust and human factors issues is an engineering problem not a >research problem. We have seen the difficulty with human readable names >in SPAM. Particularly when using UTF-8, how do we stop bad actor getting >names that look the same as someone they wish to impersonate? Who will >validate the names and issue some sort of trust token that says I can use >"Cullen Jennings" or whatever. Who else can use that name and what about >names visually similar to it. > >On the flip side we are seeing most smart phones take the incoming phone >number, and look it up the personal address book of the user and display >the name that the user of the smartphone assigned. We are seeing >enterprise phones that do a similar things using the users social >networks as well as personal address book. > >What would be bad is phone display a display name that some how claimed >to be trustable but was not. That would be worse that the current >situation. Perhaps people have a good way to solve this in mind but I'm >not seeing that that is. > >Cullen (with my individual contribute hat on of course) > > > >> On Feb 25, 2015, at 10:05 AM, Richard Shockey >>wrote: >>=20 >>=20 >> Thanks Martin .. This is my very raw first cut at a charter. Its >>hopefully simple and straight forward. >>=20 >> Send me any edits etc. >>=20 >> ***** >>=20 >> CNIT Charter [Calling Name Identity Trust] >>=20 >> WG Chairs TBD: >>=20 >> Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters >>of information associated with a specific E.164 calling party number in >>the Public Switched Telephone Network [PSTN]. In the PSTN this data is >>sent by the originating network only at the specific request of the >>terminating network via a SS7 Transaction Application Part [TCAP] >>response message. In the Session Initiation Protocol [SIP] this >>information can be inserted into the FROM: part of the originating >>INVITE message or by other means. >>=20 >> As with the originating source telephone number, this data can be >>altered in transit creating a variety of malicious abuses similar to the >>ones identified by the IETF STIR working group. >>=20 >> The purpose of the CNIT working group will be to define a data >>structure, a new SIP header or repurpose an existing SIP header to carry >>an advanced form of CNAM as well as information from a STIR Validation >>Authority. The purpose of this work is to present to the SIP called >>party trusted information from the calling party in order that the >>called party make a more reasoned and informed judgment on whether to >>accept the INVITE or not. >>=20 >> The working group will not invalidate any existing SIP mechanism for >>anonymous calling. >>=20 >> The working group will, to the best of its ability, reuse existing IETF >>protocols. >>=20 >> Full Internationalization of the Calling Name Identity Trust data >>object(s) is a requirement. >>=20 >> The working group will closely work with the IETF STIR working group >>=20 >> The working group will immediately liaison with 3GPP SA-1 in order to >>coordinate efforts. >>=20 >> The working group will coordinate with National Numbering Authorities >>and National Regulatory Authorities as needed. >>=20 >> The working group will deliver the flowing. >>=20 >> =80 A problem statement and requirements detailing the current deployment >>environment and situations that motivate work on Calling Name Identity >>Trust. >> =80 Define either a new SIP header or document a repurpose of an SIP >>existing header for Calling Name Identify Trust data >> =80 Define a data model for the Calling Name Identity Trust object (s) >>which may include various forms of multimedia data >> =80 Deliver an analysis of privacy implications of the proposed Calling >>Name Identity Trust mechanism. >>=20 >>=20 >> Milestones: >>=20 >>=20 >> =8B=20 >> Richard Shockey >> Shockey Consulting LLC >> Chairman of the Board SIP Forum >> www.shockey.us >> www.sipforum.org >> richardshockey.us >> Skype-Linkedin-Facebook rshockey101 >> PSTN +1 703-593-2683 >>=20 >>=20 >> From: "DOLLY, MARTIN C" >> Date: Tuesday, February 24, 2015 at 9:02 PM >> To: Richard Shockey >> Cc: "Holmes, David W [CTO]" , >>"dispatch@ietf.org" , "modern@ietf.org" >>, "Peterson, Jon" >> Subject: Re: [Modern] [dispatch] draft charter >>=20 >> I support Richard on this >>=20 >> Martin Dolly >> Lead Member of Technical Staff >> Core & Gov't/Regulatory Standards >> AT&T Standards and >> Industry Alliances >> +1-609-903-3390 >> Sent from my iPhone >>=20 >> On Feb 24, 2015, at 6:36 PM, Richard Shockey wrote: >>=20 >>>=20 >>> Excellent points David. >>>=20 >>> My concern here is charter overreach. I really want to keep CNAM+/CNIT >>>out of this. IMHO that is a very separate and highly focused effort to >>>define both the modification of the SIP headers necessary to support >>>some enhanced calling party identification and a very limited effort to >>>define the object and or the STIR validation data. >>>=20 >>> I=B9m violently opposed to =B3end world hunger=B2 WG=B9s. >>>=20 >>> If registries can be used fine but I certainly want to see how this >>>can be accomplished in bi lateral agreements between consenting service >>>providers and work with CUA vendors on how the data is displayed aka >>>Apple, Samsung, Microsoft in the context of a formal liaison with 3GPP. >>> Certainly the relevance of CNAM+/CNIT in enterprise and residential >>>access markets is important but we all know =B3Money is the answer what >>>is the question ..=B2 >>>=20 >>> I=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and >>>report on the JTF on NNI. As you well know we have made considerable >>>progress. >>>=20 >>> Last week I gave a talk on this to a panel that included many of our >>>friends among the national regulators. >>>=20 >>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>=20 >>>=20 >>>=20 >>> From: "Holmes, David W [CTO]" >>> Date: Tuesday, February 24, 2015 at 5:06 PM >>> To: "Peterson, Jon" , "modern@ietf.org" >>> >>> Subject: Re: [Modern] draft charter >>>=20 >>> Jon,=20 >>> =20 >>> Thank you for the work in assembling this draft of the charter for >>>MODERN. >>> =20 >>> We would like to suggest some minor clarifications to the bullets >>>describing the deliverables, to align them with the statement regarding >>>flexibility to support the needs of different regulatory regimes, & >>>thus to ensure that if quoted alone they are not taken out of context; >>>i.e. the group product will be the protocols to support the allocation >>>etc. activities, & it would not attempt to define the allocation >>>processes. We also would like the charter to note the relevant work >>>that has already been performed by both IETF & the ATIS/SIP Forum JTF, >>>& incorporate that into the output from the MODERN WG as appropriate. >>>These changes/additions are have been added to your text inline below. >>> =20 >>> We are hoping that the MODERN session at IETF#92 will have remote >>>access, to allow participation by those of us that cannot attend in >>>person due to other commitments that week. >>> =20 >>> Regards,=20 >>> =20 >>> David/Sprint=20 >>>=20 >>>________________________________________________________________________ >>>______ >>> =20 >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, >>>Jon >>> Sent: Wednesday, February 11, 2015 9:19 AM >>> To: modern@ietf.org >>> Subject: [Modern] draft charter >>> =20 >>> =20 >>> At the Dallas IETF meeting in March, we'd like to get together and >>>talk about what a working group for MODERN might look like. As an >>>initial input to the discussion, a few of us have put together a >>>proposed charter. While the TeRQ work was positively evaluated in the >>>DISPATCH process, we feel this is broader enough in scope to warrant >>>its own BoF. >>> =20 >>> Comments are welcome, this is just a starting point. >>> =20 >>> ------ >>> =20 >>> Modern charter text: >>> =20 >>> The MODERN working group will define a set of Internet-based >>>mechanisms for the purposes of managing and resolving telephone numbers >>>(TNs) in an IP environment. Existing mechanisms for these purposes >>>face obsolescence as the voice communications infrastructure evolves to >>>IP technology and new applications for TNs become possible. The >>>traditional model of a TN having an association to a single service >>>provider and a single application is breaking down. Its use as a >>>network locator is going away, but its use as an identifier for an >>>individual or an organization will remain for some time. Devices, >>>applications, and network tools increasingly need to manage TNs, >>>including requesting and acquiring TN delegations from authorities. >>> =20 >>> The working group will define a framework for the roles and functions >>>involved in managing and resolving TNs in an IP environment. This >>>includes a protocol mechanism for acquiring TNs, which will provide an >>>enrollment process for the individuals and entities that use and manage >>>TNs. TNs may either be managed in a hierarchical tree, or in a >>>distributed peer-to-peer architecture. Privacy of the enrollment data >>>and security of the resource will be primary considerations. >>> =20 >>> Additionally, the working group will deliver a protocol mechanism for >>>resolving TNs which will allow entities such as service providers, >>>devices, and applications to access data related to TNs, possibly >>>including caller name data (CNAM). Maintaining reliability, real time >>>application performance, security and privacy are primary >>>considerations. The working group will take into consideration >>>existing IETF work including ENUM, SPEERMINT, STIR, and DRINKS. >>> =20 >>> The work of this group is limited to specifying a solution for TNs and >>>covers any service that can be addressed using a TN. Expanding the >>>work to other identifiers is out of scope. Solutions and mechanisms >>>created by the working group will be flexible enough to accommodate >>>different policies, e.g., by different regulatory agencies. >>> =20 >>> The work group will deliver the following: >>> =20 >>> - An architecture overview document that includes high level >>>requirements and security/privacy considerationsbuilt on the work of >>>IETF & the ATIS/SIP Forum JTF, that included: >>> o Call routing architecture >>> o Inter-carrier NNI >>> o Cryptographically-enabled Anti-spoofing (STIR) >>> o Enhanced Calling Name (CNIT/CNAM) >>> - A document describing the protocols to support enrollment >>>processes for existing and new TNs including any modifications to >>>metadata related to those TNs >>> - A document describing protocol mechanisms for accessing >>>contact information associated with enrollments >>> - A document describing protocol mechanisms for resolving >>>information related to TNs >>> =20 >>> - =20 >>>=20 >>>=20 >>> This e-mail may contain Sprint proprietary information intended for >>>the sole use of the recipient(s). Any use by others is prohibited. If >>>you are not the intended recipient, please contact the sender and >>>delete all copies of the message. >>> _______________________________________________ Modern mailing list >>>Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ Modern mailing list >>Modern@ietf.org=20 >>https://www.ietf.org/mailman/listinfo/modern_____________________________ >>__________________ >> 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 Mar 9 15:24:47 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C663E1ACDA1 for ; Mon, 9 Mar 2015 15:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7dD_f7KEgPG for ; Mon, 9 Mar 2015 15:24:34 -0700 (PDT) Received: from SLCv-EXEDGE01.Sorenson.com (slcv-exedge01.sorenson.com [209.169.244.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0411A016B for ; Mon, 9 Mar 2015 15:24:34 -0700 (PDT) Received: from SLC-EXHUB01.CORP.SRELAY.COM (10.20.38.90) by Mail.Sorenson.com (10.20.26.32) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 9 Mar 2015 16:23:38 -0600 Received: from SLC-EXMB01.CORP.SRELAY.COM ([fe80::a918:8b31:3421:8d2a]) by SLC-EXHUB01.CORP.SRELAY.COM ([::1]) with mapi id 14.01.0218.012; Mon, 9 Mar 2015 16:24:34 -0600 From: Scot Brooksby To: "fluffy@cisco.com" Thread-Topic: [VRS Interop] Re: [dispatch] New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt Thread-Index: AQHQWpQSIoP2JBnqF0+qFqe/UUv9x50UtYFA Date: Mon, 9 Mar 2015 22:24:33 +0000 Message-ID: <18D75981C159A342A11F851B5CD2DECFCCBD4DF1@SLC-EXMB01.CORP.SRELAY.COM> References: <6F2A17BA-AE0D-4370-A613-9E28B052AF16@cisco.com> <54FDE18C.7050800@alum.mit.edu> In-Reply-To: <54FDE18C.7050800@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.152.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] [VRS Interop] Re: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:24:38 -0000 Q3VsbGVuLA0KDQpUaGUgRkNDIHJ1bGVzIGZvciBSZWxheSBwcm92aWRlcnMgY2FuIGJlIGZvdW5k IGF0Og0KDQpodHRwOi8vd3d3LmVjZnIuZ292L2NnaS1iaW4vcmV0cmlldmVFQ0ZSP2dwPTEmU0lE PTc2YWZlNzQwNGNhMDUzOTE4M2I4ZWU5YjZkNzhlOGJlJnR5PUhUTUwmaD1MJnI9UEFSVCZuPXB0 NDcuMy42NCNzZTQ3LjMuNjRfMTYwNA0KDQpTcGVjaWZpY2FsbHksIHlvdSB3YW50IHRvIGxvb2sg YXQgwqc2NC42MDQsIHBhcmFncmFwaCAoYikoMikodmkpIChxdW90ZWQgYmVsb3cgLSB3aXRoIG15 IGVtcGhhc2lzIG9uIHRoZSBwYXJhZ3JhcGgpLg0KDQooMikgQ2FsbCBkYXRhIHJlcXVpcmVkIGZy b20gYWxsIFRSUyBwcm92aWRlcnMuIEluIGFkZGl0aW9uIHRvIHRoZSBkYXRhIHJlcXVlc3RlZCBi eSBwYXJhZ3JhcGggKGMpKDUpKGlpaSkoQykoMSkgb2YgdGhpcyBzZWN0aW9uLCBUUlMgcHJvdmlk ZXJzIHNlZWtpbmcgY29tcGVuc2F0aW9uIGZyb20gdGhlIFRSUyBGdW5kIHNoYWxsIHN1Ym1pdCB0 aGUgZm9sbG93aW5nIHNwZWNpZmljIGRhdGEgYXNzb2NpYXRlZCB3aXRoIGVhY2ggVFJTIGNhbGwg Zm9yIHdoaWNoIGNvbXBlbnNhdGlvbiBpcyBzb3VnaHQ6DQogICAgKGkpIFRoZSBjYWxsIHJlY29y ZCBJRCBzZXF1ZW5jZTsNCiAgICAoaWkpIENBIElEIG51bWJlcjsNCiAgICAoaWlpKSBTZXNzaW9u IHN0YXJ0IGFuZCBlbmQgdGltZXMgbm90ZWQgYXQgYSBtaW5pbXVtIHRvIHRoZSBuZWFyZXN0IHNl Y29uZDsNCiAgICAoaXYpIENvbnZlcnNhdGlvbiBzdGFydCBhbmQgZW5kIHRpbWVzIG5vdGVkIGF0 IGEgbWluaW11bSB0byB0aGUgbmVhcmVzdCBzZWNvbmQ7DQogICAgKHYpIEluY29taW5nIHRlbGVw aG9uZSBudW1iZXIgYW5kIElQIGFkZHJlc3MgKGlmIGNhbGwgb3JpZ2luYXRlcyB3aXRoIGFuIElQ LWJhc2VkIGRldmljZSkgYXQgdGhlIHRpbWUgb2YgdGhlIGNhbGw7DQogICAgKHZpKSBPdXRib3Vu ZCB0ZWxlcGhvbmUgbnVtYmVyIChpZiBjYWxsIHRlcm1pbmF0ZXMgdG8gYSB0ZWxlcGhvbmUpIGFu ZCBJUCBhZGRyZXNzIChpZiBjYWxsIHRlcm1pbmF0ZXMgdG8gYW4gSVAtYmFzZWQgZGV2aWNlKSBh dCB0aGUgdGltZSBvZiBjYWxsOw0KKioodmlpKSBUb3RhbCBjb252ZXJzYXRpb24gbWludXRlczsg KioNCiAgICAodmlpaSkgVG90YWwgc2Vzc2lvbiBtaW51dGVzOw0KICAgIChpeCkgVGhlIGNhbGwg Y2VudGVyIChieSBhc3NpZ25lZCBjZW50ZXIgSUQgbnVtYmVyKSB0aGF0IGhhbmRsZWQgdGhlIGNh bGw7IGFuZA0KICAgICh4KSBUaGUgVVJMIGFkZHJlc3MgdGhyb3VnaCB3aGljaCB0aGUgY2FsbCBp cyBoYW5kbGVkLg0KICAgICgzKSBBZGRpdGlvbmFsIGNhbGwgZGF0YSByZXF1aXJlZCBmcm9tIElu dGVybmV0LWJhc2VkIFJlbGF5IFByb3ZpZGVycy4gSW4gYWRkaXRpb24gdG8gdGhlIGRhdGEgcmVx dWlyZWQgYnkgcGFyYWdyYXBoIChjKSg1KShpaWkpKEMpKDIpIG9mIHRoaXMgc2VjdGlvbiwgSW50 ZXJuZXQtYmFzZWQgUmVsYXkgUHJvdmlkZXJzIHNlZWtpbmcgY29tcGVuc2F0aW9uIGZyb20gdGhl IEZ1bmQgc2hhbGwgc3VibWl0IHNwZWVkIG9mIGFuc3dlciBjb21wbGlhbmNlIGRhdGEuDQogICAg KDQpIFByb3ZpZGVycyBzdWJtaXR0aW5nIGNhbGwgcmVjb3JkIGFuZCBzcGVlZCBvZiBhbnN3ZXIg ZGF0YSBpbiBjb21wbGlhbmNlIHdpdGggcGFyYWdyYXBocyAoYykoNSkoaWlpKShDKSgyKSBhbmQg KGMpKDUpKGlpaSkoQykoMykgb2YgdGhpcyBzZWN0aW9uIHNoYWxsOg0KICAgIChpKSBFbXBsb3kg YW4gYXV0b21hdGVkIHJlY29yZCBrZWVwaW5nIHN5c3RlbSB0byBjYXB0dXJlIHN1Y2ggZGF0YSBy ZXF1aXJlZCBwdXJzdWFudCB0byBwYXJhZ3JhcGggKGMpKDUpKGlpaSkoQykoMikgb2YgdGhpcyBz ZWN0aW9uIGZvciBlYWNoIFRSUyBjYWxsIGZvciB3aGljaCBtaW51dGVzIGFyZSBzdWJtaXR0ZWQg dG8gdGhlIGZ1bmQgYWRtaW5pc3RyYXRvciBmb3IgY29tcGVuc2F0aW9uOyBhbmQNCiAgICAoaWkp IFN1Ym1pdCBzdWNoIGRhdGEgZWxlY3Ryb25pY2FsbHksIGluIGEgc3RhbmRhcmRpemVkIGZvcm1h dC4gRm9yIHB1cnBvc2VzIG9mIHRoaXMgc3VicGFyYWdyYXBoLCBhbiBhdXRvbWF0ZWQgcmVjb3Jk IGtlZXBpbmcgc3lzdGVtIGlzIGEgc3lzdGVtIHRoYXQgY2FwdHVyZXMgZGF0YSBpbiBhIGNvbXB1 dGVyaXplZCBhbmQgZWxlY3Ryb25pYyBmb3JtYXQgdGhhdCBkb2VzIG5vdCBhbGxvdyBodW1hbiBp bnRlcnZlbnRpb24gZHVyaW5nIHRoZSBjYWxsIHNlc3Npb24gZm9yIGVpdGhlciBjb252ZXJzYXRp b24gb3Igc2Vzc2lvbiB0aW1lLg0KDQpUaGFua3MsDQpTY290DQoNClNjb3QgQnJvb2tzYnkNCkVu Z2luZWVyaW5nIERpcmVjdG9yLCBBcmNoaXRlY3R1cmUgYW5kIEluZnJhc3RydWN0dXJlDQpTb3Jl bnNvbiBDb21tdW5pY2F0aW9ucw0KDQoNCj4gLS0tLS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0t LS0tLS0NCj4gU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvciBkcmFmdC1reXppdmF0LWRpc3BhdGNoLXRycy0NCj4gY2FsbC1pbmZvLXB1cnBvc2UtMDAu dHh0DQo+IERhdGU6IE1vbiwgOSBNYXIgMjAxNSAwODo1ODo1MSAtMDYwMA0KPiBGcm9tOiBDdWxs ZW4gSmVubmluZ3MgPGZsdWZmeUBjaXNjby5jb20+DQo+IFRvOiBQYXVsIEt5eml2YXQgPHBreXpp dmF0QGFsdW0ubWl0LmVkdT4NCj4gQ0M6IGRpc3BhdGNoQGlldGYub3JnIDxkaXNwYXRjaEBpZXRm Lm9yZz4NCj4gDQo+IA0KPiBUaGUgaGVhcnQgb2YgdGhpcyBkcmFmdCBnaXZlcyBtZSwgYWggLCBo ZWFydGJ1cm4uIFRoZSBpc3N1ZSBpcw0KPiANCj4gICAgIEZvciBhIHByb3ZpZGVyIHRvIHJlY2Vp dmUgcmVpbWJ1cnNlbWVudCBmb3IgcHJvdmlkaW5nIHJlbGF5IHNlcnZpY2UNCj4gICAgIG9uIGEg Y2FsbCB0aGUgRkNDIHJlcXVpcmVzIHRoYXQgdGhlIHByb3ZpZGVyIHN1cHBseSBjYWxsIGRldGFp bA0KPiAgICAgaW5jbHVkaW5nIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBkZXZpY2UgdGhlIFRSUyB1 c2VyIGlzIHVzaW5nIGZvciB0aGUNCj4gICAgIGNhbGwuDQo+IA0KPiBGaXJzdCBvZiBhbGwgd2hh dCBJUC4gVGhlIElQIG9mIHRoZWlyIHBob25lIGJlaGluZCB0aGVpciBsaW5rc3lzIG5hdD8NCj4g dGhlIHB1YmxpYyBJUCBvZiB0aGUgVFVSTiBzZXJ2ZXI/IHRoZSBWUE4/IE5vbmUgb2YgdGhlc2Ug YXJlIGEgdmlhYmxlDQo+IHdheSB0byBhdXRoZW50aWNhdGUgdGhhdCB0aGUgdXNlciBzaG91bGQg cmVjZWl2ZSB0aGlzIHNlcnZpY2VzIGFuZCB0aGUNCj4gSUVURiBzaG91bGQgaW1wbGljaXRseSBl bmRvcnNlIHRoYXQgdGhleSBhcmUuIEZ1cnRoZXJtb3JlIHRoZSBJRVRGDQo+IHNob3VsZCBiZSBq dXN0IGFzIGNvbmNlcm5lZCBhYm91dCBwcml2YWN5IGZvciBwZW9wbGUgdXNpbmcgYSBWUlMgYXMN Cj4gcGVvcGxlIHRoYXQgZG8gbm90IG5lZWQgb25lIGFuZCB0aGlzIHNvcnQgb2YgcmV2ZWFsIG15 IElQIGFkZHJlc3MgZXZlbg0KPiBpZiBJIHdhbnQgbG9jYXRpb24gcHJpdmFjeSBpcyBub3QgZ3Jl YXQuDQo+IA0KPiBHaXZlbiB0aGUgbGFjayBvZiBhbnkgc2VjdXJpdHkgYXJvdW5kIHRoaXMgYW5k IHRoZSBUUlMtNSByZXF1aXJlbWVudCwgSQ0KPiB3b25kZXIgaWYgb25lIGNhbiBqdXN0IGxvb2sg YXQgdGhlIHZpYSBsaXN0IGFuZCB1c2UgdGhhdD8NCj4gDQo+IElmIHdlIGRvIHByb2NlZWQgd2l0 aCB0aGlzLCBJIGRvbid0IHRoaW5rIHRoZSBjYWxsLWluZm8gaXMgdGhlDQo+IGFwcHJvcHJpYXRl IHBsYWNlIHRvIHB1dCBpdC4gSSB0aGluayBhIG5ldyBoZWFkZXIgd291bGQgYmUgdGhlIHJpZ2h0 IHRoaW5nLg0KPiANCj4gQ2FuIHlvdSBwcm92aWRlIGEgcG9pbnRlciB0byB0aGUgYWN0dWFsbHkg RkNDIHJ1bGVzIGZvciB0aGlzPw0KPiANCj4gSWYgdGhlIGdvYWwgaXMgcHVyZWx5IHRvIGNoZWNr IHRoZSB1c2VyIGlzIGluIHRoZSBVUywgdGhlbiBoYXZpbmcgdGhlDQo+IFZSUyBjaGVjayB0aGF0 IHRoZXkgd2VyZSBzZW5kaW5nIG1lZGlhIHRvIGFuIElQIGFkZHJlc3MgaW5zaWRlIHRoZSBVUw0K PiBzZWVtcyBsaWtlIGl0IHdvdWxkIGJlIGEgYmV0dGVyIHNvbHV0aW9uLg0KPiANCj4gVGhhbmtz DQo+IA0KPiANCj4gDQo+ID4gT24gSmFuIDEzLCAyMDE1LCBhdCA5OjE0IEFNLCBQYXVsIEt5eml2 YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6DQo+ID4NCj4gPiBEaXNwYXRjaGVyczoN Cj4gPg0KPiA+IEkgaGF2ZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCAoc2VlIGJlbG93KSB0 aGF0IG5lZWRzIHRvIGJlIGRpc3BhdGNoZWQuIEl0DQo+IGRlZmluZXMgYSBuZXcgQ2FsbC1JbmZv ICdwdXJwb3NlJyBwYXJhbWV0ZXIgdmFsdWUuDQo+ID4NCj4gPiBUaGUgaW50ZW5kZWQgYXVkaWVu Y2UgZm9yIHRoaXMgZHJhZnQgaXMgcXVpdGUgbGltaXRlZCAtIHRvIHRoZSBwcm92aWRlcnMgb2Yg dGhlDQo+IFZpZGVvIFJlbGF5IFNlcnZpY2UgaW4gdGhlIFVTLCBhbmQgdG8gdGhlIEZDQyB0aGF0 IHNwb25zb3JzIHRoYXQgc2VydmljZS4gVGhlDQo+IEludHJvIHNlY3Rpb24gZXhwbGFpbnMgdGhp cy4NCj4gPg0KPiA+IEknbSBob3BpbmcgdGhpcyBjYW4gYmUgZGlzcGF0Y2hlZCB3aXRob3V0IGNh dXNpbmcgYSBsb3Qgb2YgYm90aGVyIGZvciBhbnlib2R5Lg0KPiBJIGRvbid0IGFudGljaXBhdGUg dGhhdCBpdCBuZWVkcyB0aW1lIGluIERhbGxhcy4gSUlVQyBkb2N1bWVudHMgb2YgdGhpcyBzb3J0 IGFyZQ0KPiBvZnRlbiBBRCBzcG9uc29yZWQuDQo+ID4NCj4gPiAJVGhhbmtzLA0KPiA+IAlQYXVs DQo+ID4NCj4gPiAtLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQo+ID4gU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1reXppdmF0LWRpc3BhdGNoLXRy cy1jYWxsLWluZm8tDQo+IHB1cnBvc2UtMDAudHh0DQo+ID4gRGF0ZTogVHVlLCAxMyBKYW4gMjAx NSAwNzo0Njo0NyAtMDgwMA0KPiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+ IFRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4sICAgICAgICAiUGF1bCBL eXppdmF0Ig0KPiA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQta3l6aXZhdC1kaXNwYXRjaC10cnMtY2FsbC1pbmZvLXB1cnBv c2UtMDAudHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQYXVsIEt5 eml2YXQgYW5kIHBvc3RlZCB0byB0aGUNCj4gPiBJRVRGIHJlcG9zaXRvcnkuDQo+ID4NCj4gPiBO YW1lOgkJZHJhZnQta3l6aXZhdC1kaXNwYXRjaC10cnMtY2FsbC1pbmZvLXB1cnBvc2UNCj4gPiBS ZXZpc2lvbjoJMDANCj4gPiBUaXRsZToJCVRlbGVjb21tdW5pY2F0aW9ucyBSZWxheSBTZXJ2aWNl IFB1cnBvc2UgZm9yIHRoZSBDYWxsLUluZm8NCj4gSGVhZGVyIEZpZWxkIGluIHRoZSBTZXNzaW9u IEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkNCj4gPiBEb2N1bWVudCBkYXRlOgkyMDE1LTAxLTEz DQo+ID4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPiBQYWdlczoJCTQNCj4gPiBV Ukw6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWt5eml2YXQtZGlz cGF0Y2gtdHJzLWNhbGwtaW5mby0NCj4gcHVycG9zZS0wMC50eHQNCj4gPiBTdGF0dXM6IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt5eml2YXQtZGlzcGF0Y2gtdHJzLWNh bGwtaW5mby0NCj4gcHVycG9zZS8NCj4gPiBIdG1saXplZDogaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQta3l6aXZhdC1kaXNwYXRjaC10cnMtY2FsbC1pbmZvLQ0KPiBwdXJwb3NlLTAw DQo+ID4NCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGFu ZCByZWdpc3RlcnMgYSB2YWx1ZSBvZiAib3JpZ2luYWwtaWRlbnRpdHkiDQo+ID4gICBmb3IgdGhl ICJwdXJwb3NlIiBoZWFkZXIgZmllbGQgcGFyYW1ldGVyIG9mIHRoZSBDYWxsLUluZm8gaGVhZGVy DQo+ID4gICBmaWVsZCBpbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVApLg0K PiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiA+IHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBk aXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4gPg0KPiANCj4gDQo+IA0K PiANCj4gLS0NCj4gWW91IHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBiZWNhdXNlIHlvdSBhcmUgc3Vi c2NyaWJlZCB0byB0aGUgR29vZ2xlIEdyb3Vwcw0KPiAiVlJTIEludGVyb3AiIGdyb3VwLg0KPiBU byB1bnN1YnNjcmliZSBmcm9tIHRoaXMgZ3JvdXAgYW5kIHN0b3AgcmVjZWl2aW5nIGVtYWlscyBm cm9tIGl0LCBzZW5kIGFuDQo+IGVtYWlsIHRvIGlvK3Vuc3Vic2NyaWJlQHZycy5pby4NCj4gVG8g cG9zdCB0byB0aGlzIGdyb3VwLCBzZW5kIGVtYWlsIHRvIGlvQHZycy5pby4NCj4gVmlzaXQgdGhp cyBncm91cCBhdCBodHRwOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS92cnMuaW8vZ3JvdXAvaW8vLg0K From nobody Mon Mar 9 17:19:26 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6E41ACDE3; Mon, 9 Mar 2015 15:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbEX22Wh-K5v; Mon, 9 Mar 2015 15:26:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87A01ACDDE; Mon, 9 Mar 2015 15:26:18 -0700 (PDT) Received: from BN1AFFO11FD053.protection.gbl (10.58.52.31) by BN1AFFO11HUB014.protection.gbl (10.58.52.124) with Microsoft SMTP Server (TLS) id 15.1.112.13; Mon, 9 Mar 2015 22:26:02 +0000 Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by BN1AFFO11FD053.mail.protection.outlook.com (10.58.53.68) with Microsoft SMTP Server (TLS) id 15.1.112.13 via Frontend Transport; Mon, 9 Mar 2015 22:26:02 +0000 Received: from pdaasen2.corp.sprint.com (pdaasen2.corp.sprint.com [144.226.111.130]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t29MQ0Jd005698 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2015 17:26:00 -0500 Received: from PREWE13M08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by pdaasen2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t29MPx6i032711 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Mar 2015 17:26:00 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 9 Mar 2015 18:25:58 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0995.028; Mon, 9 Mar 2015 17:25:58 -0500 From: "Gorman, Pierce A [CTO]" To: Richard Shockey , Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Thread-Topic: [dispatch] CNIT and Modern Charter Thread-Index: AQHQWp3ul5him8B2KUGtFEmSTKBzBp0UtHzw Date: Mon, 9 Mar 2015 22:25:58 +0000 Message-ID: References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.21] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.229.32.57 as permitted sender) receiver=protection.outlook.com; client-ip=144.229.32.57; helo=pdaasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.57) smtp.mailfrom=Pierce.Gorman@sprint.com; shockey.us; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:144.229.32.57; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(377454003)(199003)(53824002)(51704005)(479174004)(24454002)(13464003)(2501003)(107886001)(106466001)(106116001)(108616004)(5250100002)(46102003)(23676002)(33646002)(86362001)(87936001)(15975445007)(19580405001)(19580395003)(54356999)(15974865002)(50986999)(551934003)(76176999)(2900100001)(2950100001)(62966003)(77156002)(2201001)(6806004)(102836002)(92726002)(2656002)(50466002)(92566002)(47776003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB014; H:pdaasdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB014; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BN1AFFO11HUB014; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB014; X-Forefront-PRVS: 05102978A2 X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2015 22:26:02.0913 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.229.32.57]; Helo=[pdaasdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB014 Archived-At: X-Mailman-Approved-At: Mon, 09 Mar 2015 17:19:23 -0700 Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:26:23 -0000 SSBkb24ndCBoYXZlIGFueSB1c2VmdWwgY2hhcnRlciB0ZXh0Lg0KSSBhZ3JlZSB0aGF0IHRoZSBJ RVRGIHNob3VsZCBub3QgcHJvcG9zZSBidXNpbmVzcyBtb2RlbHMsIGJ1dCBpdCBzZWVtcyBpbXBv cnRhbnQgdG8gY29uc2lkZXIgdHJ1c3QgbW9kZWwocykgdG8gc2VlIGlmIGl0L3RoZXkgZHJpdmUg cHJvdG9jb2wgY29uc2lkZXJhdGlvbnMuDQpXZSBjb3VsZCBzdGFydCB3aXRoIGxpc3RpbmcgYXNz dW1wdGlvbnMuICBJJ2xsIHN0YXJ0IGJ5IGxpc3RpbmcgdHdvLg0KICAgICAxKSBJIGFzc3VtZSB0 aGVyZSB3b3VsZCBiZSBtdWx0aXBsZSBhdXRob3JpdGllcyBhbmQgbXVsdGlwbGUgbGV2ZWxzIG9m IHRydXN0Lg0KICAgICAyKSBJIGFzc3VtZSB0aGVyZSBhcmUgaW50ZXJuYXRpb25hbCB0cmFkZW5h bWUsIGFuZCB0cmFkZW1hcmsgYW5kIHRoZSBhZm9yZW1lbnRpb25lZCBVVEYtOCBpbnRlcm5hdGlv bmFsIGNoYXJhY3RlciBjb2RlIHNwb29maW5nIGNvbnNpZGVyYXRpb25zLg0KDQoNCkJlc3QgcmVn YXJkcywNCg0KDQpQaWVyY2UgR29ybWFuDQpWb2ljZSBBcmNoaXRlY3R1cmUNCkNvcmUgUGxhbm5p bmcvU3ByaW50DQo5MTMtNDM5LTQzNjggKERlc2spDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBNb2Rlcm4gW21haWx0bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFJpY2hhcmQgU2hvY2tleQ0KU2VudDogTWFyY2ggMDksIDIwMTUgMjoxOCBQTQ0KVG86 IEN1bGxlbiBKZW5uaW5nczsgY25pdEBpZXRmLm9yZzsgZGlzcGF0Y2hAaWV0Zi5vcmc7IG1vZGVy bkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNb2Rlcm5dIFtkaXNwYXRjaF0gQ05JVCBhbmQgTW9k ZXJuIENoYXJ0ZXINCg0KDQpUaGUgZmlyc3Qgb3JkZXIgaXNzdWUgaXMgcHJvcGVybHkgZGVmaW5p bmcgd2hhdCB0aGlzIGxvb2tzIGxpa2UgaW4gU0lQIGFuZCB3aGVyZSBpbiB0aGUgaGVhZGVycyBp dCBzaG91bGQgcmVzaWRlLiBUaGVyZSBpcyBhbXBsZSBldmlkZW5jZSB0aGF0IGFueSBudW1iZXIg b2Ygb3RoZXIgU0RPIGFyZSBsb29raW5nIGF0IHRoaXMgYW5kIHdpdGhvdXQgc29tZSBwcm9wZXIg c3RhbmRhcmRpemF0aW9uIHRoZXJlIHdpbGwgYmUgbm8gaW50ZXJvcGVyYWJpbGl0eSBhdCBhbGwg ZXNwZWNpYWxseSBldmVuIGZvciBTVElSIHZhbGlkYXRpb24gZGF0YSBhdCB0aGUgQ1VBIGFuZCBJ TUhPIGRvaW5nIG5vdGhpbmcgaXMgbm90IGEgdmlhYmxlIG9wdGlvbi4gVGhlIGJhc2ljIEZST00g YW5kIFBBSSB1c2FnZSBpcyBub3QgaGVscGZ1bC4NCg0KV2UgYXJlIGFsbCBhd2FyZSBvZiBob3cg c21hcnQgcGhvbmVzIHdvcmsuIFRoaXMgaXMgcHJpbmNpcGFsbHkgYWJvdXQgc2Vzc2lvbnMgdGhh dCB3b3VsZCBvcmlnaW5hdGUgb3V0c2lkZSBhIHNlbGVjdCBudW1iZXIgb2YgcGhvbmUgYm9vayBl bnRyaWVzIGFuZCBzb21lIGRpc3BsYXkgb2Ygd2hldGhlciB0aGF0IGluZm9ybWF0aW9uIGhhcyBi ZWVuIHZhbGlkYXRlZCB0aG91Z2ggd2UgZG9uwrl0IGhhdmUgdG8gZGVmaW5lIHBvbGljeSBhdCB0 aGlzIHN0YWdlIGFuZCBmcmFua2x5IEkgZG9uwrl0IHRoaW5rIHRoZSBJRVRGIHNob3VsZCB0cnkg YW55IG1vcmUgdGhhbiBpdCBjb3VsZCB0cnkgYW5kIGVzdGFibGlzaCB0aGUgYnVzaW5lc3MgbW9k ZWwgZm9yIGhvdyB0aGlzIHdvdWxkIGRlcGxveS4NCg0KVGhlIHB1cnBvc2UgaGVyZSBpcyBzaW1w bHkgYWRkaW5nIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgd2hvIG9yaWdpbmF0ZWQgdGhlIHNlc3Np b24gc28gdGhlIGNhbGxlZCBwYXJ0eSBoYXMgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIHRoZXkgY3Vy cmVudGx5IGhhdmUuICBXZSBhbHJlYWR5IGhhdmUgZW5vdWdoIGJhZCBhY3RvcnMgYXMgaXQgaXMg aW1wZXJzb25hdGluZyB0YXggYXV0aG9yaXRpZXMsIGJhbmtzLCBoZWFsdGggY2FyZSBwcm9mZXNz aW9uYWxzIGFuZCBvdGhlciBnb3Zlcm5tZW50YWwgZW50aXRpZXMuIFRoZSBwdXJwb3NlIGlzIHRv IHRyeSBhbmQgYm91bmQgdGhvc2UgcHJvYmxlbXMgdG8gYSBtYW5hZ2VhYmxlIGxldmVsLiAgVGhl cmUgaXMgbm8gc2lsdmVyIGJ1bGxldCBoZXJlLg0KDQpJIHdvdWxkIGFwcHJlY2lhdGUgYW55IHN1 Z2dlc3Rpb25zIG9uIGNoYXJ0ZXIgdGV4dCBpZiB5b3UgaGF2ZSB0aGVtLg0KDQoNCg0K4oC5DQpS aWNoYXJkIFNob2NrZXkNClNob2NrZXkgQ29uc3VsdGluZyBMTEMNCkNoYWlybWFuIG9mIHRoZSBC b2FyZCBTSVAgRm9ydW0NCnd3dy5zaG9ja2V5LnVzDQp3d3cuc2lwZm9ydW0ub3JnDQpyaWNoYXJk PGF0PnNob2NrZXkudXMNClNreXBlLUxpbmtlZGluLUZhY2Vib29rIHJzaG9ja2V5MTAxDQpQU1RO ICsxIDcwMy01OTMtMjY4Mw0KDQoNCg0KDQoNCk9uIDMvOS8xNSwgMTE6MTAgQU0sICJDdWxsZW4g SmVubmluZ3MiIDxmbHVmZnlAY2lzY28uY29tPiB3cm90ZToNCg0KPg0KPk9uIHRoZSBwYXJ0aWN1 bGFyIENOQU0gbGlrZSB0b3BpYyAuLi4NCj4NCj5JJ20gbm90IGtlZW4gb24gbW92aW5nIGZvcndh cmQgd2l0aCBzb21ldGhpbmcgbGlrZSB0aGlzIHVubGVzcyB3ZSBjYW4NCj5zaG93IHRoZSB0cnVz dCBhbmQgaHVtYW4gZmFjdG9ycyBpc3N1ZXMgaXMgYW4gZW5naW5lZXJpbmcgcHJvYmxlbSBub3Qg YQ0KPnJlc2VhcmNoIHByb2JsZW0uIFdlIGhhdmUgc2VlbiB0aGUgZGlmZmljdWx0eSB3aXRoIGh1 bWFuIHJlYWRhYmxlIG5hbWVzDQo+aW4gU1BBTS4gUGFydGljdWxhcmx5IHdoZW4gdXNpbmcgVVRG LTgsIGhvdyBkbyB3ZSBzdG9wIGJhZCBhY3RvciBnZXR0aW5nDQo+bmFtZXMgdGhhdCBsb29rIHRo ZSBzYW1lIGFzIHNvbWVvbmUgdGhleSB3aXNoIHRvIGltcGVyc29uYXRlPyBXaG8gd2lsbA0KPnZh bGlkYXRlIHRoZSBuYW1lcyBhbmQgaXNzdWUgc29tZSBzb3J0IG9mIHRydXN0IHRva2VuIHRoYXQg c2F5cyBJIGNhbiB1c2UNCj4iQ3VsbGVuIEplbm5pbmdzIiBvciB3aGF0ZXZlci4gV2hvIGVsc2Ug Y2FuIHVzZSB0aGF0IG5hbWUgYW5kIHdoYXQgYWJvdXQNCj5uYW1lcyB2aXN1YWxseSBzaW1pbGFy IHRvIGl0Lg0KPg0KPk9uIHRoZSBmbGlwIHNpZGUgd2UgYXJlIHNlZWluZyBtb3N0IHNtYXJ0IHBo b25lcyB0YWtlIHRoZSBpbmNvbWluZyBwaG9uZQ0KPm51bWJlciwgYW5kIGxvb2sgaXQgdXAgdGhl IHBlcnNvbmFsIGFkZHJlc3MgYm9vayBvZiB0aGUgdXNlciBhbmQgZGlzcGxheQ0KPnRoZSBuYW1l IHRoYXQgdGhlIHVzZXIgb2YgdGhlIHNtYXJ0cGhvbmUgYXNzaWduZWQuIFdlIGFyZSBzZWVpbmcN Cj5lbnRlcnByaXNlIHBob25lcyB0aGF0IGRvIGEgc2ltaWxhciB0aGluZ3MgdXNpbmcgdGhlIHVz ZXJzICBzb2NpYWwNCj5uZXR3b3JrcyBhcyB3ZWxsIGFzIHBlcnNvbmFsIGFkZHJlc3MgYm9vay4N Cj4NCj5XaGF0IHdvdWxkIGJlIGJhZCBpcyBwaG9uZSBkaXNwbGF5IGEgZGlzcGxheSBuYW1lIHRo YXQgc29tZSBob3cgY2xhaW1lZA0KPnRvIGJlIHRydXN0YWJsZSBidXQgd2FzIG5vdC4gVGhhdCB3 b3VsZCBiZSB3b3JzZSB0aGF0IHRoZSBjdXJyZW50DQo+c2l0dWF0aW9uLiBQZXJoYXBzIHBlb3Bs ZSBoYXZlIGEgZ29vZCB3YXkgdG8gc29sdmUgdGhpcyBpbiBtaW5kIGJ1dCBJJ20NCj5ub3Qgc2Vl aW5nIHRoYXQgdGhhdCBpcy4NCj4NCj5DdWxsZW4gKHdpdGggbXkgaW5kaXZpZHVhbCBjb250cmli dXRlIGhhdCBvbiBvZiBjb3Vyc2UpDQo+DQo+DQo+DQo+PiBPbiBGZWIgMjUsIDIwMTUsIGF0IDEw OjA1IEFNLCBSaWNoYXJkIFNob2NrZXkgPHJpY2hhcmRAc2hvY2tleS51cz4NCj4+d3JvdGU6DQo+ Pg0KPj4NCj4+IFRoYW5rcyBNYXJ0aW4gLi4gVGhpcyBpcyBteSB2ZXJ5IHJhdyBmaXJzdCBjdXQg YXQgYSBjaGFydGVyLiBJdHMNCj4+aG9wZWZ1bGx5IHNpbXBsZSBhbmQgc3RyYWlnaHQgZm9yd2Fy ZC4NCj4+DQo+PiBTZW5kIG1lIGFueSBlZGl0cyBldGMuDQo+Pg0KPj4gKioqKioNCj4+DQo+PiBD TklUIENoYXJ0ZXIgW0NhbGxpbmcgTmFtZSBJZGVudGl0eSBUcnVzdF0NCj4+DQo+PiBXRyBDaGFp cnMgVEJEOg0KPj4NCj4+IENhbGxpbmcgTmFtZSBEZWxpdmVyeSBbQ05BTV0gaXMgYSBzdHJpbmcg b2YgdXAgdG8gMTUgQVNDSUkgQ2hhcmFjdGVycw0KPj5vZiBpbmZvcm1hdGlvbiBhc3NvY2lhdGVk IHdpdGggYSBzcGVjaWZpYyBFLjE2NCBjYWxsaW5nIHBhcnR5IG51bWJlciBpbg0KPj50aGUgUHVi bGljIFN3aXRjaGVkIFRlbGVwaG9uZSBOZXR3b3JrIFtQU1ROXS4gIEluIHRoZSBQU1ROIHRoaXMg ZGF0YSBpcw0KPj5zZW50IGJ5IHRoZSBvcmlnaW5hdGluZyBuZXR3b3JrIG9ubHkgYXQgdGhlIHNw ZWNpZmljIHJlcXVlc3Qgb2YgdGhlDQo+PnRlcm1pbmF0aW5nIG5ldHdvcmsgdmlhIGEgU1M3IFRy YW5zYWN0aW9uIEFwcGxpY2F0aW9uIFBhcnQgW1RDQVBdDQo+PnJlc3BvbnNlIG1lc3NhZ2UuICBJ biB0aGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIFtTSVBdIHRoaXMNCj4+aW5mb3JtYXRp b24gY2FuIGJlIGluc2VydGVkIGludG8gdGhlIEZST006IHBhcnQgb2YgdGhlIG9yaWdpbmF0aW5n DQo+PklOVklURSBtZXNzYWdlIG9yIGJ5IG90aGVyIG1lYW5zLg0KPj4NCj4+IEFzIHdpdGggdGhl IG9yaWdpbmF0aW5nIHNvdXJjZSB0ZWxlcGhvbmUgbnVtYmVyLCB0aGlzIGRhdGEgY2FuIGJlDQo+ PmFsdGVyZWQgaW4gdHJhbnNpdCBjcmVhdGluZyBhIHZhcmlldHkgb2YgbWFsaWNpb3VzIGFidXNl cyBzaW1pbGFyIHRvIHRoZQ0KPj5vbmVzIGlkZW50aWZpZWQgYnkgdGhlIElFVEYgU1RJUiB3b3Jr aW5nIGdyb3VwLg0KPj4NCj4+IFRoZSBwdXJwb3NlIG9mIHRoZSBDTklUIHdvcmtpbmcgZ3JvdXAg d2lsbCBiZSB0byBkZWZpbmUgYSBkYXRhDQo+PnN0cnVjdHVyZSwgYSBuZXcgU0lQIGhlYWRlciBv ciByZXB1cnBvc2UgYW4gZXhpc3RpbmcgU0lQIGhlYWRlciB0byBjYXJyeQ0KPj5hbiBhZHZhbmNl ZCBmb3JtIG9mIENOQU0gYXMgd2VsbCBhcyBpbmZvcm1hdGlvbiBmcm9tIGEgU1RJUiBWYWxpZGF0 aW9uDQo+PkF1dGhvcml0eS4gIFRoZSBwdXJwb3NlIG9mIHRoaXMgd29yayBpcyB0byBwcmVzZW50 IHRvIHRoZSBTSVAgY2FsbGVkDQo+PnBhcnR5IHRydXN0ZWQgaW5mb3JtYXRpb24gZnJvbSB0aGUg Y2FsbGluZyBwYXJ0eSBpbiBvcmRlciB0aGF0IHRoZQ0KPj5jYWxsZWQgcGFydHkgbWFrZSBhIG1v cmUgcmVhc29uZWQgYW5kIGluZm9ybWVkIGp1ZGdtZW50IG9uIHdoZXRoZXIgdG8NCj4+YWNjZXB0 IHRoZSBJTlZJVEUgb3Igbm90Lg0KPj4NCj4+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgbm90IGlu dmFsaWRhdGUgYW55IGV4aXN0aW5nIFNJUCBtZWNoYW5pc20gZm9yDQo+PmFub255bW91cyBjYWxs aW5nLg0KPj4NCj4+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwsIHRvIHRoZSBiZXN0IG9mIGl0cyBh YmlsaXR5LCByZXVzZSBleGlzdGluZyBJRVRGDQo+PnByb3RvY29scy4NCj4+DQo+PiBGdWxsIElu dGVybmF0aW9uYWxpemF0aW9uIG9mIHRoZSBDYWxsaW5nIE5hbWUgSWRlbnRpdHkgVHJ1c3QgZGF0 YQ0KPj5vYmplY3QocykgaXMgYSByZXF1aXJlbWVudC4NCj4+DQo+PiBUaGUgd29ya2luZyBncm91 cCB3aWxsIGNsb3NlbHkgd29yayB3aXRoIHRoZSBJRVRGIFNUSVIgd29ya2luZyBncm91cA0KPj4N Cj4+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgaW1tZWRpYXRlbHkgbGlhaXNvbiB3aXRoIDNHUFAg U0EtMSBpbiBvcmRlciB0bw0KPj5jb29yZGluYXRlIGVmZm9ydHMuDQo+Pg0KPj4gVGhlIHdvcmtp bmcgZ3JvdXAgd2lsbCBjb29yZGluYXRlIHdpdGggTmF0aW9uYWwgTnVtYmVyaW5nIEF1dGhvcml0 aWVzDQo+PmFuZCBOYXRpb25hbCBSZWd1bGF0b3J5IEF1dGhvcml0aWVzIGFzIG5lZWRlZC4NCj4+ DQo+PiBUaGUgd29ya2luZyBncm91cCB3aWxsIGRlbGl2ZXIgdGhlIGZsb3dpbmcuDQo+Pg0KPj4g 4oKsQSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgcmVxdWlyZW1lbnRzIGRldGFpbGluZyB0aGUgY3Vy cmVudCBkZXBsb3ltZW50DQo+PmVudmlyb25tZW50IGFuZCBzaXR1YXRpb25zIHRoYXQgbW90aXZh dGUgd29yayBvbiBDYWxsaW5nIE5hbWUgSWRlbnRpdHkNCj4+VHJ1c3QuDQo+PiDigqxEZWZpbmUg ZWl0aGVyIGEgbmV3IFNJUCBoZWFkZXIgb3IgZG9jdW1lbnQgYSByZXB1cnBvc2Ugb2YgYW4gU0lQ DQo+PmV4aXN0aW5nIGhlYWRlciBmb3IgQ2FsbGluZyBOYW1lIElkZW50aWZ5IFRydXN0IGRhdGEN Cj4+IOKCrERlZmluZSBhIGRhdGEgbW9kZWwgZm9yIHRoZSBDYWxsaW5nIE5hbWUgSWRlbnRpdHkg VHJ1c3Qgb2JqZWN0IChzKQ0KPj53aGljaCBtYXkgaW5jbHVkZSB2YXJpb3VzIGZvcm1zIG9mIG11 bHRpbWVkaWEgZGF0YQ0KPj4g4oKsRGVsaXZlciBhbiBhbmFseXNpcyBvZiBwcml2YWN5IGltcGxp Y2F0aW9ucyBvZiB0aGUgcHJvcG9zZWQgQ2FsbGluZw0KPj5OYW1lIElkZW50aXR5IFRydXN0IG1l Y2hhbmlzbS4NCj4+DQo+Pg0KPj4gTWlsZXN0b25lczoNCj4+DQo+Pg0KPj4g4oC5DQo+PiBSaWNo YXJkIFNob2NrZXkNCj4+IFNob2NrZXkgQ29uc3VsdGluZyBMTEMNCj4+IENoYWlybWFuIG9mIHRo ZSBCb2FyZCBTSVAgRm9ydW0NCj4+IHd3dy5zaG9ja2V5LnVzDQo+PiB3d3cuc2lwZm9ydW0ub3Jn DQo+PiByaWNoYXJkPGF0PnNob2NrZXkudXMNCj4+IFNreXBlLUxpbmtlZGluLUZhY2Vib29rIHJz aG9ja2V5MTAxDQo+PiBQU1ROICsxIDcwMy01OTMtMjY4Mw0KPj4NCj4+DQo+PiBGcm9tOiAiRE9M TFksIE1BUlRJTiBDIiA8bWQzMTM1QGF0dC5jb20+DQo+PiBEYXRlOiBUdWVzZGF5LCBGZWJydWFy eSAyNCwgMjAxNSBhdCA5OjAyIFBNDQo+PiBUbzogUmljaGFyZCBTaG9ja2V5IDxyaWNoYXJkQHNo b2NrZXkudXM+DQo+PiBDYzogIkhvbG1lcywgRGF2aWQgVyBbQ1RPXSIgPERhdmlkLkhvbG1lc0Bz cHJpbnQuY29tPiwNCj4+ImRpc3BhdGNoQGlldGYub3JnIiA8ZGlzcGF0Y2hAaWV0Zi5vcmc+LCAi bW9kZXJuQGlldGYub3JnIg0KPj48bW9kZXJuQGlldGYub3JnPiwgIlBldGVyc29uLCBKb24iIDxq b24ucGV0ZXJzb25AbmV1c3Rhci5iaXo+DQo+PiBTdWJqZWN0OiBSZTogW01vZGVybl0gW2Rpc3Bh dGNoXSBkcmFmdCBjaGFydGVyDQo+Pg0KPj4gSSBzdXBwb3J0IFJpY2hhcmQgb24gdGhpcw0KPj4N Cj4+IE1hcnRpbiBEb2xseQ0KPj4gTGVhZCBNZW1iZXIgb2YgVGVjaG5pY2FsIFN0YWZmDQo+PiBD b3JlICYgR292J3QvUmVndWxhdG9yeSBTdGFuZGFyZHMNCj4+IEFUJlQgU3RhbmRhcmRzIGFuZA0K Pj4gSW5kdXN0cnkgQWxsaWFuY2VzDQo+PiArMS02MDktOTAzLTMzOTANCj4+IFNlbnQgZnJvbSBt eSBpUGhvbmUNCj4+DQo+PiBPbiBGZWIgMjQsIDIwMTUsIGF0IDY6MzYgUE0sIFJpY2hhcmQgU2hv Y2tleSA8cmljaGFyZEBzaG9ja2V5LnVzPiB3cm90ZToNCj4+DQo+Pj4NCj4+PiBFeGNlbGxlbnQg cG9pbnRzIERhdmlkLg0KPj4+DQo+Pj4gTXkgY29uY2VybiBoZXJlIGlzIGNoYXJ0ZXIgb3ZlcnJl YWNoLiBJIHJlYWxseSB3YW50IHRvIGtlZXAgQ05BTSsvQ05JVA0KPj4+b3V0IG9mIHRoaXMuICBJ TUhPIHRoYXQgaXMgYSB2ZXJ5IHNlcGFyYXRlIGFuZCBoaWdobHkgZm9jdXNlZCBlZmZvcnQgdG8N Cj4+PmRlZmluZSBib3RoIHRoZSBtb2RpZmljYXRpb24gb2YgdGhlIFNJUCBoZWFkZXJzIG5lY2Vz c2FyeSB0byBzdXBwb3J0DQo+Pj5zb21lIGVuaGFuY2VkIGNhbGxpbmcgcGFydHkgaWRlbnRpZmlj YXRpb24gYW5kIGEgdmVyeSBsaW1pdGVkIGVmZm9ydCB0bw0KPj4+ZGVmaW5lIHRoZSBvYmplY3Qg YW5kIG9yIHRoZSBTVElSIHZhbGlkYXRpb24gZGF0YS4NCj4+Pg0KPj4+IEnCuW0gdmlvbGVudGx5 IG9wcG9zZWQgdG8gwrNlbmQgd29ybGQgaHVuZ2VywrIgV0fCuXMuDQo+Pj4NCj4+PiBJZiByZWdp c3RyaWVzIGNhbiBiZSB1c2VkIGZpbmUgYnV0IEkgY2VydGFpbmx5IHdhbnQgdG8gc2VlIGhvdyB0 aGlzDQo+Pj5jYW4gYmUgYWNjb21wbGlzaGVkIGluIGJpIGxhdGVyYWwgYWdyZWVtZW50cyBiZXR3 ZWVuIGNvbnNlbnRpbmcgc2VydmljZQ0KPj4+cHJvdmlkZXJzIGFuZCB3b3JrIHdpdGggQ1VBIHZl bmRvcnMgb24gaG93IHRoZSBkYXRhIGlzIGRpc3BsYXllZCBha2ENCj4+PkFwcGxlLCBTYW1zdW5n LCBNaWNyb3NvZnQgaW4gdGhlIGNvbnRleHQgb2YgYSBmb3JtYWwgbGlhaXNvbiB3aXRoIDNHUFAu DQo+Pj4gQ2VydGFpbmx5IHRoZSByZWxldmFuY2Ugb2YgQ05BTSsvQ05JVCBpbiBlbnRlcnByaXNl IGFuZCByZXNpZGVudGlhbA0KPj4+YWNjZXNzIG1hcmtldHMgaXMgaW1wb3J0YW50IGJ1dCB3ZSBh bGwga25vdyDCs01vbmV5IGlzIHRoZSBhbnN3ZXIgd2hhdA0KPj4+aXMgdGhlICBxdWVzdGlvbiAu LsKyDQo+Pj4NCj4+PiBJwrl2ZSBhc2tlZCBmb3IgdGltZSBpbiBEaXNwYXRjaCB0byBsb29rIGF0 IHRoZSBDTkFNL0NOSVQgaXNzdWUgYW5kDQo+Pj5yZXBvcnQgb24gdGhlIEpURiBvbiBOTkkuIEFz IHlvdSB3ZWxsIGtub3cgd2UgaGF2ZSBtYWRlIGNvbnNpZGVyYWJsZQ0KPj4+cHJvZ3Jlc3MuDQo+ Pj4NCj4+PiBMYXN0IHdlZWsgSSBnYXZlIGEgdGFsayBvbiB0aGlzIHRvIGEgcGFuZWwgdGhhdCBp bmNsdWRlZCBtYW55IG9mIG91cg0KPj4+ZnJpZW5kcyBhbW9uZyB0aGUgbmF0aW9uYWwgcmVndWxh dG9ycy4NCj4+Pg0KPj4+IGh0dHA6Ly9hcHBzLmZjYy5nb3YvZWNmcy9kb2N1bWVudC92aWV3P2lk PTYwMDAxMDMzMjE3DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gRnJvbTogIkhvbG1lcywgRGF2aWQgVyBb Q1RPXSIgPERhdmlkLkhvbG1lc0BzcHJpbnQuY29tPg0KPj4+IERhdGU6IFR1ZXNkYXksIEZlYnJ1 YXJ5IDI0LCAyMDE1IGF0IDU6MDYgUE0NCj4+PiBUbzogIlBldGVyc29uLCBKb24iIDxqb24ucGV0 ZXJzb25AbmV1c3Rhci5iaXo+LCAibW9kZXJuQGlldGYub3JnIg0KPj4+PG1vZGVybkBpZXRmLm9y Zz4NCj4+PiBTdWJqZWN0OiBSZTogW01vZGVybl0gZHJhZnQgY2hhcnRlcg0KPj4+DQo+Pj4gSm9u LA0KPj4+DQo+Pj4gVGhhbmsgeW91IGZvciB0aGUgd29yayBpbiBhc3NlbWJsaW5nIHRoaXMgZHJh ZnQgb2YgdGhlIGNoYXJ0ZXIgZm9yDQo+Pj5NT0RFUk4uDQo+Pj4NCj4+PiBXZSB3b3VsZCBsaWtl IHRvIHN1Z2dlc3Qgc29tZSBtaW5vciBjbGFyaWZpY2F0aW9ucyB0byB0aGUgYnVsbGV0cw0KPj4+ ZGVzY3JpYmluZyB0aGUgZGVsaXZlcmFibGVzLCB0byBhbGlnbiB0aGVtIHdpdGggdGhlIHN0YXRl bWVudCByZWdhcmRpbmcNCj4+PmZsZXhpYmlsaXR5IHRvIHN1cHBvcnQgdGhlIG5lZWRzIG9mIGRp ZmZlcmVudCByZWd1bGF0b3J5IHJlZ2ltZXMsICYNCj4+PnRodXMgdG8gZW5zdXJlIHRoYXQgaWYg cXVvdGVkIGFsb25lIHRoZXkgYXJlIG5vdCB0YWtlbiBvdXQgb2YgY29udGV4dDsNCj4+PmkuZS4g dGhlIGdyb3VwIHByb2R1Y3Qgd2lsbCBiZSB0aGUgcHJvdG9jb2xzIHRvIHN1cHBvcnQgdGhlIGFs bG9jYXRpb24NCj4+PmV0Yy4gYWN0aXZpdGllcywgJiBpdCB3b3VsZCBub3QgYXR0ZW1wdCB0byBk ZWZpbmUgdGhlIGFsbG9jYXRpb24NCj4+PnByb2Nlc3Nlcy4gIFdlIGFsc28gd291bGQgbGlrZSB0 aGUgY2hhcnRlciB0byBub3RlIHRoZSByZWxldmFudCB3b3JrDQo+Pj50aGF0IGhhcyBhbHJlYWR5 IGJlZW4gcGVyZm9ybWVkIGJ5IGJvdGggSUVURiAmIHRoZSBBVElTL1NJUCBGb3J1bSBKVEYsDQo+ Pj4mIGluY29ycG9yYXRlIHRoYXQgaW50byB0aGUgb3V0cHV0IGZyb20gdGhlIE1PREVSTiBXRyBh cyBhcHByb3ByaWF0ZS4NCj4+PlRoZXNlIGNoYW5nZXMvYWRkaXRpb25zIGFyZSBoYXZlIGJlZW4g YWRkZWQgdG8geW91ciB0ZXh0IGlubGluZSBiZWxvdy4NCj4+Pg0KPj4+IFdlIGFyZSBob3Bpbmcg dGhhdCB0aGUgTU9ERVJOIHNlc3Npb24gYXQgSUVURiM5MiB3aWxsIGhhdmUgcmVtb3RlDQo+Pj5h Y2Nlc3MsIHRvIGFsbG93IHBhcnRpY2lwYXRpb24gYnkgdGhvc2Ugb2YgdXMgdGhhdCBjYW5ub3Qg YXR0ZW5kIGluDQo+Pj5wZXJzb24gZHVlIHRvIG90aGVyIGNvbW1pdG1lbnRzIHRoYXQgd2Vlay4N Cj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4NCj4+PiBEYXZpZC9TcHJpbnQNCj4+Pg0KPj4+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj5fX19fX18NCj4+Pg0KPj4+IEZyb206IE1vZGVybiBbbWFpbHRvOm1vZGVy bi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGV0ZXJzb24sDQo+Pj5Kb24NCj4+PiBT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE1IDk6MTkgQU0NCj4+PiBUbzogbW9kZXJu QGlldGYub3JnDQo+Pj4gU3ViamVjdDogW01vZGVybl0gZHJhZnQgY2hhcnRlcg0KPj4+DQo+Pj4N Cj4+PiBBdCB0aGUgRGFsbGFzIElFVEYgbWVldGluZyBpbiBNYXJjaCwgd2UnZCBsaWtlIHRvIGdl dCB0b2dldGhlciBhbmQNCj4+PnRhbGsgYWJvdXQgd2hhdCBhIHdvcmtpbmcgZ3JvdXAgZm9yIE1P REVSTiBtaWdodCBsb29rIGxpa2UuIEFzIGFuDQo+Pj5pbml0aWFsIGlucHV0IHRvIHRoZSBkaXNj dXNzaW9uLCBhIGZldyBvZiB1cyBoYXZlIHB1dCB0b2dldGhlciBhDQo+Pj5wcm9wb3NlZCBjaGFy dGVyLiBXaGlsZSB0aGUgVGVSUSB3b3JrIHdhcyBwb3NpdGl2ZWx5IGV2YWx1YXRlZCBpbiB0aGUN Cj4+PkRJU1BBVENIIHByb2Nlc3MsIHdlIGZlZWwgdGhpcyBpcyBicm9hZGVyIGVub3VnaCBpbiBz Y29wZSB0byB3YXJyYW50DQo+Pj5pdHMgb3duIEJvRi4NCj4+Pg0KPj4+IENvbW1lbnRzIGFyZSB3 ZWxjb21lLCB0aGlzIGlzIGp1c3QgYSBzdGFydGluZyBwb2ludC4NCj4+Pg0KPj4+IC0tLS0tLQ0K Pj4+DQo+Pj4gTW9kZXJuIGNoYXJ0ZXIgdGV4dDoNCj4+Pg0KPj4+IFRoZSBNT0RFUk4gd29ya2lu ZyBncm91cCB3aWxsIGRlZmluZSBhIHNldCBvZiBJbnRlcm5ldC1iYXNlZA0KPj4+bWVjaGFuaXNt cyBmb3IgdGhlIHB1cnBvc2VzIG9mIG1hbmFnaW5nIGFuZCByZXNvbHZpbmcgdGVsZXBob25lIG51 bWJlcnMNCj4+PihUTnMpIGluIGFuIElQIGVudmlyb25tZW50LiAgRXhpc3RpbmcgbWVjaGFuaXNt cyBmb3IgdGhlc2UgcHVycG9zZXMNCj4+PmZhY2Ugb2Jzb2xlc2NlbmNlIGFzIHRoZSB2b2ljZSBj b21tdW5pY2F0aW9ucyBpbmZyYXN0cnVjdHVyZSBldm9sdmVzIHRvDQo+Pj5JUCB0ZWNobm9sb2d5 IGFuZCBuZXcgYXBwbGljYXRpb25zIGZvciBUTnMgYmVjb21lIHBvc3NpYmxlLiAgVGhlDQo+Pj50 cmFkaXRpb25hbCBtb2RlbCBvZiBhIFROIGhhdmluZyBhbiBhc3NvY2lhdGlvbiB0byBhIHNpbmds ZSBzZXJ2aWNlDQo+Pj5wcm92aWRlciBhbmQgYSBzaW5nbGUgYXBwbGljYXRpb24gaXMgYnJlYWtp bmcgZG93bi4gIEl0cyB1c2UgYXMgYQ0KPj4+bmV0d29yayBsb2NhdG9yIGlzIGdvaW5nIGF3YXks IGJ1dCBpdHMgdXNlIGFzIGFuIGlkZW50aWZpZXIgZm9yIGFuDQo+Pj5pbmRpdmlkdWFsIG9yIGFu IG9yZ2FuaXphdGlvbiB3aWxsIHJlbWFpbiBmb3Igc29tZSB0aW1lLiBEZXZpY2VzLA0KPj4+YXBw bGljYXRpb25zLCBhbmQgbmV0d29yayB0b29scyBpbmNyZWFzaW5nbHkgbmVlZCB0byBtYW5hZ2Ug VE5zLA0KPj4+aW5jbHVkaW5nIHJlcXVlc3RpbmcgYW5kIGFjcXVpcmluZyBUTiBkZWxlZ2F0aW9u cyBmcm9tIGF1dGhvcml0aWVzLg0KPj4+DQo+Pj4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZp bmUgYSBmcmFtZXdvcmsgZm9yIHRoZSByb2xlcyBhbmQgZnVuY3Rpb25zDQo+Pj5pbnZvbHZlZCBp biBtYW5hZ2luZyBhbmQgcmVzb2x2aW5nIFROcyBpbiBhbiBJUCBlbnZpcm9ubWVudC4gVGhpcw0K Pj4+aW5jbHVkZXMgYSBwcm90b2NvbCBtZWNoYW5pc20gZm9yIGFjcXVpcmluZyBUTnMsIHdoaWNo IHdpbGwgcHJvdmlkZSBhbg0KPj4+ZW5yb2xsbWVudCBwcm9jZXNzIGZvciB0aGUgaW5kaXZpZHVh bHMgYW5kIGVudGl0aWVzIHRoYXQgdXNlIGFuZCBtYW5hZ2UNCj4+PlROcy4gVE5zIG1heSBlaXRo ZXIgYmUgbWFuYWdlZCBpbiBhIGhpZXJhcmNoaWNhbCB0cmVlLCBvciBpbiBhDQo+Pj5kaXN0cmli dXRlZCBwZWVyLXRvLXBlZXIgYXJjaGl0ZWN0dXJlLiAgUHJpdmFjeSBvZiB0aGUgZW5yb2xsbWVu dCBkYXRhDQo+Pj5hbmQgc2VjdXJpdHkgb2YgdGhlIHJlc291cmNlIHdpbGwgYmUgcHJpbWFyeSBj b25zaWRlcmF0aW9ucy4NCj4+Pg0KPj4+IEFkZGl0aW9uYWxseSwgdGhlIHdvcmtpbmcgZ3JvdXAg d2lsbCBkZWxpdmVyIGEgcHJvdG9jb2wgbWVjaGFuaXNtIGZvcg0KPj4+cmVzb2x2aW5nIFROcyB3 aGljaCB3aWxsIGFsbG93IGVudGl0aWVzIHN1Y2ggYXMgc2VydmljZSBwcm92aWRlcnMsDQo+Pj5k ZXZpY2VzLCBhbmQgYXBwbGljYXRpb25zIHRvIGFjY2VzcyBkYXRhIHJlbGF0ZWQgdG8gVE5zLCBw b3NzaWJseQ0KPj4+aW5jbHVkaW5nIGNhbGxlciBuYW1lIGRhdGEgKENOQU0pLiAgTWFpbnRhaW5p bmcgcmVsaWFiaWxpdHksIHJlYWwgdGltZQ0KPj4+YXBwbGljYXRpb24gcGVyZm9ybWFuY2UsIHNl Y3VyaXR5IGFuZCBwcml2YWN5IGFyZSBwcmltYXJ5DQo+Pj5jb25zaWRlcmF0aW9ucy4gIFRoZSB3 b3JraW5nIGdyb3VwIHdpbGwgdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24NCj4+PmV4aXN0aW5nIElF VEYgd29yayBpbmNsdWRpbmcgRU5VTSwgU1BFRVJNSU5ULCBTVElSLCBhbmQgRFJJTktTLg0KPj4+ DQo+Pj4gVGhlIHdvcmsgb2YgdGhpcyBncm91cCBpcyBsaW1pdGVkIHRvIHNwZWNpZnlpbmcgYSBz b2x1dGlvbiBmb3IgVE5zIGFuZA0KPj4+Y292ZXJzIGFueSBzZXJ2aWNlIHRoYXQgY2FuIGJlIGFk ZHJlc3NlZCB1c2luZyBhIFROLiAgRXhwYW5kaW5nIHRoZQ0KPj4+d29yayB0byBvdGhlciBpZGVu dGlmaWVycyBpcyBvdXQgb2Ygc2NvcGUuICBTb2x1dGlvbnMgYW5kIG1lY2hhbmlzbXMNCj4+PmNy ZWF0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBiZSBmbGV4aWJsZSBlbm91Z2ggdG8gYWNj b21tb2RhdGUNCj4+PmRpZmZlcmVudCBwb2xpY2llcywgZS5nLiwgYnkgZGlmZmVyZW50IHJlZ3Vs YXRvcnkgYWdlbmNpZXMuDQo+Pj4NCj4+PiBUaGUgd29yayBncm91cCB3aWxsIGRlbGl2ZXIgdGhl IGZvbGxvd2luZzoNCj4+Pg0KPj4+IC0gICAgICAgICAgQW4gYXJjaGl0ZWN0dXJlIG92ZXJ2aWV3 IGRvY3VtZW50IHRoYXQgaW5jbHVkZXMgaGlnaCBsZXZlbA0KPj4+cmVxdWlyZW1lbnRzIGFuZCBz ZWN1cml0eS9wcml2YWN5IGNvbnNpZGVyYXRpb25zYnVpbHQgb24gdGhlIHdvcmsgb2YNCj4+PklF VEYgJiB0aGUgQVRJUy9TSVAgRm9ydW0gSlRGLCB0aGF0IGluY2x1ZGVkOg0KPj4+IG8gICBDYWxs IHJvdXRpbmcgYXJjaGl0ZWN0dXJlDQo+Pj4gbyAgIEludGVyLWNhcnJpZXIgTk5JDQo+Pj4gbyAg IENyeXB0b2dyYXBoaWNhbGx5LWVuYWJsZWQgQW50aS1zcG9vZmluZyAoU1RJUikNCj4+PiBvICAg RW5oYW5jZWQgQ2FsbGluZyBOYW1lIChDTklUL0NOQU0pDQo+Pj4gLSAgICAgICAgICBBIGRvY3Vt ZW50IGRlc2NyaWJpbmcgdGhlIHByb3RvY29scyB0byBzdXBwb3J0IGVucm9sbG1lbnQNCj4+PnBy b2Nlc3NlcyBmb3IgZXhpc3RpbmcgYW5kIG5ldyBUTnMgaW5jbHVkaW5nIGFueSBtb2RpZmljYXRp b25zIHRvDQo+Pj5tZXRhZGF0YSByZWxhdGVkIHRvIHRob3NlIFROcw0KPj4+IC0gICAgICAgICAg QSBkb2N1bWVudCBkZXNjcmliaW5nIHByb3RvY29sIG1lY2hhbmlzbXMgZm9yIGFjY2Vzc2luZw0K Pj4+Y29udGFjdCBpbmZvcm1hdGlvbiBhc3NvY2lhdGVkIHdpdGggZW5yb2xsbWVudHMNCj4+PiAt ICAgICAgICAgIEEgZG9jdW1lbnQgZGVzY3JpYmluZyBwcm90b2NvbCBtZWNoYW5pc21zIGZvciBy ZXNvbHZpbmcNCj4+PmluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gVE5zDQo+Pj4NCj4+PiAtDQo+Pj4N Cj4+Pg0KPj4+IFRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZv cm1hdGlvbiBpbnRlbmRlZCBmb3INCj4+PnRoZSBzb2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMp LiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVkLiBJZg0KPj4+eW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQNCj4+PmRl bGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIE1vZGVybiBtYWlsaW5nIGxpc3QNCj4+Pk1vZGVy bkBpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybg0K Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4g ZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+Pj4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBNb2Rlcm4gbWFpbGluZyBsaXN0DQo+ Pk1vZGVybkBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21vZGVybl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pl9fX19fX19fX19fX19fX19f Xw0KPj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+PiBkaXNwYXRjaEBpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZGlzcGF0Y2ggbWFpbGlu ZyBsaXN0DQo+ZGlzcGF0Y2hAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Rpc3BhdGNoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk1vZGVybiBtYWlsaW5nIGxpc3QNCk1vZGVybkBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tb2Rlcm4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRhaW4gU3ByaW50IHBy b3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJl Y2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= From nobody Mon Mar 9 18:15:43 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1271ACE4E for ; Mon, 9 Mar 2015 17:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-ETFU6_XVk0 for ; Mon, 9 Mar 2015 17:52:59 -0700 (PDT) Received: from SLCv-EXEDGE01.Sorenson.com (slcv-exedge01.sorenson.com [209.169.244.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3291AC41F for ; Mon, 9 Mar 2015 17:52:58 -0700 (PDT) Received: from SLC-EXHUB01.CORP.SRELAY.COM (10.20.38.90) by Mail.Sorenson.com (10.20.26.32) with Microsoft SMTP Server (TLS) id 14.1.379.0; Mon, 9 Mar 2015 18:52:02 -0600 Received: from SLC-EXMB03.CORP.SRELAY.COM ([fe80::a598:dee9:be8f:83c2]) by SLC-EXHUB01.CORP.SRELAY.COM ([::1]) with mapi id 14.01.0218.012; Mon, 9 Mar 2015 18:52:58 -0600 From: Grant Beckmann To: "io@vrs.io" , "fluffy@cisco.com" Thread-Topic: [VRS Interop] Re: [dispatch] New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt Thread-Index: AQHQWpQLuSzR4b1MJEeQBZaIxepkhZ0VHw+A///ECmA= Date: Tue, 10 Mar 2015 00:52:57 +0000 Message-ID: References: <6F2A17BA-AE0D-4370-A613-9E28B052AF16@cisco.com> <54FDE18C.7050800@alum.mit.edu> <18D75981C159A342A11F851B5CD2DECFCCBD4DF1@SLC-EXMB01.CORP.SRELAY.COM> In-Reply-To: <18D75981C159A342A11F851B5CD2DECFCCBD4DF1@SLC-EXMB01.CORP.SRELAY.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.200.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 09 Mar 2015 18:15:42 -0700 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] [VRS Interop] Re: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 00:53:03 -0000 VGhlIEZDQyBydWxlcyBhcmUgY2xlYXIuIFRoZSBJUCBBZGRyZXNzIG5lZWRzIHRvIGJlIHRoZSB1 c2VyJ3MgcHVibGljIGFkZHJlc3MgKGUuZy4gdGhlaXIgaG9tZSwgYnVzaW5lc3MpLiBObyBVUyBw cm92aWRlciBvZiBJUCBSZWxheSBzZXJ2aWNlcyBjYW4gYmUgY29tcGVuc2F0ZWQgZm9yIGEgY2Fs bCB3aXRob3V0IHRoZSBwdWJsaWMgYWRkcmVzcy4NCg0KLWdiDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IFNjb3QgQnJvb2tzYnkgW21haWx0bzpTQnJvb2tzYnlAc29yZW5z b24uY29tXSANClNlbnQ6IE1vbmRheSwgTWFyY2ggMDksIDIwMTUgNDoyNSBQTQ0KVG86IGZsdWZm eUBjaXNjby5jb20NCkNjOiBkaXNwYXRjaEBpZXRmLm9yZzsgUGF1bCBLeXppdmF0DQpTdWJqZWN0 OiBSRTogW1ZSUyBJbnRlcm9wXSBSZTogW2Rpc3BhdGNoXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWt5eml2YXQtZGlzcGF0Y2gtdHJzLWNhbGwtaW5mby1wdXJwb3NlLTAwLnR4 dA0KDQpDdWxsZW4sDQoNClRoZSBGQ0MgcnVsZXMgZm9yIFJlbGF5IHByb3ZpZGVycyBjYW4gYmUg Zm91bmQgYXQ6DQoNCmh0dHA6Ly93d3cuZWNmci5nb3YvY2dpLWJpbi9yZXRyaWV2ZUVDRlI/Z3A9 MSZTSUQ9NzZhZmU3NDA0Y2EwNTM5MTgzYjhlZTliNmQ3OGU4YmUmdHk9SFRNTCZoPUwmcj1QQVJU Jm49cHQ0Ny4zLjY0I3NlNDcuMy42NF8xNjA0DQoNClNwZWNpZmljYWxseSwgeW91IHdhbnQgdG8g bG9vayBhdCDCpzY0LjYwNCwgcGFyYWdyYXBoIChiKSgyKSh2aSkgKHF1b3RlZCBiZWxvdyAtIHdp dGggbXkgZW1waGFzaXMgb24gdGhlIHBhcmFncmFwaCkuDQoNCigyKSBDYWxsIGRhdGEgcmVxdWly ZWQgZnJvbSBhbGwgVFJTIHByb3ZpZGVycy4gSW4gYWRkaXRpb24gdG8gdGhlIGRhdGEgcmVxdWVz dGVkIGJ5IHBhcmFncmFwaCAoYykoNSkoaWlpKShDKSgxKSBvZiB0aGlzIHNlY3Rpb24sIFRSUyBw cm92aWRlcnMgc2Vla2luZyBjb21wZW5zYXRpb24gZnJvbSB0aGUgVFJTIEZ1bmQgc2hhbGwgc3Vi bWl0IHRoZSBmb2xsb3dpbmcgc3BlY2lmaWMgZGF0YSBhc3NvY2lhdGVkIHdpdGggZWFjaCBUUlMg Y2FsbCBmb3Igd2hpY2ggY29tcGVuc2F0aW9uIGlzIHNvdWdodDoNCiAgICAoaSkgVGhlIGNhbGwg cmVjb3JkIElEIHNlcXVlbmNlOw0KICAgIChpaSkgQ0EgSUQgbnVtYmVyOw0KICAgIChpaWkpIFNl c3Npb24gc3RhcnQgYW5kIGVuZCB0aW1lcyBub3RlZCBhdCBhIG1pbmltdW0gdG8gdGhlIG5lYXJl c3Qgc2Vjb25kOw0KICAgIChpdikgQ29udmVyc2F0aW9uIHN0YXJ0IGFuZCBlbmQgdGltZXMgbm90 ZWQgYXQgYSBtaW5pbXVtIHRvIHRoZSBuZWFyZXN0IHNlY29uZDsNCiAgICAodikgSW5jb21pbmcg dGVsZXBob25lIG51bWJlciBhbmQgSVAgYWRkcmVzcyAoaWYgY2FsbCBvcmlnaW5hdGVzIHdpdGgg YW4gSVAtYmFzZWQgZGV2aWNlKSBhdCB0aGUgdGltZSBvZiB0aGUgY2FsbDsNCiAgICAodmkpIE91 dGJvdW5kIHRlbGVwaG9uZSBudW1iZXIgKGlmIGNhbGwgdGVybWluYXRlcyB0byBhIHRlbGVwaG9u ZSkgYW5kIElQIGFkZHJlc3MgKGlmIGNhbGwgdGVybWluYXRlcyB0byBhbiBJUC1iYXNlZCBkZXZp Y2UpIGF0IHRoZSB0aW1lIG9mIGNhbGw7DQoqKih2aWkpIFRvdGFsIGNvbnZlcnNhdGlvbiBtaW51 dGVzOyAqKg0KICAgICh2aWlpKSBUb3RhbCBzZXNzaW9uIG1pbnV0ZXM7DQogICAgKGl4KSBUaGUg Y2FsbCBjZW50ZXIgKGJ5IGFzc2lnbmVkIGNlbnRlciBJRCBudW1iZXIpIHRoYXQgaGFuZGxlZCB0 aGUgY2FsbDsgYW5kDQogICAgKHgpIFRoZSBVUkwgYWRkcmVzcyB0aHJvdWdoIHdoaWNoIHRoZSBj YWxsIGlzIGhhbmRsZWQuDQogICAgKDMpIEFkZGl0aW9uYWwgY2FsbCBkYXRhIHJlcXVpcmVkIGZy b20gSW50ZXJuZXQtYmFzZWQgUmVsYXkgUHJvdmlkZXJzLiBJbiBhZGRpdGlvbiB0byB0aGUgZGF0 YSByZXF1aXJlZCBieSBwYXJhZ3JhcGggKGMpKDUpKGlpaSkoQykoMikgb2YgdGhpcyBzZWN0aW9u LCBJbnRlcm5ldC1iYXNlZCBSZWxheSBQcm92aWRlcnMgc2Vla2luZyBjb21wZW5zYXRpb24gZnJv bSB0aGUgRnVuZCBzaGFsbCBzdWJtaXQgc3BlZWQgb2YgYW5zd2VyIGNvbXBsaWFuY2UgZGF0YS4N CiAgICAoNCkgUHJvdmlkZXJzIHN1Ym1pdHRpbmcgY2FsbCByZWNvcmQgYW5kIHNwZWVkIG9mIGFu c3dlciBkYXRhIGluIGNvbXBsaWFuY2Ugd2l0aCBwYXJhZ3JhcGhzIChjKSg1KShpaWkpKEMpKDIp IGFuZCAoYykoNSkoaWlpKShDKSgzKSBvZiB0aGlzIHNlY3Rpb24gc2hhbGw6DQogICAgKGkpIEVt cGxveSBhbiBhdXRvbWF0ZWQgcmVjb3JkIGtlZXBpbmcgc3lzdGVtIHRvIGNhcHR1cmUgc3VjaCBk YXRhIHJlcXVpcmVkIHB1cnN1YW50IHRvIHBhcmFncmFwaCAoYykoNSkoaWlpKShDKSgyKSBvZiB0 aGlzIHNlY3Rpb24gZm9yIGVhY2ggVFJTIGNhbGwgZm9yIHdoaWNoIG1pbnV0ZXMgYXJlIHN1Ym1p dHRlZCB0byB0aGUgZnVuZCBhZG1pbmlzdHJhdG9yIGZvciBjb21wZW5zYXRpb247IGFuZA0KICAg IChpaSkgU3VibWl0IHN1Y2ggZGF0YSBlbGVjdHJvbmljYWxseSwgaW4gYSBzdGFuZGFyZGl6ZWQg Zm9ybWF0LiBGb3IgcHVycG9zZXMgb2YgdGhpcyBzdWJwYXJhZ3JhcGgsIGFuIGF1dG9tYXRlZCBy ZWNvcmQga2VlcGluZyBzeXN0ZW0gaXMgYSBzeXN0ZW0gdGhhdCBjYXB0dXJlcyBkYXRhIGluIGEg Y29tcHV0ZXJpemVkIGFuZCBlbGVjdHJvbmljIGZvcm1hdCB0aGF0IGRvZXMgbm90IGFsbG93IGh1 bWFuIGludGVydmVudGlvbiBkdXJpbmcgdGhlIGNhbGwgc2Vzc2lvbiBmb3IgZWl0aGVyIGNvbnZl cnNhdGlvbiBvciBzZXNzaW9uIHRpbWUuDQoNClRoYW5rcywNClNjb3QNCg0KU2NvdCBCcm9va3Ni eQ0KRW5naW5lZXJpbmcgRGlyZWN0b3IsIEFyY2hpdGVjdHVyZSBhbmQgSW5mcmFzdHJ1Y3R1cmUg U29yZW5zb24gQ29tbXVuaWNhdGlvbnMNCg0KDQo+IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdl IC0tLS0tLS0tDQo+IFN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgDQo+IGRyYWZ0LWt5eml2YXQtZGlzcGF0Y2gtdHJzLSBjYWxsLWluZm8tcHVycG9z ZS0wMC50eHQNCj4gRGF0ZTogTW9uLCA5IE1hciAyMDE1IDA4OjU4OjUxIC0wNjAwDQo+IEZyb206 IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGNpc2NvLmNvbT4NCj4gVG86IFBhdWwgS3l6aXZhdCA8 cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KPiBDQzogZGlzcGF0Y2hAaWV0Zi5vcmcgPGRpc3BhdGNo QGlldGYub3JnPg0KPiANCj4gDQo+IFRoZSBoZWFydCBvZiB0aGlzIGRyYWZ0IGdpdmVzIG1lLCBh aCAsIGhlYXJ0YnVybi4gVGhlIGlzc3VlIGlzDQo+IA0KPiAgICAgRm9yIGEgcHJvdmlkZXIgdG8g cmVjZWl2ZSByZWltYnVyc2VtZW50IGZvciBwcm92aWRpbmcgcmVsYXkgc2VydmljZQ0KPiAgICAg b24gYSBjYWxsIHRoZSBGQ0MgcmVxdWlyZXMgdGhhdCB0aGUgcHJvdmlkZXIgc3VwcGx5IGNhbGwg ZGV0YWlsDQo+ICAgICBpbmNsdWRpbmcgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIGRldmljZSB0aGUg VFJTIHVzZXIgaXMgdXNpbmcgZm9yIHRoZQ0KPiAgICAgY2FsbC4NCj4gDQo+IEZpcnN0IG9mIGFs bCB3aGF0IElQLiBUaGUgSVAgb2YgdGhlaXIgcGhvbmUgYmVoaW5kIHRoZWlyIGxpbmtzeXMgbmF0 Pw0KPiB0aGUgcHVibGljIElQIG9mIHRoZSBUVVJOIHNlcnZlcj8gdGhlIFZQTj8gTm9uZSBvZiB0 aGVzZSBhcmUgYSB2aWFibGUgDQo+IHdheSB0byBhdXRoZW50aWNhdGUgdGhhdCB0aGUgdXNlciBz aG91bGQgcmVjZWl2ZSB0aGlzIHNlcnZpY2VzIGFuZCB0aGUgDQo+IElFVEYgc2hvdWxkIGltcGxp Y2l0bHkgZW5kb3JzZSB0aGF0IHRoZXkgYXJlLiBGdXJ0aGVybW9yZSB0aGUgSUVURiANCj4gc2hv dWxkIGJlIGp1c3QgYXMgY29uY2VybmVkIGFib3V0IHByaXZhY3kgZm9yIHBlb3BsZSB1c2luZyBh IFZSUyBhcyANCj4gcGVvcGxlIHRoYXQgZG8gbm90IG5lZWQgb25lIGFuZCB0aGlzIHNvcnQgb2Yg cmV2ZWFsIG15IElQIGFkZHJlc3MgZXZlbiANCj4gaWYgSSB3YW50IGxvY2F0aW9uIHByaXZhY3kg aXMgbm90IGdyZWF0Lg0KPiANCj4gR2l2ZW4gdGhlIGxhY2sgb2YgYW55IHNlY3VyaXR5IGFyb3Vu ZCB0aGlzIGFuZCB0aGUgVFJTLTUgcmVxdWlyZW1lbnQsIA0KPiBJIHdvbmRlciBpZiBvbmUgY2Fu IGp1c3QgbG9vayBhdCB0aGUgdmlhIGxpc3QgYW5kIHVzZSB0aGF0Pw0KPiANCj4gSWYgd2UgZG8g cHJvY2VlZCB3aXRoIHRoaXMsIEkgZG9uJ3QgdGhpbmsgdGhlIGNhbGwtaW5mbyBpcyB0aGUgDQo+ IGFwcHJvcHJpYXRlIHBsYWNlIHRvIHB1dCBpdC4gSSB0aGluayBhIG5ldyBoZWFkZXIgd291bGQg YmUgdGhlIHJpZ2h0IHRoaW5nLg0KPiANCj4gQ2FuIHlvdSBwcm92aWRlIGEgcG9pbnRlciB0byB0 aGUgYWN0dWFsbHkgRkNDIHJ1bGVzIGZvciB0aGlzPw0KPiANCj4gSWYgdGhlIGdvYWwgaXMgcHVy ZWx5IHRvIGNoZWNrIHRoZSB1c2VyIGlzIGluIHRoZSBVUywgdGhlbiBoYXZpbmcgdGhlIA0KPiBW UlMgY2hlY2sgdGhhdCB0aGV5IHdlcmUgc2VuZGluZyBtZWRpYSB0byBhbiBJUCBhZGRyZXNzIGlu c2lkZSB0aGUgVVMgDQo+IHNlZW1zIGxpa2UgaXQgd291bGQgYmUgYSBiZXR0ZXIgc29sdXRpb24u DQo+IA0KPiBUaGFua3MNCj4gDQo+IA0KPiANCj4gPiBPbiBKYW4gMTMsIDIwMTUsIGF0IDk6MTQg QU0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCj4gPg0KPiA+ IERpc3BhdGNoZXJzOg0KPiA+DQo+ID4gSSBoYXZlIGp1c3Qgc3VibWl0dGVkIGEgbmV3IGRyYWZ0 IChzZWUgYmVsb3cpIHRoYXQgbmVlZHMgdG8gYmUgDQo+ID4gZGlzcGF0Y2hlZC4gSXQNCj4gZGVm aW5lcyBhIG5ldyBDYWxsLUluZm8gJ3B1cnBvc2UnIHBhcmFtZXRlciB2YWx1ZS4NCj4gPg0KPiA+ IFRoZSBpbnRlbmRlZCBhdWRpZW5jZSBmb3IgdGhpcyBkcmFmdCBpcyBxdWl0ZSBsaW1pdGVkIC0g dG8gdGhlIA0KPiA+IHByb3ZpZGVycyBvZiB0aGUNCj4gVmlkZW8gUmVsYXkgU2VydmljZSBpbiB0 aGUgVVMsIGFuZCB0byB0aGUgRkNDIHRoYXQgc3BvbnNvcnMgdGhhdCANCj4gc2VydmljZS4gVGhl IEludHJvIHNlY3Rpb24gZXhwbGFpbnMgdGhpcy4NCj4gPg0KPiA+IEknbSBob3BpbmcgdGhpcyBj YW4gYmUgZGlzcGF0Y2hlZCB3aXRob3V0IGNhdXNpbmcgYSBsb3Qgb2YgYm90aGVyIGZvciBhbnli b2R5Lg0KPiBJIGRvbid0IGFudGljaXBhdGUgdGhhdCBpdCBuZWVkcyB0aW1lIGluIERhbGxhcy4g SUlVQyBkb2N1bWVudHMgb2YgDQo+IHRoaXMgc29ydCBhcmUgb2Z0ZW4gQUQgc3BvbnNvcmVkLg0K PiA+DQo+ID4gCVRoYW5rcywNCj4gPiAJUGF1bA0KPiA+DQo+ID4gLS0tLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLS0tLQ0KPiA+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgDQo+ID4gZHJhZnQta3l6aXZhdC1kaXNwYXRjaC10cnMtY2FsbC1pbmZvLQ0KPiBwdXJwb3Nl LTAwLnR4dA0KPiA+IERhdGU6IFR1ZSwgMTMgSmFuIDIwMTUgMDc6NDY6NDcgLTA4MDANCj4gPiBG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPiBUbzogUGF1bCBLeXppdmF0IDxwa3l6 aXZhdEBhbHVtLm1pdC5lZHU+LCAgICAgICAgIlBhdWwgS3l6aXZhdCINCj4gPHBreXppdmF0QGFs dW0ubWl0LmVkdT4NCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIA0KPiA+IGRy YWZ0LWt5eml2YXQtZGlzcGF0Y2gtdHJzLWNhbGwtaW5mby1wdXJwb3NlLTAwLnR4dA0KPiA+IGhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGF1bCBLeXppdmF0IGFuZCBwb3N0ZWQg dG8gdGhlIA0KPiA+IElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6CQlkcmFmdC1reXpp dmF0LWRpc3BhdGNoLXRycy1jYWxsLWluZm8tcHVycG9zZQ0KPiA+IFJldmlzaW9uOgkwMA0KPiA+ IFRpdGxlOgkJVGVsZWNvbW11bmljYXRpb25zIFJlbGF5IFNlcnZpY2UgUHVycG9zZSBmb3IgdGhl IENhbGwtSW5mbw0KPiBIZWFkZXIgRmllbGQgaW4gdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90 b2NvbCAoU0lQKQ0KPiA+IERvY3VtZW50IGRhdGU6CTIwMTUtMDEtMTMNCj4gPiBHcm91cDoJCUlu ZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+IFBhZ2VzOgkJNA0KPiA+IFVSTDogDQo+ID4gaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta3l6aXZhdC1kaXNwYXRjaC10cnMt Y2FsbC0NCj4gPiBpbmZvLQ0KPiBwdXJwb3NlLTAwLnR4dA0KPiA+IFN0YXR1czogDQo+ID4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta3l6aXZhdC1kaXNwYXRjaC10cnMt Y2FsbC1pbmYNCj4gPiBvLQ0KPiBwdXJwb3NlLw0KPiA+IEh0bWxpemVkOiANCj4gPiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1reXppdmF0LWRpc3BhdGNoLXRycy1jYWxsLWluZm8t DQo+IHB1cnBvc2UtMDANCj4gPg0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICBUaGlzIGRvY3Vt ZW50IGRlZmluZXMgYW5kIHJlZ2lzdGVycyBhIHZhbHVlIG9mICJvcmlnaW5hbC1pZGVudGl0eSIN Cj4gPiAgIGZvciB0aGUgInB1cnBvc2UiIGhlYWRlciBmaWVsZCBwYXJhbWV0ZXIgb2YgdGhlIENh bGwtSW5mbyBoZWFkZXINCj4gPiAgIGZpZWxkIGluIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJv dG9jb2wgKFNJUCkuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4gPiBzdWJt aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4NCj4gPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gPiBkaXNwYXRjaEBpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4g Pg0KPiANCj4gDQo+IA0KPiANCj4gLS0NCj4gWW91IHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBiZWNh dXNlIHlvdSBhcmUgc3Vic2NyaWJlZCB0byB0aGUgR29vZ2xlIA0KPiBHcm91cHMgIlZSUyBJbnRl cm9wIiBncm91cC4NCj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGdyb3VwIGFuZCBzdG9wIHJl Y2VpdmluZyBlbWFpbHMgZnJvbSBpdCwgc2VuZCANCj4gYW4gZW1haWwgdG8gaW8rdW5zdWJzY3Jp YmVAdnJzLmlvLg0KPiBUbyBwb3N0IHRvIHRoaXMgZ3JvdXAsIHNlbmQgZW1haWwgdG8gaW9AdnJz LmlvLg0KPiBWaXNpdCB0aGlzIGdyb3VwIGF0IGh0dHA6Ly9ncm91cHMuZ29vZ2xlLmNvbS9hL3Zy cy5pby9ncm91cC9pby8uDQoNCi0tDQpZb3UgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGJlY2F1c2Ug eW91IGFyZSBzdWJzY3JpYmVkIHRvIHRoZSBHb29nbGUgR3JvdXBzICJWUlMgSW50ZXJvcCIgZ3Jv dXAuDQpUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgZ3JvdXAgYW5kIHN0b3AgcmVjZWl2aW5nIGVt YWlscyBmcm9tIGl0LCBzZW5kIGFuIGVtYWlsIHRvIGlvK3Vuc3Vic2NyaWJlQHZycy5pby4NClRv IHBvc3QgdG8gdGhpcyBncm91cCwgc2VuZCBlbWFpbCB0byBpb0B2cnMuaW8uDQpWaXNpdCB0aGlz IGdyb3VwIGF0IGh0dHA6Ly9ncm91cHMuZ29vZ2xlLmNvbS9hL3Zycy5pby9ncm91cC9pby8uDQo= From nobody Tue Mar 10 11:37:57 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A6A1A87EB for ; Tue, 10 Mar 2015 11:37:54 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 ZYKuuZvSH3xm for ; Tue, 10 Mar 2015 11:37:50 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (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 71F431A87E9 for ; Tue, 10 Mar 2015 11:37:50 -0700 (PDT) Received: by qcvp6 with SMTP id p6so4287993qcv.1 for ; Tue, 10 Mar 2015 11:37:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zknqNaMASydt02EO+HgWESLMPHuLGANYcqa+KKKrnKc=; b=lcNSQXYcI+wnKGHN74eja4I88uweDgduCKrWSIQUfqvBvHP2viBh2go5f6cYv5I/Hn onSH5TSeuBEAfzWXsUT5a99KtevqS+qadDDwnh/9hEOvE9jQW5dVIZrdP+SS0aMZh95L YVR+2eznyq2W8rFJULz6Ow7gRWiaumVtRwyiu+PAnvrLtWjsD/ge/DBVGw/hprlVQIXE dIYdvrhtr1CHPnegtkC/FJPQG5eWTTcIKhFQL/f25nVZLZhWSBIhq/WaOjJGu3jfFfHO REdq7whuqyacJAyA1FEfAthXkSCAv1+Mq+3JCa2p29aOfMKe+iNsHlMDrsjU00t4XycR GpAQ== X-Gm-Message-State: ALoCoQllEyAuWct4+T6hIN3vERR08jqElqmxJjXNFbr8ognSniy1+LA3HELtp4cdxKsEK2UEIH0X X-Received: by 10.55.48.15 with SMTP id w15mr68396702qkw.1.1426012669486; Tue, 10 Mar 2015 11:37:49 -0700 (PDT) Received: from [10.0.2.164] (c-69-247-98-104.hsd1.pa.comcast.net. [69.247.98.104]) by mx.google.com with ESMTPSA id g34sm924235qgd.0.2015.03.10.11.37.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Mar 2015 11:37:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2081\)) From: Chris Wendt In-Reply-To: Date: Tue, 10 Mar 2015 14:37:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <95353295-617C-4920-A581-4D0DFA02EDE4@chriswendt.net> References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> To: Richard Shockey X-Mailer: Apple Mail (2.2081) Archived-At: Cc: Cullen Jennings , cnit@ietf.org, "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:37:54 -0000 I agree that this would be useful just from the standpoint that if = service providers are going to implement in-band signing of caller-id, = would quite make sense to provide a better payload for delivering = additional and/or more useful calling party information along with = signing it as well. -Chris > On Mar 9, 2015, at 3:18 PM, Richard Shockey = wrote: >=20 >=20 > The first order issue is properly defining what this looks like in SIP = and > where in the headers it should reside. There is ample evidence that = any > number of other SDO are looking at this and without some proper > standardization there will be no interoperability at all especially = even > for STIR validation data at the CUA and IMHO doing nothing is not a = viable > option. The basic FROM and PAI usage is not helpful. >=20 > We are all aware of how smart phones work. This is principally about > sessions that would originate outside a select number of phone book > entries and some display of whether that information has been = validated > though we don=C4=85t have to define policy at this stage and frankly I = don=C4=85t > think the IETF should try any more than it could try and establish the > business model for how this would deploy. >=20 > The purpose here is simply adding more information about who = originated > the session so the called party has more information than they = currently > have. We already have enough bad actors as it is impersonating tax > authorities, banks, health care professionals and other governmental > entities. The purpose is to try and bound those problems to a = manageable > level. There is no silver bullet here. >=20 > I would appreciate any suggestions on charter text if you have them. >=20 >=20 >=20 > =E2=80=B9=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 >=20 >=20 >=20 > On 3/9/15, 11:10 AM, "Cullen Jennings" wrote: >=20 >>=20 >> On the particular CNAM like topic ... >>=20 >> I'm not keen on moving forward with something like this unless we can >> show the trust and human factors issues is an engineering problem not = a >> research problem. We have seen the difficulty with human readable = names >> in SPAM. Particularly when using UTF-8, how do we stop bad actor = getting >> names that look the same as someone they wish to impersonate? Who = will >> validate the names and issue some sort of trust token that says I can = use >> "Cullen Jennings" or whatever. Who else can use that name and what = about >> names visually similar to it. >>=20 >> On the flip side we are seeing most smart phones take the incoming = phone >> number, and look it up the personal address book of the user and = display >> the name that the user of the smartphone assigned. We are seeing >> enterprise phones that do a similar things using the users social >> networks as well as personal address book. >>=20 >> What would be bad is phone display a display name that some how = claimed >> to be trustable but was not. That would be worse that the current >> situation. Perhaps people have a good way to solve this in mind but = I'm >> not seeing that that is. >>=20 >> Cullen (with my individual contribute hat on of course) >>=20 >>=20 >>=20 >>> On Feb 25, 2015, at 10:05 AM, Richard Shockey >>> wrote: >>>=20 >>>=20 >>> Thanks Martin .. This is my very raw first cut at a charter. Its >>> hopefully simple and straight forward. >>>=20 >>> Send me any edits etc. >>>=20 >>> ***** >>>=20 >>> CNIT Charter [Calling Name Identity Trust] >>>=20 >>> WG Chairs TBD: >>>=20 >>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII = Characters >>> of information associated with a specific E.164 calling party number = in >>> the Public Switched Telephone Network [PSTN]. In the PSTN this data = is >>> sent by the originating network only at the specific request of the >>> terminating network via a SS7 Transaction Application Part [TCAP] >>> response message. In the Session Initiation Protocol [SIP] this >>> information can be inserted into the FROM: part of the originating >>> INVITE message or by other means. >>>=20 >>> As with the originating source telephone number, this data can be >>> altered in transit creating a variety of malicious abuses similar to = the >>> ones identified by the IETF STIR working group. >>>=20 >>> The purpose of the CNIT working group will be to define a data >>> structure, a new SIP header or repurpose an existing SIP header to = carry >>> an advanced form of CNAM as well as information from a STIR = Validation >>> Authority. The purpose of this work is to present to the SIP called >>> party trusted information from the calling party in order that the >>> called party make a more reasoned and informed judgment on whether = to >>> accept the INVITE or not. >>>=20 >>> The working group will not invalidate any existing SIP mechanism for >>> anonymous calling. >>>=20 >>> The working group will, to the best of its ability, reuse existing = IETF >>> protocols. >>>=20 >>> Full Internationalization of the Calling Name Identity Trust data >>> object(s) is a requirement. >>>=20 >>> The working group will closely work with the IETF STIR working group >>>=20 >>> The working group will immediately liaison with 3GPP SA-1 in order = to >>> coordinate efforts. >>>=20 >>> The working group will coordinate with National Numbering = Authorities >>> and National Regulatory Authorities as needed. >>>=20 >>> The working group will deliver the flowing. >>>=20 >>> =E2=82=AC A problem statement and requirements detailing the = current deployment >>> environment and situations that motivate work on Calling Name = Identity >>> Trust. >>> =E2=82=AC Define either a new SIP header or document a repurpose = of an SIP >>> existing header for Calling Name Identify Trust data >>> =E2=82=AC Define a data model for the Calling Name Identity Trust = object (s) >>> which may include various forms of multimedia data >>> =E2=82=AC Deliver an analysis of privacy implications of the = proposed Calling >>> Name Identity Trust mechanism. >>>=20 >>>=20 >>> Milestones: >>>=20 >>>=20 >>> =E2=80=B9=20 >>> Richard Shockey >>> Shockey Consulting LLC >>> Chairman of the Board SIP Forum >>> www.shockey.us >>> www.sipforum.org >>> richardshockey.us >>> Skype-Linkedin-Facebook rshockey101 >>> PSTN +1 703-593-2683 >>>=20 >>>=20 >>> From: "DOLLY, MARTIN C" >>> Date: Tuesday, February 24, 2015 at 9:02 PM >>> To: Richard Shockey >>> Cc: "Holmes, David W [CTO]" , >>> "dispatch@ietf.org" , "modern@ietf.org" >>> , "Peterson, Jon" >>> Subject: Re: [Modern] [dispatch] draft charter >>>=20 >>> I support Richard on this >>>=20 >>> Martin Dolly >>> Lead Member of Technical Staff >>> Core & Gov't/Regulatory Standards >>> AT&T Standards and >>> Industry Alliances >>> +1-609-903-3390 >>> Sent from my iPhone >>>=20 >>> On Feb 24, 2015, at 6:36 PM, Richard Shockey = wrote: >>>=20 >>>>=20 >>>> Excellent points David. >>>>=20 >>>> My concern here is charter overreach. I really want to keep = CNAM+/CNIT >>>> out of this. IMHO that is a very separate and highly focused = effort to >>>> define both the modification of the SIP headers necessary to = support >>>> some enhanced calling party identification and a very limited = effort to >>>> define the object and or the STIR validation data. >>>>=20 >>>> I=C4=85m violently opposed to =C5=82end world hunger=CB=9B WG=C4=85s.= >>>>=20 >>>> If registries can be used fine but I certainly want to see how this >>>> can be accomplished in bi lateral agreements between consenting = service >>>> providers and work with CUA vendors on how the data is displayed = aka >>>> Apple, Samsung, Microsoft in the context of a formal liaison with = 3GPP. >>>> Certainly the relevance of CNAM+/CNIT in enterprise and residential >>>> access markets is important but we all know =C5=82Money is the = answer what >>>> is the question ..=CB=9B >>>>=20 >>>> I=C4=85ve asked for time in Dispatch to look at the CNAM/CNIT issue = and >>>> report on the JTF on NNI. As you well know we have made = considerable >>>> progress. >>>>=20 >>>> Last week I gave a talk on this to a panel that included many of = our >>>> friends among the national regulators. >>>>=20 >>>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>>=20 >>>>=20 >>>>=20 >>>> From: "Holmes, David W [CTO]" >>>> Date: Tuesday, February 24, 2015 at 5:06 PM >>>> To: "Peterson, Jon" , "modern@ietf.org" >>>> >>>> Subject: Re: [Modern] draft charter >>>>=20 >>>> Jon,=20 >>>>=20 >>>> Thank you for the work in assembling this draft of the charter for >>>> MODERN. >>>>=20 >>>> We would like to suggest some minor clarifications to the bullets >>>> describing the deliverables, to align them with the statement = regarding >>>> flexibility to support the needs of different regulatory regimes, & >>>> thus to ensure that if quoted alone they are not taken out of = context; >>>> i.e. the group product will be the protocols to support the = allocation >>>> etc. activities, & it would not attempt to define the allocation >>>> processes. We also would like the charter to note the relevant = work >>>> that has already been performed by both IETF & the ATIS/SIP Forum = JTF, >>>> & incorporate that into the output from the MODERN WG as = appropriate. >>>> These changes/additions are have been added to your text inline = below. >>>>=20 >>>> We are hoping that the MODERN session at IETF#92 will have remote >>>> access, to allow participation by those of us that cannot attend in >>>> person due to other commitments that week. >>>>=20 >>>> Regards,=20 >>>>=20 >>>> David/Sprint=20 >>>>=20 >>>> = ________________________________________________________________________ >>>> ______ >>>>=20 >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of = Peterson, >>>> Jon >>>> Sent: Wednesday, February 11, 2015 9:19 AM >>>> To: modern@ietf.org >>>> Subject: [Modern] draft charter >>>>=20 >>>>=20 >>>> At the Dallas IETF meeting in March, we'd like to get together and >>>> talk about what a working group for MODERN might look like. As an >>>> initial input to the discussion, a few of us have put together a >>>> proposed charter. While the TeRQ work was positively evaluated in = the >>>> DISPATCH process, we feel this is broader enough in scope to = warrant >>>> its own BoF. >>>>=20 >>>> Comments are welcome, this is just a starting point. >>>>=20 >>>> ------ >>>>=20 >>>> Modern charter text: >>>>=20 >>>> The MODERN working group will define a set of Internet-based >>>> mechanisms for the purposes of managing and resolving telephone = numbers >>>> (TNs) in an IP environment. Existing mechanisms for these purposes >>>> face obsolescence as the voice communications infrastructure = evolves to >>>> IP technology and new applications for TNs become possible. The >>>> traditional model of a TN having an association to a single service >>>> provider and a single application is breaking down. Its use as a >>>> network locator is going away, but its use as an identifier for an >>>> individual or an organization will remain for some time. Devices, >>>> applications, and network tools increasingly need to manage TNs, >>>> including requesting and acquiring TN delegations from authorities. >>>>=20 >>>> The working group will define a framework for the roles and = functions >>>> involved in managing and resolving TNs in an IP environment. This >>>> includes a protocol mechanism for acquiring TNs, which will provide = an >>>> enrollment process for the individuals and entities that use and = manage >>>> TNs. TNs may either be managed in a hierarchical tree, or in a >>>> distributed peer-to-peer architecture. Privacy of the enrollment = data >>>> and security of the resource will be primary considerations. >>>>=20 >>>> Additionally, the working group will deliver a protocol mechanism = for >>>> resolving TNs which will allow entities such as service providers, >>>> devices, and applications to access data related to TNs, possibly >>>> including caller name data (CNAM). Maintaining reliability, real = time >>>> application performance, security and privacy are primary >>>> considerations. The working group will take into consideration >>>> existing IETF work including ENUM, SPEERMINT, STIR, and DRINKS. >>>>=20 >>>> The work of this group is limited to specifying a solution for TNs = and >>>> covers any service that can be addressed using a TN. Expanding the >>>> work to other identifiers is out of scope. Solutions and = mechanisms >>>> created by the working group will be flexible enough to accommodate >>>> different policies, e.g., by different regulatory agencies. >>>>=20 >>>> The work group will deliver the following: >>>>=20 >>>> - An architecture overview document that includes high = level >>>> requirements and security/privacy considerationsbuilt on the work = of >>>> IETF & the ATIS/SIP Forum JTF, that included: >>>> o Call routing architecture >>>> o Inter-carrier NNI >>>> o Cryptographically-enabled Anti-spoofing (STIR) >>>> o Enhanced Calling Name (CNIT/CNAM) >>>> - A document describing the protocols to support = enrollment >>>> processes for existing and new TNs including any modifications to >>>> metadata related to those TNs >>>> - A document describing protocol mechanisms for accessing >>>> contact information associated with enrollments >>>> - A document describing protocol mechanisms for resolving >>>> information related to TNs >>>>=20 >>>> - =20 >>>>=20 >>>>=20 >>>> This e-mail may contain Sprint proprietary information intended for >>>> the sole use of the recipient(s). Any use by others is prohibited. = If >>>> you are not the intended recipient, please contact the sender and >>>> delete all copies of the message. >>>> _______________________________________________ Modern mailing list >>>> Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ Modern mailing list >>> Modern@ietf.org=20 >>> = https://www.ietf.org/mailman/listinfo/modern_____________________________ >>> __________________ >>> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Mar 10 11:53:46 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF611A8844 for ; Tue, 10 Mar 2015 11:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg52F9Fv9gig for ; Tue, 10 Mar 2015 11:53:35 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 477E31A8842 for ; Tue, 10 Mar 2015 11:53:34 -0700 (PDT) Received: (qmail 1140 invoked by uid 0); 10 Mar 2015 18:53:27 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 10 Mar 2015 18:53:27 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id 1utL1q0161MNPNq01utPJ8; Tue, 10 Mar 2015 12:53:25 -0600 X-Authority-Analysis: v=2.1 cv=d8xml3TE c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=emO1SXQWCLwA:10 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=AUd_NHdVAAAA:8 a=zQP7CpKOAAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=uyN4U3GdkdK59S0vqX4A:9 a=XJ18KnzTEAI2-tP5:21 a=-jexJdo8py0oMAw_:21 a=QEXdDO2ut3YA:10 a=DzjOOp_o1eYA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=8+Cw8eLnCDBF077DqKf2T26XpI/TBEpN8nf/of9gOYE=; b=E8SqcLradbfkReijAN3+muHs9Gt/l0XNNAbIcnXHtt90irYKT5Qfr1zkbw0t14O4Mana/Yoq/SPIAim8g8kVtWqIjGjXwLO+ReRevj7XyaQIrLltqnTpKe2thg+/abuE; Received: from [108.56.131.201] (port=49276 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YVPHO-0008RI-Cs; Tue, 10 Mar 2015 12:53:22 -0600 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 10 Mar 2015 14:53:17 -0400 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Message-ID: Thread-Topic: [dispatch] CNIT and Modern Charter References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:53:43 -0000 Exactly=E2=80=A6 studying the trust models are perfectly appropriate. Obviously the calling party data can come from different sources though I suspect in its earliest models it comes from the originating service provider through the SIP signaling mechanism to the terminating CUA. Especially in the VoLTE case. Enterprise to Enterprise would clearly be different. Certainly 3rd party databases could be involved in some way. I would remind folks that the rationale for this is consumers and National Regulators are NOT HAPPY AT ALL with the current state of how calling party data is presented to the consumer. STIR in and of itself is not enough. This is ultimately a consumer protection issue. On 3/9/15, 6:25 PM, "Gorman, Pierce A [CTO]" wrote: >I don't have any useful charter text. >I agree that the IETF should not propose business models, but it seems >important to consider trust model(s) to see if it/they drive protocol >considerations. >We could start with listing assumptions. I'll start by listing two. > 1) I assume there would be multiple authorities and multiple levels >of trust. > 2) I assume there are international tradename, and trademark and the >aforementioned UTF-8 international character code spoofing considerations. > > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > >-----Original Message----- >From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard Shockey >Sent: March 09, 2015 2:18 PM >To: Cullen Jennings; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org >Subject: Re: [Modern] [dispatch] CNIT and Modern Charter > > >The first order issue is properly defining what this looks like in SIP >and where in the headers it should reside. There is ample evidence that >any number of other SDO are looking at this and without some proper >standardization there will be no interoperability at all especially even >for STIR validation data at the CUA and IMHO doing nothing is not a >viable option. The basic FROM and PAI usage is not helpful. > >We are all aware of how smart phones work. This is principally about >sessions that would originate outside a select number of phone book >entries and some display of whether that information has been validated >though we don=C2=B9t have to define policy at this stage and frankly I don=C2=B9t >think the IETF should try any more than it could try and establish the >business model for how this would deploy. > >The purpose here is simply adding more information about who originated >the session so the called party has more information than they currently >have. We already have enough bad actors as it is impersonating tax >authorities, banks, health care professionals and other governmental >entities. The purpose is to try and bound those problems to a manageable >level. There is no silver bullet here. > >I would appreciate any suggestions on charter text if you have them. > > > >=E2=80=B9 >Richard Shockey >Shockey Consulting LLC >Chairman of the Board SIP Forum >www.shockey.us >www.sipforum.org >richardshockey.us >Skype-Linkedin-Facebook rshockey101 >PSTN +1 703-593-2683 > > > > > >On 3/9/15, 11:10 AM, "Cullen Jennings" wrote: > >> >>On the particular CNAM like topic ... >> >>I'm not keen on moving forward with something like this unless we can >>show the trust and human factors issues is an engineering problem not a >>research problem. We have seen the difficulty with human readable names >>in SPAM. Particularly when using UTF-8, how do we stop bad actor getting >>names that look the same as someone they wish to impersonate? Who will >>validate the names and issue some sort of trust token that says I can use >>"Cullen Jennings" or whatever. Who else can use that name and what about >>names visually similar to it. >> >>On the flip side we are seeing most smart phones take the incoming phone >>number, and look it up the personal address book of the user and display >>the name that the user of the smartphone assigned. We are seeing >>enterprise phones that do a similar things using the users social >>networks as well as personal address book. >> >>What would be bad is phone display a display name that some how claimed >>to be trustable but was not. That would be worse that the current >>situation. Perhaps people have a good way to solve this in mind but I'm >>not seeing that that is. >> >>Cullen (with my individual contribute hat on of course) >> >> >> >>> On Feb 25, 2015, at 10:05 AM, Richard Shockey >>>wrote: >>> >>> >>> Thanks Martin .. This is my very raw first cut at a charter. Its >>>hopefully simple and straight forward. >>> >>> Send me any edits etc. >>> >>> ***** >>> >>> CNIT Charter [Calling Name Identity Trust] >>> >>> WG Chairs TBD: >>> >>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters >>>of information associated with a specific E.164 calling party number in >>>the Public Switched Telephone Network [PSTN]. In the PSTN this data is >>>sent by the originating network only at the specific request of the >>>terminating network via a SS7 Transaction Application Part [TCAP] >>>response message. In the Session Initiation Protocol [SIP] this >>>information can be inserted into the FROM: part of the originating >>>INVITE message or by other means. >>> >>> As with the originating source telephone number, this data can be >>>altered in transit creating a variety of malicious abuses similar to the >>>ones identified by the IETF STIR working group. >>> >>> The purpose of the CNIT working group will be to define a data >>>structure, a new SIP header or repurpose an existing SIP header to carry >>>an advanced form of CNAM as well as information from a STIR Validation >>>Authority. The purpose of this work is to present to the SIP called >>>party trusted information from the calling party in order that the >>>called party make a more reasoned and informed judgment on whether to >>>accept the INVITE or not. >>> >>> The working group will not invalidate any existing SIP mechanism for >>>anonymous calling. >>> >>> The working group will, to the best of its ability, reuse existing IETF >>>protocols. >>> >>> Full Internationalization of the Calling Name Identity Trust data >>>object(s) is a requirement. >>> >>> The working group will closely work with the IETF STIR working group >>> >>> The working group will immediately liaison with 3GPP SA-1 in order to >>>coordinate efforts. >>> >>> The working group will coordinate with National Numbering Authorities >>>and National Regulatory Authorities as needed. >>> >>> The working group will deliver the flowing. >>> >>> =E2=82=ACA problem statement and requirements detailing the current deploymen= t >>>environment and situations that motivate work on Calling Name Identity >>>Trust. >>> =E2=82=ACDefine either a new SIP header or document a repurpose of an SIP >>>existing header for Calling Name Identify Trust data >>> =E2=82=ACDefine a data model for the Calling Name Identity Trust object (s) >>>which may include various forms of multimedia data >>> =E2=82=ACDeliver an analysis of privacy implications of the proposed Calling >>>Name Identity Trust mechanism. >>> >>> >>> Milestones: >>> >>> >>> =E2=80=B9 >>> Richard Shockey >>> Shockey Consulting LLC >>> Chairman of the Board SIP Forum >>> www.shockey.us >>> www.sipforum.org >>> richardshockey.us >>> Skype-Linkedin-Facebook rshockey101 >>> PSTN +1 703-593-2683 >>> >>> >>> From: "DOLLY, MARTIN C" >>> Date: Tuesday, February 24, 2015 at 9:02 PM >>> To: Richard Shockey >>> Cc: "Holmes, David W [CTO]" , >>>"dispatch@ietf.org" , "modern@ietf.org" >>>, "Peterson, Jon" >>> Subject: Re: [Modern] [dispatch] draft charter >>> >>> I support Richard on this >>> >>> Martin Dolly >>> Lead Member of Technical Staff >>> Core & Gov't/Regulatory Standards >>> AT&T Standards and >>> Industry Alliances >>> +1-609-903-3390 >>> Sent from my iPhone >>> >>> On Feb 24, 2015, at 6:36 PM, Richard Shockey >>>wrote: >>> >>>> >>>> Excellent points David. >>>> >>>> My concern here is charter overreach. I really want to keep CNAM+/CNIT >>>>out of this. IMHO that is a very separate and highly focused effort to >>>>define both the modification of the SIP headers necessary to support >>>>some enhanced calling party identification and a very limited effort to >>>>define the object and or the STIR validation data. >>>> >>>> I=C2=B9m violently opposed to =C2=B3end world hunger=C2=B2 WG=C2=B9s. >>>> >>>> If registries can be used fine but I certainly want to see how this >>>>can be accomplished in bi lateral agreements between consenting service >>>>providers and work with CUA vendors on how the data is displayed aka >>>>Apple, Samsung, Microsoft in the context of a formal liaison with 3GPP. >>>> Certainly the relevance of CNAM+/CNIT in enterprise and residential >>>>access markets is important but we all know =C2=B3Money is the answer what >>>>is the question ..=C2=B2 >>>> >>>> I=C2=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and >>>>report on the JTF on NNI. As you well know we have made considerable >>>>progress. >>>> >>>> Last week I gave a talk on this to a panel that included many of our >>>>friends among the national regulators. >>>> >>>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>> >>>> >>>> >>>> From: "Holmes, David W [CTO]" >>>> Date: Tuesday, February 24, 2015 at 5:06 PM >>>> To: "Peterson, Jon" , "modern@ietf.org" >>>> >>>> Subject: Re: [Modern] draft charter >>>> >>>> Jon, >>>> >>>> Thank you for the work in assembling this draft of the charter for >>>>MODERN. >>>> >>>> We would like to suggest some minor clarifications to the bullets >>>>describing the deliverables, to align them with the statement regarding >>>>flexibility to support the needs of different regulatory regimes, & >>>>thus to ensure that if quoted alone they are not taken out of context; >>>>i.e. the group product will be the protocols to support the allocation >>>>etc. activities, & it would not attempt to define the allocation >>>>processes. We also would like the charter to note the relevant work >>>>that has already been performed by both IETF & the ATIS/SIP Forum JTF, >>>>& incorporate that into the output from the MODERN WG as appropriate. >>>>These changes/additions are have been added to your text inline below. >>>> >>>> We are hoping that the MODERN session at IETF#92 will have remote >>>>access, to allow participation by those of us that cannot attend in >>>>person due to other commitments that week. >>>> >>>> Regards, >>>> >>>> David/Sprint >>>> >>>>_______________________________________________________________________ >>>>_ >>>>______ >>>> >>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, >>>>Jon >>>> Sent: Wednesday, February 11, 2015 9:19 AM >>>> To: modern@ietf.org >>>> Subject: [Modern] draft charter >>>> >>>> >>>> At the Dallas IETF meeting in March, we'd like to get together and >>>>talk about what a working group for MODERN might look like. As an >>>>initial input to the discussion, a few of us have put together a >>>>proposed charter. While the TeRQ work was positively evaluated in the >>>>DISPATCH process, we feel this is broader enough in scope to warrant >>>>its own BoF. >>>> >>>> Comments are welcome, this is just a starting point. >>>> >>>> ------ >>>> >>>> Modern charter text: >>>> >>>> The MODERN working group will define a set of Internet-based >>>>mechanisms for the purposes of managing and resolving telephone numbers >>>>(TNs) in an IP environment. Existing mechanisms for these purposes >>>>face obsolescence as the voice communications infrastructure evolves to >>>>IP technology and new applications for TNs become possible. The >>>>traditional model of a TN having an association to a single service >>>>provider and a single application is breaking down. Its use as a >>>>network locator is going away, but its use as an identifier for an >>>>individual or an organization will remain for some time. Devices, >>>>applications, and network tools increasingly need to manage TNs, >>>>including requesting and acquiring TN delegations from authorities. >>>> >>>> The working group will define a framework for the roles and functions >>>>involved in managing and resolving TNs in an IP environment. This >>>>includes a protocol mechanism for acquiring TNs, which will provide an >>>>enrollment process for the individuals and entities that use and manage >>>>TNs. TNs may either be managed in a hierarchical tree, or in a >>>>distributed peer-to-peer architecture. Privacy of the enrollment data >>>>and security of the resource will be primary considerations. >>>> >>>> Additionally, the working group will deliver a protocol mechanism for >>>>resolving TNs which will allow entities such as service providers, >>>>devices, and applications to access data related to TNs, possibly >>>>including caller name data (CNAM). Maintaining reliability, real time >>>>application performance, security and privacy are primary >>>>considerations. The working group will take into consideration >>>>existing IETF work including ENUM, SPEERMINT, STIR, and DRINKS. >>>> >>>> The work of this group is limited to specifying a solution for TNs and >>>>covers any service that can be addressed using a TN. Expanding the >>>>work to other identifiers is out of scope. Solutions and mechanisms >>>>created by the working group will be flexible enough to accommodate >>>>different policies, e.g., by different regulatory agencies. >>>> >>>> The work group will deliver the following: >>>> >>>> - An architecture overview document that includes high level >>>>requirements and security/privacy considerationsbuilt on the work of >>>>IETF & the ATIS/SIP Forum JTF, that included: >>>> o Call routing architecture >>>> o Inter-carrier NNI >>>> o Cryptographically-enabled Anti-spoofing (STIR) >>>> o Enhanced Calling Name (CNIT/CNAM) >>>> - A document describing the protocols to support enrollment >>>>processes for existing and new TNs including any modifications to >>>>metadata related to those TNs >>>> - A document describing protocol mechanisms for accessing >>>>contact information associated with enrollments >>>> - A document describing protocol mechanisms for resolving >>>>information related to TNs >>>> >>>> - >>>> >>>> >>>> This e-mail may contain Sprint proprietary information intended for >>>>the sole use of the recipient(s). Any use by others is prohibited. If >>>>you are not the intended recipient, please contact the sender and >>>>delete all copies of the message. >>>> _______________________________________________ Modern mailing list >>>>Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ Modern mailing list >>>Modern@ietf.org >>>https://www.ietf.org/mailman/listinfo/modern____________________________ >>>_ >>>__________________ >>> 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 > > >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. From nobody Tue Mar 10 11:58:08 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ECC1A00B6 for ; Tue, 10 Mar 2015 11:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vViiWYg2UEx for ; Tue, 10 Mar 2015 11:58:03 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 4507C1A1B51 for ; Tue, 10 Mar 2015 11:58:03 -0700 (PDT) Received: (qmail 16890 invoked by uid 0); 10 Mar 2015 18:57:58 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 10 Mar 2015 18:57:58 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id 1uxs1q0071MNPNq01uxvk4; Tue, 10 Mar 2015 12:57:56 -0600 X-Authority-Analysis: v=2.1 cv=d8xml3TE c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=emO1SXQWCLwA:10 a=w1VtefKfAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=AUd_NHdVAAAA:8 a=zQP7CpKOAAAA:8 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=lCa4_uAbQaDTmkTieisA:9 a=F6PQldQg3yCeaRyf:21 a=8huIv_oFwMX0Ryrp:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=HePVMhe3h06E9MiXNBu8a9BhSiUt5HB5VTXup7QFZwE=; b=G4+7o3PTpctSnSC7SS/Xia9+93dg7o7/8VLy61YpWSWzPW0DrI02HpztdDnJm6pTlSxDfp+zGPDa1gkBonLwIR5xx2s2ZjQGq5vbMY6XdFIM9Ghcee8XfIWZNde4YiPU; Received: from [108.56.131.201] (port=49302 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YVPLl-0003Sa-Lc; Tue, 10 Mar 2015 12:57:54 -0600 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 10 Mar 2015 14:57:48 -0400 From: Richard Shockey To: Chris Wendt Message-ID: Thread-Topic: [dispatch] CNIT and Modern Charter References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> <95353295-617C-4920-A581-4D0DFA02EDE4@chriswendt.net> In-Reply-To: <95353295-617C-4920-A581-4D0DFA02EDE4@chriswendt.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: Cullen Jennings , cnit@ietf.org, "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:58:07 -0000 Exactly. If the IETF is going to remain responsible for core SIP protocols and signaling its our job to properly define these mechanisms. There is reason to believe if we don=E2=80=99t do this it will be done for us. There were two bills in the US Congress about this last year and who knows what elsewhere. IMHO the in band model is clearly the first use case. That alone would help a great deal.=20 On 3/10/15, 2:37 PM, "Chris Wendt" wrote: >I agree that this would be useful just from the standpoint that if >service providers are going to implement in-band signing of caller-id, >would quite make sense to provide a better payload for delivering >additional and/or more useful calling party information along with >signing it as well. > >-Chris > >> On Mar 9, 2015, at 3:18 PM, Richard Shockey wrote: >>=20 >>=20 >> The first order issue is properly defining what this looks like in SIP >>and >> where in the headers it should reside. There is ample evidence that any >> number of other SDO are looking at this and without some proper >> standardization there will be no interoperability at all especially even >> for STIR validation data at the CUA and IMHO doing nothing is not a >>viable >> option. The basic FROM and PAI usage is not helpful. >>=20 >> We are all aware of how smart phones work. This is principally about >> sessions that would originate outside a select number of phone book >> entries and some display of whether that information has been validated >> though we don=C4=85t have to define policy at this stage and frankly I don=C4=85= t >> think the IETF should try any more than it could try and establish the >> business model for how this would deploy. >>=20 >> The purpose here is simply adding more information about who originated >> the session so the called party has more information than they currently >> have. We already have enough bad actors as it is impersonating tax >> authorities, banks, health care professionals and other governmental >> entities. The purpose is to try and bound those problems to a manageable >> level. There is no silver bullet here. >>=20 >> I would appreciate any suggestions on charter text if you have them. >>=20 >>=20 >>=20 >> =E2=80=B9=20 >> Richard Shockey >> Shockey Consulting LLC >> Chairman of the Board SIP Forum >> www.shockey.us >> www.sipforum.org >> richardshockey.us >> Skype-Linkedin-Facebook rshockey101 >> PSTN +1 703-593-2683 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 3/9/15, 11:10 AM, "Cullen Jennings" wrote: >>=20 >>>=20 >>> On the particular CNAM like topic ... >>>=20 >>> I'm not keen on moving forward with something like this unless we can >>> show the trust and human factors issues is an engineering problem not a >>> research problem. We have seen the difficulty with human readable names >>> in SPAM. Particularly when using UTF-8, how do we stop bad actor >>>getting >>> names that look the same as someone they wish to impersonate? Who will >>> validate the names and issue some sort of trust token that says I can >>>use >>> "Cullen Jennings" or whatever. Who else can use that name and what >>>about >>> names visually similar to it. >>>=20 >>> On the flip side we are seeing most smart phones take the incoming >>>phone >>> number, and look it up the personal address book of the user and >>>display >>> the name that the user of the smartphone assigned. We are seeing >>> enterprise phones that do a similar things using the users social >>> networks as well as personal address book. >>>=20 >>> What would be bad is phone display a display name that some how claimed >>> to be trustable but was not. That would be worse that the current >>> situation. Perhaps people have a good way to solve this in mind but I'm >>> not seeing that that is. >>>=20 >>> Cullen (with my individual contribute hat on of course) >>>=20 >>>=20 >>>=20 >>>> On Feb 25, 2015, at 10:05 AM, Richard Shockey >>>> wrote: >>>>=20 >>>>=20 >>>> Thanks Martin .. This is my very raw first cut at a charter. Its >>>> hopefully simple and straight forward. >>>>=20 >>>> Send me any edits etc. >>>>=20 >>>> ***** >>>>=20 >>>> CNIT Charter [Calling Name Identity Trust] >>>>=20 >>>> WG Chairs TBD: >>>>=20 >>>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters >>>> of information associated with a specific E.164 calling party number >>>>in >>>> the Public Switched Telephone Network [PSTN]. In the PSTN this data >>>>is >>>> sent by the originating network only at the specific request of the >>>> terminating network via a SS7 Transaction Application Part [TCAP] >>>> response message. In the Session Initiation Protocol [SIP] this >>>> information can be inserted into the FROM: part of the originating >>>> INVITE message or by other means. >>>>=20 >>>> As with the originating source telephone number, this data can be >>>> altered in transit creating a variety of malicious abuses similar to >>>>the >>>> ones identified by the IETF STIR working group. >>>>=20 >>>> The purpose of the CNIT working group will be to define a data >>>> structure, a new SIP header or repurpose an existing SIP header to >>>>carry >>>> an advanced form of CNAM as well as information from a STIR Validation >>>> Authority. The purpose of this work is to present to the SIP called >>>> party trusted information from the calling party in order that the >>>> called party make a more reasoned and informed judgment on whether to >>>> accept the INVITE or not. >>>>=20 >>>> The working group will not invalidate any existing SIP mechanism for >>>> anonymous calling. >>>>=20 >>>> The working group will, to the best of its ability, reuse existing >>>>IETF >>>> protocols. >>>>=20 >>>> Full Internationalization of the Calling Name Identity Trust data >>>> object(s) is a requirement. >>>>=20 >>>> The working group will closely work with the IETF STIR working group >>>>=20 >>>> The working group will immediately liaison with 3GPP SA-1 in order to >>>> coordinate efforts. >>>>=20 >>>> The working group will coordinate with National Numbering Authorities >>>> and National Regulatory Authorities as needed. >>>>=20 >>>> The working group will deliver the flowing. >>>>=20 >>>> =E2=82=AC A problem statement and requirements detailing the current >>>>deployment >>>> environment and situations that motivate work on Calling Name Identity >>>> Trust. >>>> =E2=82=AC Define either a new SIP header or document a repurpose of an SIP >>>> existing header for Calling Name Identify Trust data >>>> =E2=82=AC Define a data model for the Calling Name Identity Trust object (s) >>>> which may include various forms of multimedia data >>>> =E2=82=AC Deliver an analysis of privacy implications of the proposed Callin= g >>>> Name Identity Trust mechanism. >>>>=20 >>>>=20 >>>> Milestones: >>>>=20 >>>>=20 >>>> =E2=80=B9=20 >>>> Richard Shockey >>>> Shockey Consulting LLC >>>> Chairman of the Board SIP Forum >>>> www.shockey.us >>>> www.sipforum.org >>>> richardshockey.us >>>> Skype-Linkedin-Facebook rshockey101 >>>> PSTN +1 703-593-2683 >>>>=20 >>>>=20 >>>> From: "DOLLY, MARTIN C" >>>> Date: Tuesday, February 24, 2015 at 9:02 PM >>>> To: Richard Shockey >>>> Cc: "Holmes, David W [CTO]" , >>>> "dispatch@ietf.org" , "modern@ietf.org" >>>> , "Peterson, Jon" >>>> Subject: Re: [Modern] [dispatch] draft charter >>>>=20 >>>> I support Richard on this >>>>=20 >>>> Martin Dolly >>>> Lead Member of Technical Staff >>>> Core & Gov't/Regulatory Standards >>>> AT&T Standards and >>>> Industry Alliances >>>> +1-609-903-3390 >>>> Sent from my iPhone >>>>=20 >>>> On Feb 24, 2015, at 6:36 PM, Richard Shockey >>>>wrote: >>>>=20 >>>>>=20 >>>>> Excellent points David. >>>>>=20 >>>>> My concern here is charter overreach. I really want to keep >>>>>CNAM+/CNIT >>>>> out of this. IMHO that is a very separate and highly focused effort >>>>>to >>>>> define both the modification of the SIP headers necessary to support >>>>> some enhanced calling party identification and a very limited effort >>>>>to >>>>> define the object and or the STIR validation data. >>>>>=20 >>>>> I=C4=85m violently opposed to =C5=82end world hunger=CB=9B WG=C4=85s. >>>>>=20 >>>>> If registries can be used fine but I certainly want to see how this >>>>> can be accomplished in bi lateral agreements between consenting >>>>>service >>>>> providers and work with CUA vendors on how the data is displayed aka >>>>> Apple, Samsung, Microsoft in the context of a formal liaison with >>>>>3GPP. >>>>> Certainly the relevance of CNAM+/CNIT in enterprise and residential >>>>> access markets is important but we all know =C5=82Money is the answer wha= t >>>>> is the question ..=CB=9B >>>>>=20 >>>>> I=C4=85ve asked for time in Dispatch to look at the CNAM/CNIT issue and >>>>> report on the JTF on NNI. As you well know we have made considerable >>>>> progress. >>>>>=20 >>>>> Last week I gave a talk on this to a panel that included many of our >>>>> friends among the national regulators. >>>>>=20 >>>>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: "Holmes, David W [CTO]" >>>>> Date: Tuesday, February 24, 2015 at 5:06 PM >>>>> To: "Peterson, Jon" , "modern@ietf.org" >>>>> >>>>> Subject: Re: [Modern] draft charter >>>>>=20 >>>>> Jon,=20 >>>>>=20 >>>>> Thank you for the work in assembling this draft of the charter for >>>>> MODERN. >>>>>=20 >>>>> We would like to suggest some minor clarifications to the bullets >>>>> describing the deliverables, to align them with the statement >>>>>regarding >>>>> flexibility to support the needs of different regulatory regimes, & >>>>> thus to ensure that if quoted alone they are not taken out of >>>>>context; >>>>> i.e. the group product will be the protocols to support the >>>>>allocation >>>>> etc. activities, & it would not attempt to define the allocation >>>>> processes. We also would like the charter to note the relevant work >>>>> that has already been performed by both IETF & the ATIS/SIP Forum >>>>>JTF, >>>>> & incorporate that into the output from the MODERN WG as appropriate. >>>>> These changes/additions are have been added to your text inline >>>>>below. >>>>>=20 >>>>> We are hoping that the MODERN session at IETF#92 will have remote >>>>> access, to allow participation by those of us that cannot attend in >>>>> person due to other commitments that week. >>>>>=20 >>>>> Regards,=20 >>>>>=20 >>>>> David/Sprint=20 >>>>>=20 >>>>>=20 >>>>>______________________________________________________________________ >>>>>__ >>>>> ______ >>>>>=20 >>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, >>>>> Jon >>>>> Sent: Wednesday, February 11, 2015 9:19 AM >>>>> To: modern@ietf.org >>>>> Subject: [Modern] draft charter >>>>>=20 >>>>>=20 >>>>> At the Dallas IETF meeting in March, we'd like to get together and >>>>> talk about what a working group for MODERN might look like. As an >>>>> initial input to the discussion, a few of us have put together a >>>>> proposed charter. While the TeRQ work was positively evaluated in the >>>>> DISPATCH process, we feel this is broader enough in scope to warrant >>>>> its own BoF. >>>>>=20 >>>>> Comments are welcome, this is just a starting point. >>>>>=20 >>>>> ------ >>>>>=20 >>>>> Modern charter text: >>>>>=20 >>>>> The MODERN working group will define a set of Internet-based >>>>> mechanisms for the purposes of managing and resolving telephone >>>>>numbers >>>>> (TNs) in an IP environment. Existing mechanisms for these purposes >>>>> face obsolescence as the voice communications infrastructure evolves >>>>>to >>>>> IP technology and new applications for TNs become possible. The >>>>> traditional model of a TN having an association to a single service >>>>> provider and a single application is breaking down. Its use as a >>>>> network locator is going away, but its use as an identifier for an >>>>> individual or an organization will remain for some time. Devices, >>>>> applications, and network tools increasingly need to manage TNs, >>>>> including requesting and acquiring TN delegations from authorities. >>>>>=20 >>>>> The working group will define a framework for the roles and functions >>>>> involved in managing and resolving TNs in an IP environment. This >>>>> includes a protocol mechanism for acquiring TNs, which will provide >>>>>an >>>>> enrollment process for the individuals and entities that use and >>>>>manage >>>>> TNs. TNs may either be managed in a hierarchical tree, or in a >>>>> distributed peer-to-peer architecture. Privacy of the enrollment >>>>>data >>>>> and security of the resource will be primary considerations. >>>>>=20 >>>>> Additionally, the working group will deliver a protocol mechanism for >>>>> resolving TNs which will allow entities such as service providers, >>>>> devices, and applications to access data related to TNs, possibly >>>>> including caller name data (CNAM). Maintaining reliability, real >>>>>time >>>>> application performance, security and privacy are primary >>>>> considerations. The working group will take into consideration >>>>> existing IETF work including ENUM, SPEERMINT, STIR, and DRINKS. >>>>>=20 >>>>> The work of this group is limited to specifying a solution for TNs >>>>>and >>>>> covers any service that can be addressed using a TN. Expanding the >>>>> work to other identifiers is out of scope. Solutions and mechanisms >>>>> created by the working group will be flexible enough to accommodate >>>>> different policies, e.g., by different regulatory agencies. >>>>>=20 >>>>> The work group will deliver the following: >>>>>=20 >>>>> - An architecture overview document that includes high level >>>>> requirements and security/privacy considerationsbuilt on the work of >>>>> IETF & the ATIS/SIP Forum JTF, that included: >>>>> o Call routing architecture >>>>> o Inter-carrier NNI >>>>> o Cryptographically-enabled Anti-spoofing (STIR) >>>>> o Enhanced Calling Name (CNIT/CNAM) >>>>> - A document describing the protocols to support enrollment >>>>> processes for existing and new TNs including any modifications to >>>>> metadata related to those TNs >>>>> - A document describing protocol mechanisms for accessing >>>>> contact information associated with enrollments >>>>> - A document describing protocol mechanisms for resolving >>>>> information related to TNs >>>>>=20 >>>>> - =20 >>>>>=20 >>>>>=20 >>>>> This e-mail may contain Sprint proprietary information intended for >>>>> the sole use of the recipient(s). Any use by others is prohibited. If >>>>> you are not the intended recipient, please contact the sender and >>>>> delete all copies of the message. >>>>> _______________________________________________ Modern mailing list >>>>> Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> _______________________________________________ Modern mailing list >>>> Modern@ietf.org >>>>=20 >>>>https://www.ietf.org/mailman/listinfo/modern___________________________ >>>>__ >>>> __________________ >>>> 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 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Mar 10 12:00:15 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E638B1A8891; Tue, 10 Mar 2015 12:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ3UjqIQBUYR; Tue, 10 Mar 2015 12:00:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB391A8726; Tue, 10 Mar 2015 12:00:03 -0700 (PDT) Received: from BN1BFFO11FD012.protection.gbl (10.58.144.33) by BN1BFFO11HUB031.protection.gbl (10.58.144.178) with Microsoft SMTP Server (TLS) id 15.1.112.13; Tue, 10 Mar 2015 18:59:43 +0000 Received: from plsasdm1.corp.sprint.com (144.230.168.25) by BN1BFFO11FD012.mail.protection.outlook.com (10.58.144.75) with Microsoft SMTP Server (TLS) id 15.1.112.13 via Frontend Transport; Tue, 10 Mar 2015 18:59:41 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t2AIxbTk016284 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2015 13:59:40 -0500 Received: from PREWE13M08.ad.sprint.com (prewe13m08.corp.sprint.com [144.226.128.27]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t2AIxahO019717 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Mar 2015 13:59:40 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M08.ad.sprint.com (2002:90e2:801b::90e2:801b) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 10 Mar 2015 14:58:28 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0995.028; Tue, 10 Mar 2015 13:58:28 -0500 From: "Gorman, Pierce A [CTO]" To: Richard Shockey , Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Thread-Topic: [dispatch] CNIT and Modern Charter Thread-Index: AQHQWp3ul5him8B2KUGtFEmSTKBzBp0UtHzwgAGxCoD//61e4A== Date: Tue, 10 Mar 2015 18:58:28 +0000 Message-ID: <13c4861265204b8faee6af46ce62af9a@PLSWE13M08.ad.sprint.com> References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.21] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.168.25 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.168.25; helo=plsasdm1.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.230.168.25) smtp.mailfrom=Pierce.Gorman@sprint.com; shockey.us; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:144.230.168.25; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(53824002)(24454002)(13464003)(479174004)(189002)(377454003)(199003)(2900100001)(77156002)(2950100001)(62966003)(6806004)(15974865002)(54356999)(551934003)(76176999)(50986999)(47776003)(92726002)(2201001)(15975445007)(92566002)(50466002)(33646002)(107886001)(106116001)(93886004)(86362001)(106466001)(2501003)(2656002)(23676002)(87936001)(19580405001)(19580395003)(46102003)(102836002)(5250100002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1BFFO11HUB031; H:plsasdm1.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1BFFO11HUB031; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BN1BFFO11HUB031; BCL:0; PCL:0; RULEID:; SRVR:BN1BFFO11HUB031; X-Forefront-PRVS: 051158ECBB X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2015 18:59:41.6394 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.168.25]; Helo=[plsasdm1.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1BFFO11HUB031 Archived-At: Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:00:12 -0000 U2hvdWxkIHRoZXJlIGJlIG11dHVhbCBhdXRoZW50aWNhdGlvbj8gIFNob3VsZCB0aGUgY2FsbGlu ZyBwYXJ0eSByZWNlaXZlIGEgY2FsbGVkIHBhcnR5IGlkZW50aXR5Pw0KDQpCZXN0IHJlZ2FyZHMs DQoNCg0KUGllcmNlIEdvcm1hbg0KVm9pY2UgQXJjaGl0ZWN0dXJlDQpDb3JlIFBsYW5uaW5nL1Nw cmludA0KOTEzLTQzOS00MzY4IChEZXNrKQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogUmljaGFyZCBTaG9ja2V5IFttYWlsdG86cmljaGFyZEBzaG9ja2V5LnVzXQ0KU2VudDog TWFyY2ggMTAsIDIwMTUgMTo1MyBQTQ0KVG86IEdvcm1hbiwgUGllcmNlIEEgW0NUT107IEN1bGxl biBKZW5uaW5nczsgY25pdEBpZXRmLm9yZzsgZGlzcGF0Y2hAaWV0Zi5vcmc7IG1vZGVybkBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gQ05JVCBhbmQgTW9kZXJuIENoYXJ0ZXINCg0K DQpFeGFjdGx54oCmIHN0dWR5aW5nIHRoZSB0cnVzdCBtb2RlbHMgYXJlIHBlcmZlY3RseSBhcHBy b3ByaWF0ZS4gIE9idmlvdXNseSB0aGUgY2FsbGluZyBwYXJ0eSBkYXRhIGNhbiBjb21lIGZyb20g ZGlmZmVyZW50IHNvdXJjZXMgdGhvdWdoIEkgc3VzcGVjdCBpbiBpdHMgZWFybGllc3QgbW9kZWxz IGl0IGNvbWVzIGZyb20gdGhlIG9yaWdpbmF0aW5nIHNlcnZpY2UgcHJvdmlkZXIgdGhyb3VnaCB0 aGUgU0lQIHNpZ25hbGluZyBtZWNoYW5pc20gdG8gdGhlIHRlcm1pbmF0aW5nIENVQS4gRXNwZWNp YWxseSBpbiB0aGUgVm9MVEUgY2FzZS4NCg0KRW50ZXJwcmlzZSB0byBFbnRlcnByaXNlIHdvdWxk IGNsZWFybHkgYmUgZGlmZmVyZW50LiAgQ2VydGFpbmx5IDNyZCBwYXJ0eSBkYXRhYmFzZXMgY291 bGQgYmUgaW52b2x2ZWQgaW4gc29tZSB3YXkuDQoNCkkgd291bGQgcmVtaW5kIGZvbGtzIHRoYXQg dGhlIHJhdGlvbmFsZSBmb3IgdGhpcyBpcyBjb25zdW1lcnMgYW5kIE5hdGlvbmFsIFJlZ3VsYXRv cnMgYXJlIE5PVCBIQVBQWSBBVCBBTEwgd2l0aCB0aGUgY3VycmVudCBzdGF0ZSBvZiBob3cgY2Fs bGluZyBwYXJ0eSBkYXRhIGlzIHByZXNlbnRlZCB0byB0aGUgY29uc3VtZXIuIFNUSVIgaW4gYW5k IG9mIGl0c2VsZiBpcyBub3QgZW5vdWdoLiAgVGhpcyBpcyB1bHRpbWF0ZWx5IGEgY29uc3VtZXIg cHJvdGVjdGlvbiBpc3N1ZS4NCg0KDQoNCg0KT24gMy85LzE1LCA2OjI1IFBNLCAiR29ybWFuLCBQ aWVyY2UgQSBbQ1RPXSIgPFBpZXJjZS5Hb3JtYW5Ac3ByaW50LmNvbT4NCndyb3RlOg0KDQo+SSBk b24ndCBoYXZlIGFueSB1c2VmdWwgY2hhcnRlciB0ZXh0Lg0KPkkgYWdyZWUgdGhhdCB0aGUgSUVU RiBzaG91bGQgbm90IHByb3Bvc2UgYnVzaW5lc3MgbW9kZWxzLCBidXQgaXQgc2VlbXMNCj5pbXBv cnRhbnQgdG8gY29uc2lkZXIgdHJ1c3QgbW9kZWwocykgdG8gc2VlIGlmIGl0L3RoZXkgZHJpdmUg cHJvdG9jb2wNCj5jb25zaWRlcmF0aW9ucy4NCj5XZSBjb3VsZCBzdGFydCB3aXRoIGxpc3Rpbmcg YXNzdW1wdGlvbnMuICBJJ2xsIHN0YXJ0IGJ5IGxpc3RpbmcgdHdvLg0KPiAgICAgMSkgSSBhc3N1 bWUgdGhlcmUgd291bGQgYmUgbXVsdGlwbGUgYXV0aG9yaXRpZXMgYW5kIG11bHRpcGxlDQo+bGV2 ZWxzIG9mIHRydXN0Lg0KPiAgICAgMikgSSBhc3N1bWUgdGhlcmUgYXJlIGludGVybmF0aW9uYWwg dHJhZGVuYW1lLCBhbmQgdHJhZGVtYXJrIGFuZA0KPnRoZSBhZm9yZW1lbnRpb25lZCBVVEYtOCBp bnRlcm5hdGlvbmFsIGNoYXJhY3RlciBjb2RlIHNwb29maW5nIGNvbnNpZGVyYXRpb25zLg0KPg0K Pg0KPkJlc3QgcmVnYXJkcywNCj4NCj4NCj5QaWVyY2UgR29ybWFuDQo+Vm9pY2UgQXJjaGl0ZWN0 dXJlDQo+Q29yZSBQbGFubmluZy9TcHJpbnQNCj45MTMtNDM5LTQzNjggKERlc2spDQo+DQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBNb2Rlcm4gW21haWx0bzptb2Rlcm4tYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQNCj5TaG9ja2V5DQo+U2VudDogTWFy Y2ggMDksIDIwMTUgMjoxOCBQTQ0KPlRvOiBDdWxsZW4gSmVubmluZ3M7IGNuaXRAaWV0Zi5vcmc7 IGRpc3BhdGNoQGlldGYub3JnOyBtb2Rlcm5AaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW01vZGVy bl0gW2Rpc3BhdGNoXSBDTklUIGFuZCBNb2Rlcm4gQ2hhcnRlcg0KPg0KPg0KPlRoZSBmaXJzdCBv cmRlciBpc3N1ZSBpcyBwcm9wZXJseSBkZWZpbmluZyB3aGF0IHRoaXMgbG9va3MgbGlrZSBpbiBT SVANCj5hbmQgd2hlcmUgaW4gdGhlIGhlYWRlcnMgaXQgc2hvdWxkIHJlc2lkZS4gVGhlcmUgaXMg YW1wbGUgZXZpZGVuY2UgdGhhdA0KPmFueSBudW1iZXIgb2Ygb3RoZXIgU0RPIGFyZSBsb29raW5n IGF0IHRoaXMgYW5kIHdpdGhvdXQgc29tZSBwcm9wZXINCj5zdGFuZGFyZGl6YXRpb24gdGhlcmUg d2lsbCBiZSBubyBpbnRlcm9wZXJhYmlsaXR5IGF0IGFsbCBlc3BlY2lhbGx5DQo+ZXZlbiBmb3Ig U1RJUiB2YWxpZGF0aW9uIGRhdGEgYXQgdGhlIENVQSBhbmQgSU1ITyBkb2luZyBub3RoaW5nIGlz IG5vdA0KPmEgdmlhYmxlIG9wdGlvbi4gVGhlIGJhc2ljIEZST00gYW5kIFBBSSB1c2FnZSBpcyBu b3QgaGVscGZ1bC4NCj4NCj5XZSBhcmUgYWxsIGF3YXJlIG9mIGhvdyBzbWFydCBwaG9uZXMgd29y ay4gVGhpcyBpcyBwcmluY2lwYWxseSBhYm91dA0KPnNlc3Npb25zIHRoYXQgd291bGQgb3JpZ2lu YXRlIG91dHNpZGUgYSBzZWxlY3QgbnVtYmVyIG9mIHBob25lIGJvb2sNCj5lbnRyaWVzIGFuZCBz b21lIGRpc3BsYXkgb2Ygd2hldGhlciB0aGF0IGluZm9ybWF0aW9uIGhhcyBiZWVuIHZhbGlkYXRl ZA0KPnRob3VnaCB3ZSBkb27CuXQgaGF2ZSB0byBkZWZpbmUgcG9saWN5IGF0IHRoaXMgc3RhZ2Ug YW5kIGZyYW5rbHkgSSBkb27CuXQNCj50aGluayB0aGUgSUVURiBzaG91bGQgdHJ5IGFueSBtb3Jl IHRoYW4gaXQgY291bGQgdHJ5IGFuZCBlc3RhYmxpc2ggdGhlDQo+YnVzaW5lc3MgbW9kZWwgZm9y IGhvdyB0aGlzIHdvdWxkIGRlcGxveS4NCj4NCj5UaGUgcHVycG9zZSBoZXJlIGlzIHNpbXBseSBh ZGRpbmcgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB3aG8gb3JpZ2luYXRlZA0KPnRoZSBzZXNzaW9u IHNvIHRoZSBjYWxsZWQgcGFydHkgaGFzIG1vcmUgaW5mb3JtYXRpb24gdGhhbiB0aGV5DQo+Y3Vy cmVudGx5IGhhdmUuICBXZSBhbHJlYWR5IGhhdmUgZW5vdWdoIGJhZCBhY3RvcnMgYXMgaXQgaXMN Cj5pbXBlcnNvbmF0aW5nIHRheCBhdXRob3JpdGllcywgYmFua3MsIGhlYWx0aCBjYXJlIHByb2Zl c3Npb25hbHMgYW5kDQo+b3RoZXIgZ292ZXJubWVudGFsIGVudGl0aWVzLiBUaGUgcHVycG9zZSBp cyB0byB0cnkgYW5kIGJvdW5kIHRob3NlDQo+cHJvYmxlbXMgdG8gYSBtYW5hZ2VhYmxlIGxldmVs LiAgVGhlcmUgaXMgbm8gc2lsdmVyIGJ1bGxldCBoZXJlLg0KPg0KPkkgd291bGQgYXBwcmVjaWF0 ZSBhbnkgc3VnZ2VzdGlvbnMgb24gY2hhcnRlciB0ZXh0IGlmIHlvdSBoYXZlIHRoZW0uDQo+DQo+ DQo+DQo+4oC5DQo+UmljaGFyZCBTaG9ja2V5DQo+U2hvY2tleSBDb25zdWx0aW5nIExMQw0KPkNo YWlybWFuIG9mIHRoZSBCb2FyZCBTSVAgRm9ydW0NCj53d3cuc2hvY2tleS51cw0KPnd3dy5zaXBm b3J1bS5vcmcNCj5yaWNoYXJkPGF0PnNob2NrZXkudXMNCj5Ta3lwZS1MaW5rZWRpbi1GYWNlYm9v ayByc2hvY2tleTEwMQ0KPlBTVE4gKzEgNzAzLTU5My0yNjgzDQo+DQo+DQo+DQo+DQo+DQo+T24g My85LzE1LCAxMToxMCBBTSwgIkN1bGxlbiBKZW5uaW5ncyIgPGZsdWZmeUBjaXNjby5jb20+IHdy b3RlOg0KPg0KPj4NCj4+T24gdGhlIHBhcnRpY3VsYXIgQ05BTSBsaWtlIHRvcGljIC4uLg0KPj4N Cj4+SSdtIG5vdCBrZWVuIG9uIG1vdmluZyBmb3J3YXJkIHdpdGggc29tZXRoaW5nIGxpa2UgdGhp cyB1bmxlc3Mgd2UgY2FuDQo+PnNob3cgdGhlIHRydXN0IGFuZCBodW1hbiBmYWN0b3JzIGlzc3Vl cyBpcyBhbiBlbmdpbmVlcmluZyBwcm9ibGVtIG5vdA0KPj5hIHJlc2VhcmNoIHByb2JsZW0uIFdl IGhhdmUgc2VlbiB0aGUgZGlmZmljdWx0eSB3aXRoIGh1bWFuIHJlYWRhYmxlDQo+Pm5hbWVzIGlu IFNQQU0uIFBhcnRpY3VsYXJseSB3aGVuIHVzaW5nIFVURi04LCBob3cgZG8gd2Ugc3RvcCBiYWQg YWN0b3INCj4+Z2V0dGluZyBuYW1lcyB0aGF0IGxvb2sgdGhlIHNhbWUgYXMgc29tZW9uZSB0aGV5 IHdpc2ggdG8gaW1wZXJzb25hdGU/DQo+PldobyB3aWxsIHZhbGlkYXRlIHRoZSBuYW1lcyBhbmQg aXNzdWUgc29tZSBzb3J0IG9mIHRydXN0IHRva2VuIHRoYXQNCj4+c2F5cyBJIGNhbiB1c2UgIkN1 bGxlbiBKZW5uaW5ncyIgb3Igd2hhdGV2ZXIuIFdobyBlbHNlIGNhbiB1c2UgdGhhdA0KPj5uYW1l IGFuZCB3aGF0IGFib3V0IG5hbWVzIHZpc3VhbGx5IHNpbWlsYXIgdG8gaXQuDQo+Pg0KPj5PbiB0 aGUgZmxpcCBzaWRlIHdlIGFyZSBzZWVpbmcgbW9zdCBzbWFydCBwaG9uZXMgdGFrZSB0aGUgaW5j b21pbmcNCj4+cGhvbmUgbnVtYmVyLCBhbmQgbG9vayBpdCB1cCB0aGUgcGVyc29uYWwgYWRkcmVz cyBib29rIG9mIHRoZSB1c2VyIGFuZA0KPj5kaXNwbGF5IHRoZSBuYW1lIHRoYXQgdGhlIHVzZXIg b2YgdGhlIHNtYXJ0cGhvbmUgYXNzaWduZWQuIFdlIGFyZQ0KPj5zZWVpbmcgZW50ZXJwcmlzZSBw aG9uZXMgdGhhdCBkbyBhIHNpbWlsYXIgdGhpbmdzIHVzaW5nIHRoZSB1c2Vycw0KPj5zb2NpYWwg bmV0d29ya3MgYXMgd2VsbCBhcyBwZXJzb25hbCBhZGRyZXNzIGJvb2suDQo+Pg0KPj5XaGF0IHdv dWxkIGJlIGJhZCBpcyBwaG9uZSBkaXNwbGF5IGEgZGlzcGxheSBuYW1lIHRoYXQgc29tZSBob3cN Cj4+Y2xhaW1lZCB0byBiZSB0cnVzdGFibGUgYnV0IHdhcyBub3QuIFRoYXQgd291bGQgYmUgd29y c2UgdGhhdCB0aGUNCj4+Y3VycmVudCBzaXR1YXRpb24uIFBlcmhhcHMgcGVvcGxlIGhhdmUgYSBn b29kIHdheSB0byBzb2x2ZSB0aGlzIGluDQo+Pm1pbmQgYnV0IEknbSBub3Qgc2VlaW5nIHRoYXQg dGhhdCBpcy4NCj4+DQo+PkN1bGxlbiAod2l0aCBteSBpbmRpdmlkdWFsIGNvbnRyaWJ1dGUgaGF0 IG9uIG9mIGNvdXJzZSkNCj4+DQo+Pg0KPj4NCj4+PiBPbiBGZWIgMjUsIDIwMTUsIGF0IDEwOjA1 IEFNLCBSaWNoYXJkIFNob2NrZXkgPHJpY2hhcmRAc2hvY2tleS51cz4NCj4+Pndyb3RlOg0KPj4+ DQo+Pj4NCj4+PiBUaGFua3MgTWFydGluIC4uIFRoaXMgaXMgbXkgdmVyeSByYXcgZmlyc3QgY3V0 IGF0IGEgY2hhcnRlci4gSXRzDQo+Pj5ob3BlZnVsbHkgc2ltcGxlIGFuZCBzdHJhaWdodCBmb3J3 YXJkLg0KPj4+DQo+Pj4gU2VuZCBtZSBhbnkgZWRpdHMgZXRjLg0KPj4+DQo+Pj4gKioqKioNCj4+ Pg0KPj4+IENOSVQgQ2hhcnRlciBbQ2FsbGluZyBOYW1lIElkZW50aXR5IFRydXN0XQ0KPj4+DQo+ Pj4gV0cgQ2hhaXJzIFRCRDoNCj4+Pg0KPj4+IENhbGxpbmcgTmFtZSBEZWxpdmVyeSBbQ05BTV0g aXMgYSBzdHJpbmcgb2YgdXAgdG8gMTUgQVNDSUkNCj4+PkNoYXJhY3RlcnMgb2YgaW5mb3JtYXRp b24gYXNzb2NpYXRlZCB3aXRoIGEgc3BlY2lmaWMgRS4xNjQgY2FsbGluZw0KPj4+cGFydHkgbnVt YmVyIGluIHRoZSBQdWJsaWMgU3dpdGNoZWQgVGVsZXBob25lIE5ldHdvcmsgW1BTVE5dLiAgSW4g dGhlDQo+Pj5QU1ROIHRoaXMgZGF0YSBpcyBzZW50IGJ5IHRoZSBvcmlnaW5hdGluZyBuZXR3b3Jr IG9ubHkgYXQgdGhlDQo+Pj5zcGVjaWZpYyByZXF1ZXN0IG9mIHRoZSB0ZXJtaW5hdGluZyBuZXR3 b3JrIHZpYSBhIFNTNyBUcmFuc2FjdGlvbg0KPj4+QXBwbGljYXRpb24gUGFydCBbVENBUF0gcmVz cG9uc2UgbWVzc2FnZS4gIEluIHRoZSBTZXNzaW9uIEluaXRpYXRpb24NCj4+PlByb3RvY29sIFtT SVBdIHRoaXMgaW5mb3JtYXRpb24gY2FuIGJlIGluc2VydGVkIGludG8gdGhlIEZST006IHBhcnQN Cj4+Pm9mIHRoZSBvcmlnaW5hdGluZyBJTlZJVEUgbWVzc2FnZSBvciBieSBvdGhlciBtZWFucy4N Cj4+Pg0KPj4+IEFzIHdpdGggdGhlIG9yaWdpbmF0aW5nIHNvdXJjZSB0ZWxlcGhvbmUgbnVtYmVy LCB0aGlzIGRhdGEgY2FuIGJlDQo+Pj5hbHRlcmVkIGluIHRyYW5zaXQgY3JlYXRpbmcgYSB2YXJp ZXR5IG9mIG1hbGljaW91cyBhYnVzZXMgc2ltaWxhciB0bw0KPj4+dGhlIG9uZXMgaWRlbnRpZmll ZCBieSB0aGUgSUVURiBTVElSIHdvcmtpbmcgZ3JvdXAuDQo+Pj4NCj4+PiBUaGUgcHVycG9zZSBv ZiB0aGUgQ05JVCB3b3JraW5nIGdyb3VwIHdpbGwgYmUgdG8gZGVmaW5lIGEgZGF0YQ0KPj4+c3Ry dWN0dXJlLCBhIG5ldyBTSVAgaGVhZGVyIG9yIHJlcHVycG9zZSBhbiBleGlzdGluZyBTSVAgaGVh ZGVyIHRvDQo+Pj5jYXJyeSBhbiBhZHZhbmNlZCBmb3JtIG9mIENOQU0gYXMgd2VsbCBhcyBpbmZv cm1hdGlvbiBmcm9tIGEgU1RJUg0KPj4+VmFsaWRhdGlvbiBBdXRob3JpdHkuICBUaGUgcHVycG9z ZSBvZiB0aGlzIHdvcmsgaXMgdG8gcHJlc2VudCB0byB0aGUNCj4+PlNJUCBjYWxsZWQgcGFydHkg dHJ1c3RlZCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBjYWxsaW5nIHBhcnR5IGluIG9yZGVyDQo+Pj50 aGF0IHRoZSBjYWxsZWQgcGFydHkgbWFrZSBhIG1vcmUgcmVhc29uZWQgYW5kIGluZm9ybWVkIGp1 ZGdtZW50IG9uDQo+Pj53aGV0aGVyIHRvIGFjY2VwdCB0aGUgSU5WSVRFIG9yIG5vdC4NCj4+Pg0K Pj4+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgbm90IGludmFsaWRhdGUgYW55IGV4aXN0aW5nIFNJ UCBtZWNoYW5pc20gZm9yDQo+Pj5hbm9ueW1vdXMgY2FsbGluZy4NCj4+Pg0KPj4+IFRoZSB3b3Jr aW5nIGdyb3VwIHdpbGwsIHRvIHRoZSBiZXN0IG9mIGl0cyBhYmlsaXR5LCByZXVzZSBleGlzdGlu Zw0KPj4+SUVURiBwcm90b2NvbHMuDQo+Pj4NCj4+PiBGdWxsIEludGVybmF0aW9uYWxpemF0aW9u IG9mIHRoZSBDYWxsaW5nIE5hbWUgSWRlbnRpdHkgVHJ1c3QgZGF0YQ0KPj4+b2JqZWN0KHMpIGlz IGEgcmVxdWlyZW1lbnQuDQo+Pj4NCj4+PiBUaGUgd29ya2luZyBncm91cCB3aWxsIGNsb3NlbHkg d29yayB3aXRoIHRoZSBJRVRGIFNUSVIgd29ya2luZyBncm91cA0KPj4+DQo+Pj4gVGhlIHdvcmtp bmcgZ3JvdXAgd2lsbCBpbW1lZGlhdGVseSBsaWFpc29uIHdpdGggM0dQUCBTQS0xIGluIG9yZGVy DQo+Pj50byBjb29yZGluYXRlIGVmZm9ydHMuDQo+Pj4NCj4+PiBUaGUgd29ya2luZyBncm91cCB3 aWxsIGNvb3JkaW5hdGUgd2l0aCBOYXRpb25hbCBOdW1iZXJpbmcNCj4+PkF1dGhvcml0aWVzIGFu ZCBOYXRpb25hbCBSZWd1bGF0b3J5IEF1dGhvcml0aWVzIGFzIG5lZWRlZC4NCj4+Pg0KPj4+IFRo ZSB3b3JraW5nIGdyb3VwIHdpbGwgZGVsaXZlciB0aGUgZmxvd2luZy4NCj4+Pg0KPj4+IOKCrEEg cHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHJlcXVpcmVtZW50cyBkZXRhaWxpbmcgdGhlIGN1cnJlbnQN Cj4+PmRlcGxveW1lbnQgZW52aXJvbm1lbnQgYW5kIHNpdHVhdGlvbnMgdGhhdCBtb3RpdmF0ZSB3 b3JrIG9uIENhbGxpbmcNCj4+Pk5hbWUgSWRlbnRpdHkgVHJ1c3QuDQo+Pj4g4oKsRGVmaW5lIGVp dGhlciBhIG5ldyBTSVAgaGVhZGVyIG9yIGRvY3VtZW50IGEgcmVwdXJwb3NlIG9mIGFuIFNJUA0K Pj4+ZXhpc3RpbmcgaGVhZGVyIGZvciBDYWxsaW5nIE5hbWUgSWRlbnRpZnkgVHJ1c3QgZGF0YSAg 4oKsRGVmaW5lIGEgZGF0YQ0KPj4+bW9kZWwgZm9yIHRoZSBDYWxsaW5nIE5hbWUgSWRlbnRpdHkg VHJ1c3Qgb2JqZWN0IChzKSB3aGljaCBtYXkNCj4+PmluY2x1ZGUgdmFyaW91cyBmb3JtcyBvZiBt dWx0aW1lZGlhIGRhdGEgIOKCrERlbGl2ZXIgYW4gYW5hbHlzaXMgb2YNCj4+PnByaXZhY3kgaW1w bGljYXRpb25zIG9mIHRoZSBwcm9wb3NlZCBDYWxsaW5nIE5hbWUgSWRlbnRpdHkgVHJ1c3QNCj4+ Pm1lY2hhbmlzbS4NCj4+Pg0KPj4+DQo+Pj4gTWlsZXN0b25lczoNCj4+Pg0KPj4+DQo+Pj4g4oC5 DQo+Pj4gUmljaGFyZCBTaG9ja2V5DQo+Pj4gU2hvY2tleSBDb25zdWx0aW5nIExMQw0KPj4+IENo YWlybWFuIG9mIHRoZSBCb2FyZCBTSVAgRm9ydW0NCj4+PiB3d3cuc2hvY2tleS51cw0KPj4+IHd3 dy5zaXBmb3J1bS5vcmcNCj4+PiByaWNoYXJkPGF0PnNob2NrZXkudXMNCj4+PiBTa3lwZS1MaW5r ZWRpbi1GYWNlYm9vayByc2hvY2tleTEwMQ0KPj4+IFBTVE4gKzEgNzAzLTU5My0yNjgzDQo+Pj4N Cj4+Pg0KPj4+IEZyb206ICJET0xMWSwgTUFSVElOIEMiIDxtZDMxMzVAYXR0LmNvbT4NCj4+PiBE YXRlOiBUdWVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNSBhdCA5OjAyIFBNDQo+Pj4gVG86IFJpY2hh cmQgU2hvY2tleSA8cmljaGFyZEBzaG9ja2V5LnVzPg0KPj4+IENjOiAiSG9sbWVzLCBEYXZpZCBX IFtDVE9dIiA8RGF2aWQuSG9sbWVzQHNwcmludC5jb20+LA0KPj4+ImRpc3BhdGNoQGlldGYub3Jn IiA8ZGlzcGF0Y2hAaWV0Zi5vcmc+LCAibW9kZXJuQGlldGYub3JnIg0KPj4+PG1vZGVybkBpZXRm Lm9yZz4sICJQZXRlcnNvbiwgSm9uIiA8am9uLnBldGVyc29uQG5ldXN0YXIuYml6Pg0KPj4+IFN1 YmplY3Q6IFJlOiBbTW9kZXJuXSBbZGlzcGF0Y2hdIGRyYWZ0IGNoYXJ0ZXINCj4+Pg0KPj4+IEkg c3VwcG9ydCBSaWNoYXJkIG9uIHRoaXMNCj4+Pg0KPj4+IE1hcnRpbiBEb2xseQ0KPj4+IExlYWQg TWVtYmVyIG9mIFRlY2huaWNhbCBTdGFmZg0KPj4+IENvcmUgJiBHb3YndC9SZWd1bGF0b3J5IFN0 YW5kYXJkcw0KPj4+IEFUJlQgU3RhbmRhcmRzIGFuZA0KPj4+IEluZHVzdHJ5IEFsbGlhbmNlcw0K Pj4+ICsxLTYwOS05MDMtMzM5MA0KPj4+IFNlbnQgZnJvbSBteSBpUGhvbmUNCj4+Pg0KPj4+IE9u IEZlYiAyNCwgMjAxNSwgYXQgNjozNiBQTSwgUmljaGFyZCBTaG9ja2V5IDxyaWNoYXJkQHNob2Nr ZXkudXM+DQo+Pj53cm90ZToNCj4+Pg0KPj4+Pg0KPj4+PiBFeGNlbGxlbnQgcG9pbnRzIERhdmlk Lg0KPj4+Pg0KPj4+PiBNeSBjb25jZXJuIGhlcmUgaXMgY2hhcnRlciBvdmVycmVhY2guIEkgcmVh bGx5IHdhbnQgdG8ga2VlcA0KPj4+PkNOQU0rL0NOSVQgb3V0IG9mIHRoaXMuICBJTUhPIHRoYXQg aXMgYSB2ZXJ5IHNlcGFyYXRlIGFuZCBoaWdobHkNCj4+Pj5mb2N1c2VkIGVmZm9ydCB0byBkZWZp bmUgYm90aCB0aGUgbW9kaWZpY2F0aW9uIG9mIHRoZSBTSVAgaGVhZGVycw0KPj4+Pm5lY2Vzc2Fy eSB0byBzdXBwb3J0IHNvbWUgZW5oYW5jZWQgY2FsbGluZyBwYXJ0eSBpZGVudGlmaWNhdGlvbiBh bmQNCj4+Pj5hIHZlcnkgbGltaXRlZCBlZmZvcnQgdG8gZGVmaW5lIHRoZSBvYmplY3QgYW5kIG9y IHRoZSBTVElSIHZhbGlkYXRpb24gZGF0YS4NCj4+Pj4NCj4+Pj4gScK5bSB2aW9sZW50bHkgb3Bw b3NlZCB0byDCs2VuZCB3b3JsZCBodW5nZXLCsiBXR8K5cy4NCj4+Pj4NCj4+Pj4gSWYgcmVnaXN0 cmllcyBjYW4gYmUgdXNlZCBmaW5lIGJ1dCBJIGNlcnRhaW5seSB3YW50IHRvIHNlZSBob3cgdGhp cw0KPj4+PmNhbiBiZSBhY2NvbXBsaXNoZWQgaW4gYmkgbGF0ZXJhbCBhZ3JlZW1lbnRzIGJldHdl ZW4gY29uc2VudGluZw0KPj4+PnNlcnZpY2UgcHJvdmlkZXJzIGFuZCB3b3JrIHdpdGggQ1VBIHZl bmRvcnMgb24gaG93IHRoZSBkYXRhIGlzDQo+Pj4+ZGlzcGxheWVkIGFrYSBBcHBsZSwgU2Ftc3Vu ZywgTWljcm9zb2Z0IGluIHRoZSBjb250ZXh0IG9mIGEgZm9ybWFsIGxpYWlzb24gd2l0aCAzR1BQ Lg0KPj4+PiBDZXJ0YWlubHkgdGhlIHJlbGV2YW5jZSBvZiBDTkFNKy9DTklUIGluIGVudGVycHJp c2UgYW5kIHJlc2lkZW50aWFsDQo+Pj4+YWNjZXNzIG1hcmtldHMgaXMgaW1wb3J0YW50IGJ1dCB3 ZSBhbGwga25vdyDCs01vbmV5IGlzIHRoZSBhbnN3ZXINCj4+Pj53aGF0IGlzIHRoZSAgcXVlc3Rp b24gLi7Csg0KPj4+Pg0KPj4+PiBJwrl2ZSBhc2tlZCBmb3IgdGltZSBpbiBEaXNwYXRjaCB0byBs b29rIGF0IHRoZSBDTkFNL0NOSVQgaXNzdWUgYW5kDQo+Pj4+cmVwb3J0IG9uIHRoZSBKVEYgb24g Tk5JLiBBcyB5b3Ugd2VsbCBrbm93IHdlIGhhdmUgbWFkZSBjb25zaWRlcmFibGUNCj4+Pj5wcm9n cmVzcy4NCj4+Pj4NCj4+Pj4gTGFzdCB3ZWVrIEkgZ2F2ZSBhIHRhbGsgb24gdGhpcyB0byBhIHBh bmVsIHRoYXQgaW5jbHVkZWQgbWFueSBvZg0KPj4+Pm91ciBmcmllbmRzIGFtb25nIHRoZSBuYXRp b25hbCByZWd1bGF0b3JzLg0KPj4+Pg0KPj4+PiBodHRwOi8vYXBwcy5mY2MuZ292L2VjZnMvZG9j dW1lbnQvdmlldz9pZD02MDAwMTAzMzIxNw0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBGcm9tOiAi SG9sbWVzLCBEYXZpZCBXIFtDVE9dIiA8RGF2aWQuSG9sbWVzQHNwcmludC5jb20+DQo+Pj4+IERh dGU6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE1IGF0IDU6MDYgUE0NCj4+Pj4gVG86ICJQZXRl cnNvbiwgSm9uIiA8am9uLnBldGVyc29uQG5ldXN0YXIuYml6PiwgIm1vZGVybkBpZXRmLm9yZyIN Cj4+Pj48bW9kZXJuQGlldGYub3JnPg0KPj4+PiBTdWJqZWN0OiBSZTogW01vZGVybl0gZHJhZnQg Y2hhcnRlcg0KPj4+Pg0KPj4+PiBKb24sDQo+Pj4+DQo+Pj4+IFRoYW5rIHlvdSBmb3IgdGhlIHdv cmsgaW4gYXNzZW1ibGluZyB0aGlzIGRyYWZ0IG9mIHRoZSBjaGFydGVyIGZvcg0KPj4+Pk1PREVS Ti4NCj4+Pj4NCj4+Pj4gV2Ugd291bGQgbGlrZSB0byBzdWdnZXN0IHNvbWUgbWlub3IgY2xhcmlm aWNhdGlvbnMgdG8gdGhlIGJ1bGxldHMNCj4+Pj5kZXNjcmliaW5nIHRoZSBkZWxpdmVyYWJsZXMs IHRvIGFsaWduIHRoZW0gd2l0aCB0aGUgc3RhdGVtZW50DQo+Pj4+cmVnYXJkaW5nIGZsZXhpYmls aXR5IHRvIHN1cHBvcnQgdGhlIG5lZWRzIG9mIGRpZmZlcmVudCByZWd1bGF0b3J5DQo+Pj4+cmVn aW1lcywgJiB0aHVzIHRvIGVuc3VyZSB0aGF0IGlmIHF1b3RlZCBhbG9uZSB0aGV5IGFyZSBub3Qg dGFrZW4NCj4+Pj5vdXQgb2YgY29udGV4dDsgaS5lLiB0aGUgZ3JvdXAgcHJvZHVjdCB3aWxsIGJl IHRoZSBwcm90b2NvbHMgdG8NCj4+Pj5zdXBwb3J0IHRoZSBhbGxvY2F0aW9uIGV0Yy4gYWN0aXZp dGllcywgJiBpdCB3b3VsZCBub3QgYXR0ZW1wdCB0bw0KPj4+PmRlZmluZSB0aGUgYWxsb2NhdGlv biBwcm9jZXNzZXMuICBXZSBhbHNvIHdvdWxkIGxpa2UgdGhlIGNoYXJ0ZXIgdG8NCj4+Pj5ub3Rl IHRoZSByZWxldmFudCB3b3JrIHRoYXQgaGFzIGFscmVhZHkgYmVlbiBwZXJmb3JtZWQgYnkgYm90 aCBJRVRGDQo+Pj4+JiB0aGUgQVRJUy9TSVAgRm9ydW0gSlRGLCAmIGluY29ycG9yYXRlIHRoYXQg aW50byB0aGUgb3V0cHV0IGZyb20gdGhlIE1PREVSTiBXRyBhcyBhcHByb3ByaWF0ZS4NCj4+Pj5U aGVzZSBjaGFuZ2VzL2FkZGl0aW9ucyBhcmUgaGF2ZSBiZWVuIGFkZGVkIHRvIHlvdXIgdGV4dCBp bmxpbmUgYmVsb3cuDQo+Pj4+DQo+Pj4+IFdlIGFyZSBob3BpbmcgdGhhdCB0aGUgTU9ERVJOIHNl c3Npb24gYXQgSUVURiM5MiB3aWxsIGhhdmUgcmVtb3RlDQo+Pj4+YWNjZXNzLCB0byBhbGxvdyBw YXJ0aWNpcGF0aW9uIGJ5IHRob3NlIG9mIHVzIHRoYXQgY2Fubm90IGF0dGVuZCBpbg0KPj4+PnBl cnNvbiBkdWUgdG8gb3RoZXIgY29tbWl0bWVudHMgdGhhdCB3ZWVrLg0KPj4+Pg0KPj4+PiBSZWdh cmRzLA0KPj4+Pg0KPj4+PiBEYXZpZC9TcHJpbnQNCj4+Pj4NCj4+Pj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pl9fXw0KPj4+Pl8NCj4+Pj5fX19fX18NCj4+Pj4NCj4+Pj4gRnJvbTogTW9kZXJuIFttYWlsdG86 bW9kZXJuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPj4+PlBldGVyc29uLCBKb24N Cj4+Pj4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNSA5OjE5IEFNDQo+Pj4+IFRv OiBtb2Rlcm5AaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogW01vZGVybl0gZHJhZnQgY2hhcnRlcg0K Pj4+Pg0KPj4+Pg0KPj4+PiBBdCB0aGUgRGFsbGFzIElFVEYgbWVldGluZyBpbiBNYXJjaCwgd2Un ZCBsaWtlIHRvIGdldCB0b2dldGhlciBhbmQNCj4+Pj50YWxrIGFib3V0IHdoYXQgYSB3b3JraW5n IGdyb3VwIGZvciBNT0RFUk4gbWlnaHQgbG9vayBsaWtlLiBBcyBhbg0KPj4+PmluaXRpYWwgaW5w dXQgdG8gdGhlIGRpc2N1c3Npb24sIGEgZmV3IG9mIHVzIGhhdmUgcHV0IHRvZ2V0aGVyIGENCj4+ Pj5wcm9wb3NlZCBjaGFydGVyLiBXaGlsZSB0aGUgVGVSUSB3b3JrIHdhcyBwb3NpdGl2ZWx5IGV2 YWx1YXRlZCBpbg0KPj4+PnRoZSBESVNQQVRDSCBwcm9jZXNzLCB3ZSBmZWVsIHRoaXMgaXMgYnJv YWRlciBlbm91Z2ggaW4gc2NvcGUgdG8NCj4+Pj53YXJyYW50IGl0cyBvd24gQm9GLg0KPj4+Pg0K Pj4+PiBDb21tZW50cyBhcmUgd2VsY29tZSwgdGhpcyBpcyBqdXN0IGEgc3RhcnRpbmcgcG9pbnQu DQo+Pj4+DQo+Pj4+IC0tLS0tLQ0KPj4+Pg0KPj4+PiBNb2Rlcm4gY2hhcnRlciB0ZXh0Og0KPj4+ Pg0KPj4+PiBUaGUgTU9ERVJOIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgYSBzZXQgb2YgSW50 ZXJuZXQtYmFzZWQNCj4+Pj5tZWNoYW5pc21zIGZvciB0aGUgcHVycG9zZXMgb2YgbWFuYWdpbmcg YW5kIHJlc29sdmluZyB0ZWxlcGhvbmUNCj4+Pj5udW1iZXJzDQo+Pj4+KFROcykgaW4gYW4gSVAg ZW52aXJvbm1lbnQuICBFeGlzdGluZyBtZWNoYW5pc21zIGZvciB0aGVzZSBwdXJwb3Nlcw0KPj4+ PmZhY2Ugb2Jzb2xlc2NlbmNlIGFzIHRoZSB2b2ljZSBjb21tdW5pY2F0aW9ucyBpbmZyYXN0cnVj dHVyZSBldm9sdmVzDQo+Pj4+dG8gSVAgdGVjaG5vbG9neSBhbmQgbmV3IGFwcGxpY2F0aW9ucyBm b3IgVE5zIGJlY29tZSBwb3NzaWJsZS4gIFRoZQ0KPj4+PnRyYWRpdGlvbmFsIG1vZGVsIG9mIGEg VE4gaGF2aW5nIGFuIGFzc29jaWF0aW9uIHRvIGEgc2luZ2xlIHNlcnZpY2UNCj4+Pj5wcm92aWRl ciBhbmQgYSBzaW5nbGUgYXBwbGljYXRpb24gaXMgYnJlYWtpbmcgZG93bi4gIEl0cyB1c2UgYXMg YQ0KPj4+Pm5ldHdvcmsgbG9jYXRvciBpcyBnb2luZyBhd2F5LCBidXQgaXRzIHVzZSBhcyBhbiBp ZGVudGlmaWVyIGZvciBhbg0KPj4+PmluZGl2aWR1YWwgb3IgYW4gb3JnYW5pemF0aW9uIHdpbGwg cmVtYWluIGZvciBzb21lIHRpbWUuIERldmljZXMsDQo+Pj4+YXBwbGljYXRpb25zLCBhbmQgbmV0 d29yayB0b29scyBpbmNyZWFzaW5nbHkgbmVlZCB0byBtYW5hZ2UgVE5zLA0KPj4+PmluY2x1ZGlu ZyByZXF1ZXN0aW5nIGFuZCBhY3F1aXJpbmcgVE4gZGVsZWdhdGlvbnMgZnJvbSBhdXRob3JpdGll cy4NCj4+Pj4NCj4+Pj4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgYSBmcmFtZXdvcmsg Zm9yIHRoZSByb2xlcyBhbmQNCj4+Pj5mdW5jdGlvbnMgaW52b2x2ZWQgaW4gbWFuYWdpbmcgYW5k IHJlc29sdmluZyBUTnMgaW4gYW4gSVANCj4+Pj5lbnZpcm9ubWVudC4gVGhpcyBpbmNsdWRlcyBh IHByb3RvY29sIG1lY2hhbmlzbSBmb3IgYWNxdWlyaW5nIFROcywNCj4+Pj53aGljaCB3aWxsIHBy b3ZpZGUgYW4gZW5yb2xsbWVudCBwcm9jZXNzIGZvciB0aGUgaW5kaXZpZHVhbHMgYW5kDQo+Pj4+ ZW50aXRpZXMgdGhhdCB1c2UgYW5kIG1hbmFnZSBUTnMuIFROcyBtYXkgZWl0aGVyIGJlIG1hbmFn ZWQgaW4gYQ0KPj4+PmhpZXJhcmNoaWNhbCB0cmVlLCBvciBpbiBhIGRpc3RyaWJ1dGVkIHBlZXIt dG8tcGVlciBhcmNoaXRlY3R1cmUuDQo+Pj4+UHJpdmFjeSBvZiB0aGUgZW5yb2xsbWVudCBkYXRh IGFuZCBzZWN1cml0eSBvZiB0aGUgcmVzb3VyY2Ugd2lsbCBiZSBwcmltYXJ5IGNvbnNpZGVyYXRp b25zLg0KPj4+Pg0KPj4+PiBBZGRpdGlvbmFsbHksIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGVs aXZlciBhIHByb3RvY29sIG1lY2hhbmlzbQ0KPj4+PmZvciByZXNvbHZpbmcgVE5zIHdoaWNoIHdp bGwgYWxsb3cgZW50aXRpZXMgc3VjaCBhcyBzZXJ2aWNlDQo+Pj4+cHJvdmlkZXJzLCBkZXZpY2Vz LCBhbmQgYXBwbGljYXRpb25zIHRvIGFjY2VzcyBkYXRhIHJlbGF0ZWQgdG8gVE5zLA0KPj4+PnBv c3NpYmx5IGluY2x1ZGluZyBjYWxsZXIgbmFtZSBkYXRhIChDTkFNKS4gIE1haW50YWluaW5nDQo+ Pj4+cmVsaWFiaWxpdHksIHJlYWwgdGltZSBhcHBsaWNhdGlvbiBwZXJmb3JtYW5jZSwgc2VjdXJp dHkgYW5kIHByaXZhY3kNCj4+Pj5hcmUgcHJpbWFyeSBjb25zaWRlcmF0aW9ucy4gIFRoZSB3b3Jr aW5nIGdyb3VwIHdpbGwgdGFrZSBpbnRvDQo+Pj4+Y29uc2lkZXJhdGlvbiBleGlzdGluZyBJRVRG IHdvcmsgaW5jbHVkaW5nIEVOVU0sIFNQRUVSTUlOVCwgU1RJUiwgYW5kIERSSU5LUy4NCj4+Pj4N Cj4+Pj4gVGhlIHdvcmsgb2YgdGhpcyBncm91cCBpcyBsaW1pdGVkIHRvIHNwZWNpZnlpbmcgYSBz b2x1dGlvbiBmb3IgVE5zDQo+Pj4+YW5kIGNvdmVycyBhbnkgc2VydmljZSB0aGF0IGNhbiBiZSBh ZGRyZXNzZWQgdXNpbmcgYSBUTi4gIEV4cGFuZGluZw0KPj4+PnRoZSB3b3JrIHRvIG90aGVyIGlk ZW50aWZpZXJzIGlzIG91dCBvZiBzY29wZS4gIFNvbHV0aW9ucyBhbmQNCj4+Pj5tZWNoYW5pc21z IGNyZWF0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBiZSBmbGV4aWJsZSBlbm91Z2ggdG8N Cj4+Pj5hY2NvbW1vZGF0ZSBkaWZmZXJlbnQgcG9saWNpZXMsIGUuZy4sIGJ5IGRpZmZlcmVudCBy ZWd1bGF0b3J5IGFnZW5jaWVzLg0KPj4+Pg0KPj4+PiBUaGUgd29yayBncm91cCB3aWxsIGRlbGl2 ZXIgdGhlIGZvbGxvd2luZzoNCj4+Pj4NCj4+Pj4gLSAgICAgICAgICBBbiBhcmNoaXRlY3R1cmUg b3ZlcnZpZXcgZG9jdW1lbnQgdGhhdCBpbmNsdWRlcyBoaWdoIGxldmVsDQo+Pj4+cmVxdWlyZW1l bnRzIGFuZCBzZWN1cml0eS9wcml2YWN5IGNvbnNpZGVyYXRpb25zYnVpbHQgb24gdGhlIHdvcmsg b2YNCj4+Pj5JRVRGICYgdGhlIEFUSVMvU0lQIEZvcnVtIEpURiwgdGhhdCBpbmNsdWRlZDoNCj4+ Pj4gbyAgIENhbGwgcm91dGluZyBhcmNoaXRlY3R1cmUNCj4+Pj4gbyAgIEludGVyLWNhcnJpZXIg Tk5JDQo+Pj4+IG8gICBDcnlwdG9ncmFwaGljYWxseS1lbmFibGVkIEFudGktc3Bvb2ZpbmcgKFNU SVIpDQo+Pj4+IG8gICBFbmhhbmNlZCBDYWxsaW5nIE5hbWUgKENOSVQvQ05BTSkNCj4+Pj4gLSAg ICAgICAgICBBIGRvY3VtZW50IGRlc2NyaWJpbmcgdGhlIHByb3RvY29scyB0byBzdXBwb3J0IGVu cm9sbG1lbnQNCj4+Pj5wcm9jZXNzZXMgZm9yIGV4aXN0aW5nIGFuZCBuZXcgVE5zIGluY2x1ZGlu ZyBhbnkgbW9kaWZpY2F0aW9ucyB0bw0KPj4+Pm1ldGFkYXRhIHJlbGF0ZWQgdG8gdGhvc2UgVE5z DQo+Pj4+IC0gICAgICAgICAgQSBkb2N1bWVudCBkZXNjcmliaW5nIHByb3RvY29sIG1lY2hhbmlz bXMgZm9yIGFjY2Vzc2luZw0KPj4+PmNvbnRhY3QgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRo IGVucm9sbG1lbnRzDQo+Pj4+IC0gICAgICAgICAgQSBkb2N1bWVudCBkZXNjcmliaW5nIHByb3Rv Y29sIG1lY2hhbmlzbXMgZm9yIHJlc29sdmluZw0KPj4+PmluZm9ybWF0aW9uIHJlbGF0ZWQgdG8g VE5zDQo+Pj4+DQo+Pj4+IC0NCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhpcyBlLW1haWwgbWF5IGNvbnRh aW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvcg0KPj4+PnRoZSBz b2xlIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJp dGVkLg0KPj4+PklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBj b250YWN0IHRoZSBzZW5kZXIgYW5kDQo+Pj4+ZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3Nh Z2UuDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IE1vZGVybiBtYWlsaW5nIGxpc3QNCj4+Pj5Nb2Rlcm5AaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tb2Rlcm4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+ Pj4+IGRpc3BhdGNoQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGlzcGF0Y2gNCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyBNb2Rlcm4gbWFpbGluZyBsaXN0DQo+Pj5Nb2Rlcm5AaWV0Zi5vcmcNCj4+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW9kZXJuX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+X19fDQo+Pj5fDQo+Pj5fX19fX19fX19fX19fX19fX18NCj4+PiBk aXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4+PiBkaXNwYXRjaEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4+DQo+Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PmRpc3BhdGNoIG1haWxpbmcg bGlzdA0KPj5kaXNwYXRjaEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Rpc3BhdGNoDQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5Nb2Rlcm4gbWFpbGluZyBsaXN0DQo+TW9kZXJuQGlldGYub3Jn DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tb2Rlcm4NCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPlRoaXMgZS1tYWlsIG1heSBjb250YWlu IFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlDQo+c29sZSB1 c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4g SWYgeW91DQo+YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0 aGUgc2VuZGVyIGFuZCBkZWxldGUNCj5hbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBlLW1haWwgbWF5IGNvbnRh aW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMgcHJvaGliaXRlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhl IHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2UuDQo= From nobody Tue Mar 10 12:37:18 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DDD1A1B51 for ; Tue, 10 Mar 2015 12:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 oh93eqahvOuG for ; Tue, 10 Mar 2015 12:37:13 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id A229B1A8837 for ; Tue, 10 Mar 2015 12:37:12 -0700 (PDT) Received: (qmail 28303 invoked by uid 0); 10 Mar 2015 19:37:10 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 10 Mar 2015 19:37:10 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 21d51q00j1MNPNq011d8fQ; Tue, 10 Mar 2015 19:37:08 -0600 X-Authority-Analysis: v=2.1 cv=GJqbTI9K c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=emO1SXQWCLwA:10 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=AUd_NHdVAAAA:8 a=zQP7CpKOAAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=mHzDmSJhgmuQEHE9BYcA:9 a=GbgNgFfZDaRurbUZ:21 a=wnV0NKHQwkAa0n8_:21 a=QEXdDO2ut3YA:10 a=DzjOOp_o1eYA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=8WGTykBUFZ9dyGLs6ViMMUg+x1Z9XOIdWIxGwxuXj4s=; b=ZhU4illlJdwzrsU+6Fd4dcoGWVjSeTZZm78RrA3AKbkZzYOss26PXHilf5YWzTAl/ls9je7mgdBuUOJm64RAbHXWmIn5paXLpJtx07YoWMoK2gj1OuFm58WrA9X/MiiI; Received: from [108.56.131.201] (port=49341 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YVPxi-0003hL-Os; Tue, 10 Mar 2015 13:37:07 -0600 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 10 Mar 2015 15:36:59 -0400 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Message-ID: Thread-Topic: [dispatch] CNIT and Modern Charter References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> <13c4861265204b8faee6af46ce62af9a@PLSWE13M08.ad.sprint.com> In-Reply-To: <13c4861265204b8faee6af46ce62af9a@PLSWE13M08.ad.sprint.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:37:17 -0000 As a matter of principal I wouldn=E2=80=99t rule anything like this out but there could be some philshing issues. My question would be why? Sort of like the old out of band STIR idea that I=E2=80=99m convinced is going no where. I=E2=80=99d like to fix one simple problem reasonably quickly. On 3/10/15, 2:58 PM, "Gorman, Pierce A [CTO]" wrote: >Should there be mutual authentication? Should the calling party receive >a called party identity? > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > >-----Original Message----- >From: Richard Shockey [mailto:richard@shockey.us] >Sent: March 10, 2015 1:53 PM >To: Gorman, Pierce A [CTO]; Cullen Jennings; cnit@ietf.org; >dispatch@ietf.org; modern@ietf.org >Subject: Re: [dispatch] CNIT and Modern Charter > > >Exactly=E2=80=A6 studying the trust models are perfectly appropriate. Obviously >the calling party data can come from different sources though I suspect >in its earliest models it comes from the originating service provider >through the SIP signaling mechanism to the terminating CUA. Especially in >the VoLTE case. > >Enterprise to Enterprise would clearly be different. Certainly 3rd party >databases could be involved in some way. > >I would remind folks that the rationale for this is consumers and >National Regulators are NOT HAPPY AT ALL with the current state of how >calling party data is presented to the consumer. STIR in and of itself is >not enough. This is ultimately a consumer protection issue. > > > > >On 3/9/15, 6:25 PM, "Gorman, Pierce A [CTO]" >wrote: > >>I don't have any useful charter text. >>I agree that the IETF should not propose business models, but it seems >>important to consider trust model(s) to see if it/they drive protocol >>considerations. >>We could start with listing assumptions. I'll start by listing two. >> 1) I assume there would be multiple authorities and multiple >>levels of trust. >> 2) I assume there are international tradename, and trademark and >>the aforementioned UTF-8 international character code spoofing >>considerations. >> >> >>Best regards, >> >> >>Pierce Gorman >>Voice Architecture >>Core Planning/Sprint >>913-439-4368 (Desk) >> >>-----Original Message----- >>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard >>Shockey >>Sent: March 09, 2015 2:18 PM >>To: Cullen Jennings; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org >>Subject: Re: [Modern] [dispatch] CNIT and Modern Charter >> >> >>The first order issue is properly defining what this looks like in SIP >>and where in the headers it should reside. There is ample evidence that >>any number of other SDO are looking at this and without some proper >>standardization there will be no interoperability at all especially >>even for STIR validation data at the CUA and IMHO doing nothing is not >>a viable option. The basic FROM and PAI usage is not helpful. >> >>We are all aware of how smart phones work. This is principally about >>sessions that would originate outside a select number of phone book >>entries and some display of whether that information has been validated >>though we don=C2=B9t have to define policy at this stage and frankly I don=C2=B9t >>think the IETF should try any more than it could try and establish the >>business model for how this would deploy. >> >>The purpose here is simply adding more information about who originated >>the session so the called party has more information than they >>currently have. We already have enough bad actors as it is >>impersonating tax authorities, banks, health care professionals and >>other governmental entities. The purpose is to try and bound those >>problems to a manageable level. There is no silver bullet here. >> >>I would appreciate any suggestions on charter text if you have them. >> >> >> >>=E2=80=B9 >>Richard Shockey >>Shockey Consulting LLC >>Chairman of the Board SIP Forum >>www.shockey.us >>www.sipforum.org >>richardshockey.us >>Skype-Linkedin-Facebook rshockey101 >>PSTN +1 703-593-2683 >> >> >> >> >> >>On 3/9/15, 11:10 AM, "Cullen Jennings" wrote: >> >>> >>>On the particular CNAM like topic ... >>> >>>I'm not keen on moving forward with something like this unless we can >>>show the trust and human factors issues is an engineering problem not >>>a research problem. We have seen the difficulty with human readable >>>names in SPAM. Particularly when using UTF-8, how do we stop bad actor >>>getting names that look the same as someone they wish to impersonate? >>>Who will validate the names and issue some sort of trust token that >>>says I can use "Cullen Jennings" or whatever. Who else can use that >>>name and what about names visually similar to it. >>> >>>On the flip side we are seeing most smart phones take the incoming >>>phone number, and look it up the personal address book of the user and >>>display the name that the user of the smartphone assigned. We are >>>seeing enterprise phones that do a similar things using the users >>>social networks as well as personal address book. >>> >>>What would be bad is phone display a display name that some how >>>claimed to be trustable but was not. That would be worse that the >>>current situation. Perhaps people have a good way to solve this in >>>mind but I'm not seeing that that is. >>> >>>Cullen (with my individual contribute hat on of course) >>> >>> >>> >>>> On Feb 25, 2015, at 10:05 AM, Richard Shockey >>>>wrote: >>>> >>>> >>>> Thanks Martin .. This is my very raw first cut at a charter. Its >>>>hopefully simple and straight forward. >>>> >>>> Send me any edits etc. >>>> >>>> ***** >>>> >>>> CNIT Charter [Calling Name Identity Trust] >>>> >>>> WG Chairs TBD: >>>> >>>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII >>>>Characters of information associated with a specific E.164 calling >>>>party number in the Public Switched Telephone Network [PSTN]. In the >>>>PSTN this data is sent by the originating network only at the >>>>specific request of the terminating network via a SS7 Transaction >>>>Application Part [TCAP] response message. In the Session Initiation >>>>Protocol [SIP] this information can be inserted into the FROM: part >>>>of the originating INVITE message or by other means. >>>> >>>> As with the originating source telephone number, this data can be >>>>altered in transit creating a variety of malicious abuses similar to >>>>the ones identified by the IETF STIR working group. >>>> >>>> The purpose of the CNIT working group will be to define a data >>>>structure, a new SIP header or repurpose an existing SIP header to >>>>carry an advanced form of CNAM as well as information from a STIR >>>>Validation Authority. The purpose of this work is to present to the >>>>SIP called party trusted information from the calling party in order >>>>that the called party make a more reasoned and informed judgment on >>>>whether to accept the INVITE or not. >>>> >>>> The working group will not invalidate any existing SIP mechanism for >>>>anonymous calling. >>>> >>>> The working group will, to the best of its ability, reuse existing >>>>IETF protocols. >>>> >>>> Full Internationalization of the Calling Name Identity Trust data >>>>object(s) is a requirement. >>>> >>>> The working group will closely work with the IETF STIR working group >>>> >>>> The working group will immediately liaison with 3GPP SA-1 in order >>>>to coordinate efforts. >>>> >>>> The working group will coordinate with National Numbering >>>>Authorities and National Regulatory Authorities as needed. >>>> >>>> The working group will deliver the flowing. >>>> >>>> =E2=82=ACA problem statement and requirements detailing the current >>>>deployment environment and situations that motivate work on Calling >>>>Name Identity Trust. >>>> =E2=82=ACDefine either a new SIP header or document a repurpose of an SIP >>>>existing header for Calling Name Identify Trust data =E2=82=ACDefine a data >>>>model for the Calling Name Identity Trust object (s) which may >>>>include various forms of multimedia data =E2=82=ACDeliver an analysis of >>>>privacy implications of the proposed Calling Name Identity Trust >>>>mechanism. >>>> >>>> >>>> Milestones: >>>> >>>> >>>> =E2=80=B9 >>>> Richard Shockey >>>> Shockey Consulting LLC >>>> Chairman of the Board SIP Forum >>>> www.shockey.us >>>> www.sipforum.org >>>> richardshockey.us >>>> Skype-Linkedin-Facebook rshockey101 >>>> PSTN +1 703-593-2683 >>>> >>>> >>>> From: "DOLLY, MARTIN C" >>>> Date: Tuesday, February 24, 2015 at 9:02 PM >>>> To: Richard Shockey >>>> Cc: "Holmes, David W [CTO]" , >>>>"dispatch@ietf.org" , "modern@ietf.org" >>>>, "Peterson, Jon" >>>> Subject: Re: [Modern] [dispatch] draft charter >>>> >>>> I support Richard on this >>>> >>>> Martin Dolly >>>> Lead Member of Technical Staff >>>> Core & Gov't/Regulatory Standards >>>> AT&T Standards and >>>> Industry Alliances >>>> +1-609-903-3390 >>>> Sent from my iPhone >>>> >>>> On Feb 24, 2015, at 6:36 PM, Richard Shockey >>>>wrote: >>>> >>>>> >>>>> Excellent points David. >>>>> >>>>> My concern here is charter overreach. I really want to keep >>>>>CNAM+/CNIT out of this. IMHO that is a very separate and highly >>>>>focused effort to define both the modification of the SIP headers >>>>>necessary to support some enhanced calling party identification and >>>>>a very limited effort to define the object and or the STIR validation >>>>>data. >>>>> >>>>> I=C2=B9m violently opposed to =C2=B3end world hunger=C2=B2 WG=C2=B9s. >>>>> >>>>> If registries can be used fine but I certainly want to see how this >>>>>can be accomplished in bi lateral agreements between consenting >>>>>service providers and work with CUA vendors on how the data is >>>>>displayed aka Apple, Samsung, Microsoft in the context of a formal >>>>>liaison with 3GPP. >>>>> Certainly the relevance of CNAM+/CNIT in enterprise and residential >>>>>access markets is important but we all know =C2=B3Money is the answer >>>>>what is the question ..=C2=B2 >>>>> >>>>> I=C2=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and >>>>>report on the JTF on NNI. As you well know we have made considerable >>>>>progress. >>>>> >>>>> Last week I gave a talk on this to a panel that included many of >>>>>our friends among the national regulators. >>>>> >>>>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>>> >>>>> >>>>> >>>>> From: "Holmes, David W [CTO]" >>>>> Date: Tuesday, February 24, 2015 at 5:06 PM >>>>> To: "Peterson, Jon" , "modern@ietf.org" >>>>> >>>>> Subject: Re: [Modern] draft charter >>>>> >>>>> Jon, >>>>> >>>>> Thank you for the work in assembling this draft of the charter for >>>>>MODERN. >>>>> >>>>> We would like to suggest some minor clarifications to the bullets >>>>>describing the deliverables, to align them with the statement >>>>>regarding flexibility to support the needs of different regulatory >>>>>regimes, & thus to ensure that if quoted alone they are not taken >>>>>out of context; i.e. the group product will be the protocols to >>>>>support the allocation etc. activities, & it would not attempt to >>>>>define the allocation processes. We also would like the charter to >>>>>note the relevant work that has already been performed by both IETF >>>>>& the ATIS/SIP Forum JTF, & incorporate that into the output from the >>>>>MODERN WG as appropriate. >>>>>These changes/additions are have been added to your text inline below. >>>>> >>>>> We are hoping that the MODERN session at IETF#92 will have remote >>>>>access, to allow participation by those of us that cannot attend in >>>>>person due to other commitments that week. >>>>> >>>>> Regards, >>>>> >>>>> David/Sprint >>>>> >>>>>____________________________________________________________________ >>>>>___ >>>>>_ >>>>>______ >>>>> >>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>>>>Peterson, Jon >>>>> Sent: Wednesday, February 11, 2015 9:19 AM >>>>> To: modern@ietf.org >>>>> Subject: [Modern] draft charter >>>>> >>>>> >>>>> At the Dallas IETF meeting in March, we'd like to get together and >>>>>talk about what a working group for MODERN might look like. As an >>>>>initial input to the discussion, a few of us have put together a >>>>>proposed charter. While the TeRQ work was positively evaluated in >>>>>the DISPATCH process, we feel this is broader enough in scope to >>>>>warrant its own BoF. >>>>> >>>>> Comments are welcome, this is just a starting point. >>>>> >>>>> ------ >>>>> >>>>> Modern charter text: >>>>> >>>>> The MODERN working group will define a set of Internet-based >>>>>mechanisms for the purposes of managing and resolving telephone >>>>>numbers >>>>>(TNs) in an IP environment. Existing mechanisms for these purposes >>>>>face obsolescence as the voice communications infrastructure evolves >>>>>to IP technology and new applications for TNs become possible. The >>>>>traditional model of a TN having an association to a single service >>>>>provider and a single application is breaking down. Its use as a >>>>>network locator is going away, but its use as an identifier for an >>>>>individual or an organization will remain for some time. Devices, >>>>>applications, and network tools increasingly need to manage TNs, >>>>>including requesting and acquiring TN delegations from authorities. >>>>> >>>>> The working group will define a framework for the roles and >>>>>functions involved in managing and resolving TNs in an IP >>>>>environment. This includes a protocol mechanism for acquiring TNs, >>>>>which will provide an enrollment process for the individuals and >>>>>entities that use and manage TNs. TNs may either be managed in a >>>>>hierarchical tree, or in a distributed peer-to-peer architecture. >>>>>Privacy of the enrollment data and security of the resource will be >>>>>primary considerations. >>>>> >>>>> Additionally, the working group will deliver a protocol mechanism >>>>>for resolving TNs which will allow entities such as service >>>>>providers, devices, and applications to access data related to TNs, >>>>>possibly including caller name data (CNAM). Maintaining >>>>>reliability, real time application performance, security and privacy >>>>>are primary considerations. The working group will take into >>>>>consideration existing IETF work including ENUM, SPEERMINT, STIR, and >>>>>DRINKS. >>>>> >>>>> The work of this group is limited to specifying a solution for TNs >>>>>and covers any service that can be addressed using a TN. Expanding >>>>>the work to other identifiers is out of scope. Solutions and >>>>>mechanisms created by the working group will be flexible enough to >>>>>accommodate different policies, e.g., by different regulatory >>>>>agencies. >>>>> >>>>> The work group will deliver the following: >>>>> >>>>> - An architecture overview document that includes high level >>>>>requirements and security/privacy considerationsbuilt on the work of >>>>>IETF & the ATIS/SIP Forum JTF, that included: >>>>> o Call routing architecture >>>>> o Inter-carrier NNI >>>>> o Cryptographically-enabled Anti-spoofing (STIR) >>>>> o Enhanced Calling Name (CNIT/CNAM) >>>>> - A document describing the protocols to support enrollment >>>>>processes for existing and new TNs including any modifications to >>>>>metadata related to those TNs >>>>> - A document describing protocol mechanisms for accessing >>>>>contact information associated with enrollments >>>>> - A document describing protocol mechanisms for resolving >>>>>information related to TNs >>>>> >>>>> - >>>>> >>>>> >>>>> This e-mail may contain Sprint proprietary information intended for >>>>>the sole use of the recipient(s). Any use by others is prohibited. >>>>>If you are not the intended recipient, please contact the sender and >>>>>delete all copies of the message. >>>>> _______________________________________________ Modern mailing list >>>>>Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> _______________________________________________ Modern mailing list >>>>Modern@ietf.org >>>>https://www.ietf.org/mailman/listinfo/modern_________________________ >>>>___ >>>>_ >>>>__________________ >>>> 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 >> >> >>_______________________________________________ >>Modern mailing list >>Modern@ietf.org >>https://www.ietf.org/mailman/listinfo/modern >> >>________________________________ >> >>This e-mail may contain Sprint proprietary information intended for the >>sole use of the recipient(s). Any use by others is prohibited. If you >>are not the intended recipient, please contact the sender and delete >>all copies of the message. > > > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. From nobody Tue Mar 10 12:49:01 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318AB1A8864; Tue, 10 Mar 2015 12:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJp-8-0PlfEr; Tue, 10 Mar 2015 12:48:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BBC91A8797; Tue, 10 Mar 2015 12:48:55 -0700 (PDT) Received: from BN1AFFO11FD049.protection.gbl (10.58.52.30) by BN1AFFO11HUB036.protection.gbl (10.58.52.147) with Microsoft SMTP Server (TLS) id 15.1.112.13; Tue, 10 Mar 2015 19:48:36 +0000 Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by BN1AFFO11FD049.mail.protection.outlook.com (10.58.53.64) with Microsoft SMTP Server (TLS) id 15.1.112.13 via Frontend Transport; Tue, 10 Mar 2015 19:48:35 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t2AJgqhU003951 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2015 14:42:53 -0500 Received: from PREWE13M07.ad.sprint.com (prewe13m07.corp.sprint.com [144.226.128.26]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id t2AJgp6B028783 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Mar 2015 14:42:52 -0500 Received: from PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) by PREWE13M07.ad.sprint.com (2002:90e2:801a::90e2:801a) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 10 Mar 2015 15:42:50 -0400 Received: from PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216]) by PLSWE13M08.ad.sprint.com ([fe80::948e:8473:1735:b216%15]) with mapi id 15.00.0995.028; Tue, 10 Mar 2015 14:42:50 -0500 From: "Gorman, Pierce A [CTO]" To: Richard Shockey , Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Thread-Topic: [dispatch] CNIT and Modern Charter Thread-Index: AQHQWp3ul5him8B2KUGtFEmSTKBzBp0UtHzwgAGxCoD//61e4IAAXteA//+sosA= Date: Tue, 10 Mar 2015 19:42:49 +0000 Message-ID: References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> <13c4861265204b8faee6af46ce62af9a@PLSWE13M08.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.21] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.229.32.57 as permitted sender) receiver=protection.outlook.com; client-ip=144.229.32.57; helo=pdaasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.57) smtp.mailfrom=Pierce.Gorman@sprint.com; ietf.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:144.229.32.57; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(438002)(53824002)(199003)(377454003)(24454002)(479174004)(51704005)(189002)(13464003)(54356999)(50986999)(76176999)(19580395003)(93886004)(92726002)(62966003)(15975445007)(46102003)(92566002)(2950100001)(102836002)(2900100001)(77156002)(106116001)(19580405001)(6806004)(23676002)(2656002)(86362001)(87936001)(15974865002)(2201001)(107886001)(5250100002)(106466001)(551934003)(2501003)(47776003)(33646002)(50466002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB036; H:pdaasdm2.corp.sprint.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1AFFO11HUB036; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:BN1AFFO11HUB036; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB036; X-Forefront-PRVS: 051158ECBB X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2015 19:48:35.9716 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.229.32.57]; Helo=[pdaasdm2.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB036 Archived-At: Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:49:01 -0000 V2h5PyAgQSBjb21tb24gc2NhbSBpcyB0byBnZXQgc29tZW9uZSB0byBjYWxsLCB0ZXh0LCBlLW1h aWwsIGJyb3dzZSwgdG8gYSBsb2NhdGlvbiBvZiBiYWQgYWN0aW9ucy4gIElmIHRoZXJlIHdhcyBz b21ld2F5IHRvIGF1dGhlbnRpY2F0ZSB0aGF0IHRoZSBjYWxsZXIgaGFzbid0IGFjdHVhbGx5IHJl YWNoZWQgdGhlICJyZWFsIiBCYW5rIG9mIEFtZXJpY2EsIG9yIHdoYXRldmVyLCB0aGVyZSBpcyBz b21lIHZhbHVlIHRvIHRoZSBjb25zdW1lci4gIEp1c3QgYSB0aG91Z2h0LiAgVExTIGluY2x1ZGVz IGEgbm9kIHRvIG11dHVhbCBhdXRoZW50aWNhdGlvbi4gIEkgd2FzIGp1c3QgdHJ5aW5nIHRvIHRo aW5rIG1vcmUgYWJvdXQgInRydXN0IG1vZGVscyIgYW5kIHdoYXQgdGhleSBjYW4vc2hvdWxkIGxv b2sgbGlrZS4NCg0KQmVzdCByZWdhcmRzLA0KDQoNClBpZXJjZSBHb3JtYW4NClZvaWNlIEFyY2hp dGVjdHVyZQ0KQ29yZSBQbGFubmluZy9TcHJpbnQNCjkxMy00MzktNDM2OCAoRGVzaykNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJpY2hhcmQgU2hvY2tleSBbbWFpbHRvOnJp Y2hhcmRAc2hvY2tleS51c10NClNlbnQ6IE1hcmNoIDEwLCAyMDE1IDI6MzcgUE0NClRvOiBHb3Jt YW4sIFBpZXJjZSBBIFtDVE9dOyBDdWxsZW4gSmVubmluZ3M7IGNuaXRAaWV0Zi5vcmc7IGRpc3Bh dGNoQGlldGYub3JnOyBtb2Rlcm5AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIENO SVQgYW5kIE1vZGVybiBDaGFydGVyDQoNCg0KQXMgYSBtYXR0ZXIgb2YgcHJpbmNpcGFsIEkgd291 bGRu4oCZdCBydWxlIGFueXRoaW5nIGxpa2UgdGhpcyBvdXQgYnV0IHRoZXJlIGNvdWxkIGJlIHNv bWUgcGhpbHNoaW5nIGlzc3Vlcy4NCg0KTXkgcXVlc3Rpb24gd291bGQgYmUgd2h5PyAgU29ydCBv ZiBsaWtlIHRoZSBvbGQgb3V0IG9mIGJhbmQgU1RJUiBpZGVhIHRoYXQgSeKAmW0gY29udmluY2Vk IGlzIGdvaW5nIG5vIHdoZXJlLg0KDQpJ4oCZZCBsaWtlIHRvIGZpeCBvbmUgc2ltcGxlIHByb2Js ZW0gcmVhc29uYWJseSBxdWlja2x5Lg0KDQoNCg0KT24gMy8xMC8xNSwgMjo1OCBQTSwgIkdvcm1h biwgUGllcmNlIEEgW0NUT10iIDxQaWVyY2UuR29ybWFuQHNwcmludC5jb20+DQp3cm90ZToNCg0K PlNob3VsZCB0aGVyZSBiZSBtdXR1YWwgYXV0aGVudGljYXRpb24/ICBTaG91bGQgdGhlIGNhbGxp bmcgcGFydHkNCj5yZWNlaXZlIGEgY2FsbGVkIHBhcnR5IGlkZW50aXR5Pw0KPg0KPkJlc3QgcmVn YXJkcywNCj4NCj4NCj5QaWVyY2UgR29ybWFuDQo+Vm9pY2UgQXJjaGl0ZWN0dXJlDQo+Q29yZSBQ bGFubmluZy9TcHJpbnQNCj45MTMtNDM5LTQzNjggKERlc2spDQo+DQo+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj5Gcm9tOiBSaWNoYXJkIFNob2NrZXkgW21haWx0bzpyaWNoYXJkQHNob2Nr ZXkudXNdDQo+U2VudDogTWFyY2ggMTAsIDIwMTUgMTo1MyBQTQ0KPlRvOiBHb3JtYW4sIFBpZXJj ZSBBIFtDVE9dOyBDdWxsZW4gSmVubmluZ3M7IGNuaXRAaWV0Zi5vcmc7DQo+ZGlzcGF0Y2hAaWV0 Zi5vcmc7IG1vZGVybkBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIENOSVQgYW5k IE1vZGVybiBDaGFydGVyDQo+DQo+DQo+RXhhY3RseeKApiBzdHVkeWluZyB0aGUgdHJ1c3QgbW9k ZWxzIGFyZSBwZXJmZWN0bHkgYXBwcm9wcmlhdGUuDQo+T2J2aW91c2x5IHRoZSBjYWxsaW5nIHBh cnR5IGRhdGEgY2FuIGNvbWUgZnJvbSBkaWZmZXJlbnQgc291cmNlcyB0aG91Z2gNCj5JIHN1c3Bl Y3QgaW4gaXRzIGVhcmxpZXN0IG1vZGVscyBpdCBjb21lcyBmcm9tIHRoZSBvcmlnaW5hdGluZyBz ZXJ2aWNlDQo+cHJvdmlkZXIgdGhyb3VnaCB0aGUgU0lQIHNpZ25hbGluZyBtZWNoYW5pc20gdG8g dGhlIHRlcm1pbmF0aW5nIENVQS4NCj5Fc3BlY2lhbGx5IGluIHRoZSBWb0xURSBjYXNlLg0KPg0K PkVudGVycHJpc2UgdG8gRW50ZXJwcmlzZSB3b3VsZCBjbGVhcmx5IGJlIGRpZmZlcmVudC4gIENl cnRhaW5seSAzcmQNCj5wYXJ0eSBkYXRhYmFzZXMgY291bGQgYmUgaW52b2x2ZWQgaW4gc29tZSB3 YXkuDQo+DQo+SSB3b3VsZCByZW1pbmQgZm9sa3MgdGhhdCB0aGUgcmF0aW9uYWxlIGZvciB0aGlz IGlzIGNvbnN1bWVycyBhbmQNCj5OYXRpb25hbCBSZWd1bGF0b3JzIGFyZSBOT1QgSEFQUFkgQVQg QUxMIHdpdGggdGhlIGN1cnJlbnQgc3RhdGUgb2YgaG93DQo+Y2FsbGluZyBwYXJ0eSBkYXRhIGlz IHByZXNlbnRlZCB0byB0aGUgY29uc3VtZXIuIFNUSVIgaW4gYW5kIG9mIGl0c2VsZg0KPmlzIG5v dCBlbm91Z2guICBUaGlzIGlzIHVsdGltYXRlbHkgYSBjb25zdW1lciBwcm90ZWN0aW9uIGlzc3Vl Lg0KPg0KPg0KPg0KPg0KPk9uIDMvOS8xNSwgNjoyNSBQTSwgIkdvcm1hbiwgUGllcmNlIEEgW0NU T10iIDxQaWVyY2UuR29ybWFuQHNwcmludC5jb20+DQo+d3JvdGU6DQo+DQo+PkkgZG9uJ3QgaGF2 ZSBhbnkgdXNlZnVsIGNoYXJ0ZXIgdGV4dC4NCj4+SSBhZ3JlZSB0aGF0IHRoZSBJRVRGIHNob3Vs ZCBub3QgcHJvcG9zZSBidXNpbmVzcyBtb2RlbHMsIGJ1dCBpdCBzZWVtcw0KPj5pbXBvcnRhbnQg dG8gY29uc2lkZXIgdHJ1c3QgbW9kZWwocykgdG8gc2VlIGlmIGl0L3RoZXkgZHJpdmUgcHJvdG9j b2wNCj4+Y29uc2lkZXJhdGlvbnMuDQo+PldlIGNvdWxkIHN0YXJ0IHdpdGggbGlzdGluZyBhc3N1 bXB0aW9ucy4gIEknbGwgc3RhcnQgYnkgbGlzdGluZyB0d28uDQo+PiAgICAgMSkgSSBhc3N1bWUg dGhlcmUgd291bGQgYmUgbXVsdGlwbGUgYXV0aG9yaXRpZXMgYW5kIG11bHRpcGxlDQo+PmxldmVs cyBvZiB0cnVzdC4NCj4+ICAgICAyKSBJIGFzc3VtZSB0aGVyZSBhcmUgaW50ZXJuYXRpb25hbCB0 cmFkZW5hbWUsIGFuZCB0cmFkZW1hcmsgYW5kDQo+PnRoZSBhZm9yZW1lbnRpb25lZCBVVEYtOCBp bnRlcm5hdGlvbmFsIGNoYXJhY3RlciBjb2RlIHNwb29maW5nDQo+PmNvbnNpZGVyYXRpb25zLg0K Pj4NCj4+DQo+PkJlc3QgcmVnYXJkcywNCj4+DQo+Pg0KPj5QaWVyY2UgR29ybWFuDQo+PlZvaWNl IEFyY2hpdGVjdHVyZQ0KPj5Db3JlIFBsYW5uaW5nL1NwcmludA0KPj45MTMtNDM5LTQzNjggKERl c2spDQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBNb2Rlcm4gW21h aWx0bzptb2Rlcm4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQNCj4+U2hv Y2tleQ0KPj5TZW50OiBNYXJjaCAwOSwgMjAxNSAyOjE4IFBNDQo+PlRvOiBDdWxsZW4gSmVubmlu Z3M7IGNuaXRAaWV0Zi5vcmc7IGRpc3BhdGNoQGlldGYub3JnOyBtb2Rlcm5AaWV0Zi5vcmcNCj4+ U3ViamVjdDogUmU6IFtNb2Rlcm5dIFtkaXNwYXRjaF0gQ05JVCBhbmQgTW9kZXJuIENoYXJ0ZXIN Cj4+DQo+Pg0KPj5UaGUgZmlyc3Qgb3JkZXIgaXNzdWUgaXMgcHJvcGVybHkgZGVmaW5pbmcgd2hh dCB0aGlzIGxvb2tzIGxpa2UgaW4gU0lQDQo+PmFuZCB3aGVyZSBpbiB0aGUgaGVhZGVycyBpdCBz aG91bGQgcmVzaWRlLiBUaGVyZSBpcyBhbXBsZSBldmlkZW5jZQ0KPj50aGF0IGFueSBudW1iZXIg b2Ygb3RoZXIgU0RPIGFyZSBsb29raW5nIGF0IHRoaXMgYW5kIHdpdGhvdXQgc29tZQ0KPj5wcm9w ZXIgc3RhbmRhcmRpemF0aW9uIHRoZXJlIHdpbGwgYmUgbm8gaW50ZXJvcGVyYWJpbGl0eSBhdCBh bGwNCj4+ZXNwZWNpYWxseSBldmVuIGZvciBTVElSIHZhbGlkYXRpb24gZGF0YSBhdCB0aGUgQ1VB IGFuZCBJTUhPIGRvaW5nDQo+Pm5vdGhpbmcgaXMgbm90IGEgdmlhYmxlIG9wdGlvbi4gVGhlIGJh c2ljIEZST00gYW5kIFBBSSB1c2FnZSBpcyBub3QgaGVscGZ1bC4NCj4+DQo+PldlIGFyZSBhbGwg YXdhcmUgb2YgaG93IHNtYXJ0IHBob25lcyB3b3JrLiBUaGlzIGlzIHByaW5jaXBhbGx5IGFib3V0 DQo+PnNlc3Npb25zIHRoYXQgd291bGQgb3JpZ2luYXRlIG91dHNpZGUgYSBzZWxlY3QgbnVtYmVy IG9mIHBob25lIGJvb2sNCj4+ZW50cmllcyBhbmQgc29tZSBkaXNwbGF5IG9mIHdoZXRoZXIgdGhh dCBpbmZvcm1hdGlvbiBoYXMgYmVlbg0KPj52YWxpZGF0ZWQgdGhvdWdoIHdlIGRvbsK5dCBoYXZl IHRvIGRlZmluZSBwb2xpY3kgYXQgdGhpcyBzdGFnZSBhbmQNCj4+ZnJhbmtseSBJIGRvbsK5dCB0 aGluayB0aGUgSUVURiBzaG91bGQgdHJ5IGFueSBtb3JlIHRoYW4gaXQgY291bGQgdHJ5DQo+PmFu ZCBlc3RhYmxpc2ggdGhlIGJ1c2luZXNzIG1vZGVsIGZvciBob3cgdGhpcyB3b3VsZCBkZXBsb3ku DQo+Pg0KPj5UaGUgcHVycG9zZSBoZXJlIGlzIHNpbXBseSBhZGRpbmcgbW9yZSBpbmZvcm1hdGlv biBhYm91dCB3aG8NCj4+b3JpZ2luYXRlZCB0aGUgc2Vzc2lvbiBzbyB0aGUgY2FsbGVkIHBhcnR5 IGhhcyBtb3JlIGluZm9ybWF0aW9uIHRoYW4NCj4+dGhleSBjdXJyZW50bHkgaGF2ZS4gIFdlIGFs cmVhZHkgaGF2ZSBlbm91Z2ggYmFkIGFjdG9ycyBhcyBpdCBpcw0KPj5pbXBlcnNvbmF0aW5nIHRh eCBhdXRob3JpdGllcywgYmFua3MsIGhlYWx0aCBjYXJlIHByb2Zlc3Npb25hbHMgYW5kDQo+Pm90 aGVyIGdvdmVybm1lbnRhbCBlbnRpdGllcy4gVGhlIHB1cnBvc2UgaXMgdG8gdHJ5IGFuZCBib3Vu ZCB0aG9zZQ0KPj5wcm9ibGVtcyB0byBhIG1hbmFnZWFibGUgbGV2ZWwuICBUaGVyZSBpcyBubyBz aWx2ZXIgYnVsbGV0IGhlcmUuDQo+Pg0KPj5JIHdvdWxkIGFwcHJlY2lhdGUgYW55IHN1Z2dlc3Rp b25zIG9uIGNoYXJ0ZXIgdGV4dCBpZiB5b3UgaGF2ZSB0aGVtLg0KPj4NCj4+DQo+Pg0KPj7igLkN Cj4+UmljaGFyZCBTaG9ja2V5DQo+PlNob2NrZXkgQ29uc3VsdGluZyBMTEMNCj4+Q2hhaXJtYW4g b2YgdGhlIEJvYXJkIFNJUCBGb3J1bQ0KPj53d3cuc2hvY2tleS51cw0KPj53d3cuc2lwZm9ydW0u b3JnDQo+PnJpY2hhcmQ8YXQ+c2hvY2tleS51cw0KPj5Ta3lwZS1MaW5rZWRpbi1GYWNlYm9vayBy c2hvY2tleTEwMQ0KPj5QU1ROICsxIDcwMy01OTMtMjY4Mw0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+ Pk9uIDMvOS8xNSwgMTE6MTAgQU0sICJDdWxsZW4gSmVubmluZ3MiIDxmbHVmZnlAY2lzY28uY29t PiB3cm90ZToNCj4+DQo+Pj4NCj4+Pk9uIHRoZSBwYXJ0aWN1bGFyIENOQU0gbGlrZSB0b3BpYyAu Li4NCj4+Pg0KPj4+SSdtIG5vdCBrZWVuIG9uIG1vdmluZyBmb3J3YXJkIHdpdGggc29tZXRoaW5n IGxpa2UgdGhpcyB1bmxlc3Mgd2UgY2FuDQo+Pj5zaG93IHRoZSB0cnVzdCBhbmQgaHVtYW4gZmFj dG9ycyBpc3N1ZXMgaXMgYW4gZW5naW5lZXJpbmcgcHJvYmxlbSBub3QNCj4+PmEgcmVzZWFyY2gg cHJvYmxlbS4gV2UgaGF2ZSBzZWVuIHRoZSBkaWZmaWN1bHR5IHdpdGggaHVtYW4gcmVhZGFibGUN Cj4+Pm5hbWVzIGluIFNQQU0uIFBhcnRpY3VsYXJseSB3aGVuIHVzaW5nIFVURi04LCBob3cgZG8g d2Ugc3RvcCBiYWQNCj4+PmFjdG9yIGdldHRpbmcgbmFtZXMgdGhhdCBsb29rIHRoZSBzYW1lIGFz IHNvbWVvbmUgdGhleSB3aXNoIHRvIGltcGVyc29uYXRlPw0KPj4+V2hvIHdpbGwgdmFsaWRhdGUg dGhlIG5hbWVzIGFuZCBpc3N1ZSBzb21lIHNvcnQgb2YgdHJ1c3QgdG9rZW4gdGhhdA0KPj4+c2F5 cyBJIGNhbiB1c2UgIkN1bGxlbiBKZW5uaW5ncyIgb3Igd2hhdGV2ZXIuIFdobyBlbHNlIGNhbiB1 c2UgdGhhdA0KPj4+bmFtZSBhbmQgd2hhdCBhYm91dCBuYW1lcyB2aXN1YWxseSBzaW1pbGFyIHRv IGl0Lg0KPj4+DQo+Pj5PbiB0aGUgZmxpcCBzaWRlIHdlIGFyZSBzZWVpbmcgbW9zdCBzbWFydCBw aG9uZXMgdGFrZSB0aGUgaW5jb21pbmcNCj4+PnBob25lIG51bWJlciwgYW5kIGxvb2sgaXQgdXAg dGhlIHBlcnNvbmFsIGFkZHJlc3MgYm9vayBvZiB0aGUgdXNlcg0KPj4+YW5kIGRpc3BsYXkgdGhl IG5hbWUgdGhhdCB0aGUgdXNlciBvZiB0aGUgc21hcnRwaG9uZSBhc3NpZ25lZC4gV2UgYXJlDQo+ Pj5zZWVpbmcgZW50ZXJwcmlzZSBwaG9uZXMgdGhhdCBkbyBhIHNpbWlsYXIgdGhpbmdzIHVzaW5n IHRoZSB1c2Vycw0KPj4+c29jaWFsIG5ldHdvcmtzIGFzIHdlbGwgYXMgcGVyc29uYWwgYWRkcmVz cyBib29rLg0KPj4+DQo+Pj5XaGF0IHdvdWxkIGJlIGJhZCBpcyBwaG9uZSBkaXNwbGF5IGEgZGlz cGxheSBuYW1lIHRoYXQgc29tZSBob3cNCj4+PmNsYWltZWQgdG8gYmUgdHJ1c3RhYmxlIGJ1dCB3 YXMgbm90LiBUaGF0IHdvdWxkIGJlIHdvcnNlIHRoYXQgdGhlDQo+Pj5jdXJyZW50IHNpdHVhdGlv bi4gUGVyaGFwcyBwZW9wbGUgaGF2ZSBhIGdvb2Qgd2F5IHRvIHNvbHZlIHRoaXMgaW4NCj4+Pm1p bmQgYnV0IEknbSBub3Qgc2VlaW5nIHRoYXQgdGhhdCBpcy4NCj4+Pg0KPj4+Q3VsbGVuICh3aXRo IG15IGluZGl2aWR1YWwgY29udHJpYnV0ZSBoYXQgb24gb2YgY291cnNlKQ0KPj4+DQo+Pj4NCj4+ Pg0KPj4+PiBPbiBGZWIgMjUsIDIwMTUsIGF0IDEwOjA1IEFNLCBSaWNoYXJkIFNob2NrZXkgPHJp Y2hhcmRAc2hvY2tleS51cz4NCj4+Pj53cm90ZToNCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhhbmtzIE1h cnRpbiAuLiBUaGlzIGlzIG15IHZlcnkgcmF3IGZpcnN0IGN1dCBhdCBhIGNoYXJ0ZXIuIEl0cw0K Pj4+PmhvcGVmdWxseSBzaW1wbGUgYW5kIHN0cmFpZ2h0IGZvcndhcmQuDQo+Pj4+DQo+Pj4+IFNl bmQgbWUgYW55IGVkaXRzIGV0Yy4NCj4+Pj4NCj4+Pj4gKioqKioNCj4+Pj4NCj4+Pj4gQ05JVCBD aGFydGVyIFtDYWxsaW5nIE5hbWUgSWRlbnRpdHkgVHJ1c3RdDQo+Pj4+DQo+Pj4+IFdHIENoYWly cyBUQkQ6DQo+Pj4+DQo+Pj4+IENhbGxpbmcgTmFtZSBEZWxpdmVyeSBbQ05BTV0gaXMgYSBzdHJp bmcgb2YgdXAgdG8gMTUgQVNDSUkNCj4+Pj5DaGFyYWN0ZXJzIG9mIGluZm9ybWF0aW9uIGFzc29j aWF0ZWQgd2l0aCBhIHNwZWNpZmljIEUuMTY0IGNhbGxpbmcNCj4+Pj5wYXJ0eSBudW1iZXIgaW4g dGhlIFB1YmxpYyBTd2l0Y2hlZCBUZWxlcGhvbmUgTmV0d29yayBbUFNUTl0uICBJbg0KPj4+PnRo ZSBQU1ROIHRoaXMgZGF0YSBpcyBzZW50IGJ5IHRoZSBvcmlnaW5hdGluZyBuZXR3b3JrIG9ubHkg YXQgdGhlDQo+Pj4+c3BlY2lmaWMgcmVxdWVzdCBvZiB0aGUgdGVybWluYXRpbmcgbmV0d29yayB2 aWEgYSBTUzcgVHJhbnNhY3Rpb24NCj4+Pj5BcHBsaWNhdGlvbiBQYXJ0IFtUQ0FQXSByZXNwb25z ZSBtZXNzYWdlLiAgSW4gdGhlIFNlc3Npb24gSW5pdGlhdGlvbg0KPj4+PlByb3RvY29sIFtTSVBd IHRoaXMgaW5mb3JtYXRpb24gY2FuIGJlIGluc2VydGVkIGludG8gdGhlIEZST006IHBhcnQNCj4+ Pj5vZiB0aGUgb3JpZ2luYXRpbmcgSU5WSVRFIG1lc3NhZ2Ugb3IgYnkgb3RoZXIgbWVhbnMuDQo+ Pj4+DQo+Pj4+IEFzIHdpdGggdGhlIG9yaWdpbmF0aW5nIHNvdXJjZSB0ZWxlcGhvbmUgbnVtYmVy LCB0aGlzIGRhdGEgY2FuIGJlDQo+Pj4+YWx0ZXJlZCBpbiB0cmFuc2l0IGNyZWF0aW5nIGEgdmFy aWV0eSBvZiBtYWxpY2lvdXMgYWJ1c2VzIHNpbWlsYXIgdG8NCj4+Pj50aGUgb25lcyBpZGVudGlm aWVkIGJ5IHRoZSBJRVRGIFNUSVIgd29ya2luZyBncm91cC4NCj4+Pj4NCj4+Pj4gVGhlIHB1cnBv c2Ugb2YgdGhlIENOSVQgd29ya2luZyBncm91cCB3aWxsIGJlIHRvIGRlZmluZSBhIGRhdGENCj4+ Pj5zdHJ1Y3R1cmUsIGEgbmV3IFNJUCBoZWFkZXIgb3IgcmVwdXJwb3NlIGFuIGV4aXN0aW5nIFNJ UCBoZWFkZXIgdG8NCj4+Pj5jYXJyeSBhbiBhZHZhbmNlZCBmb3JtIG9mIENOQU0gYXMgd2VsbCBh cyBpbmZvcm1hdGlvbiBmcm9tIGEgU1RJUg0KPj4+PlZhbGlkYXRpb24gQXV0aG9yaXR5LiAgVGhl IHB1cnBvc2Ugb2YgdGhpcyB3b3JrIGlzIHRvIHByZXNlbnQgdG8gdGhlDQo+Pj4+U0lQIGNhbGxl ZCBwYXJ0eSB0cnVzdGVkIGluZm9ybWF0aW9uIGZyb20gdGhlIGNhbGxpbmcgcGFydHkgaW4gb3Jk ZXINCj4+Pj50aGF0IHRoZSBjYWxsZWQgcGFydHkgbWFrZSBhIG1vcmUgcmVhc29uZWQgYW5kIGlu Zm9ybWVkIGp1ZGdtZW50IG9uDQo+Pj4+d2hldGhlciB0byBhY2NlcHQgdGhlIElOVklURSBvciBu b3QuDQo+Pj4+DQo+Pj4+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgbm90IGludmFsaWRhdGUgYW55 IGV4aXN0aW5nIFNJUCBtZWNoYW5pc20NCj4+Pj5mb3IgYW5vbnltb3VzIGNhbGxpbmcuDQo+Pj4+ DQo+Pj4+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwsIHRvIHRoZSBiZXN0IG9mIGl0cyBhYmlsaXR5 LCByZXVzZSBleGlzdGluZw0KPj4+PklFVEYgcHJvdG9jb2xzLg0KPj4+Pg0KPj4+PiBGdWxsIElu dGVybmF0aW9uYWxpemF0aW9uIG9mIHRoZSBDYWxsaW5nIE5hbWUgSWRlbnRpdHkgVHJ1c3QgZGF0 YQ0KPj4+Pm9iamVjdChzKSBpcyBhIHJlcXVpcmVtZW50Lg0KPj4+Pg0KPj4+PiBUaGUgd29ya2lu ZyBncm91cCB3aWxsIGNsb3NlbHkgd29yayB3aXRoIHRoZSBJRVRGIFNUSVIgd29ya2luZw0KPj4+ PiBncm91cA0KPj4+Pg0KPj4+PiBUaGUgd29ya2luZyBncm91cCB3aWxsIGltbWVkaWF0ZWx5IGxp YWlzb24gd2l0aCAzR1BQIFNBLTEgaW4gb3JkZXINCj4+Pj50byBjb29yZGluYXRlIGVmZm9ydHMu DQo+Pj4+DQo+Pj4+IFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29vcmRpbmF0ZSB3aXRoIE5hdGlv bmFsIE51bWJlcmluZw0KPj4+PkF1dGhvcml0aWVzIGFuZCBOYXRpb25hbCBSZWd1bGF0b3J5IEF1 dGhvcml0aWVzIGFzIG5lZWRlZC4NCj4+Pj4NCj4+Pj4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBk ZWxpdmVyIHRoZSBmbG93aW5nLg0KPj4+Pg0KPj4+PiDigqxBIHByb2JsZW0gc3RhdGVtZW50IGFu ZCByZXF1aXJlbWVudHMgZGV0YWlsaW5nIHRoZSBjdXJyZW50DQo+Pj4+ZGVwbG95bWVudCBlbnZp cm9ubWVudCBhbmQgc2l0dWF0aW9ucyB0aGF0IG1vdGl2YXRlIHdvcmsgb24gQ2FsbGluZw0KPj4+ Pk5hbWUgSWRlbnRpdHkgVHJ1c3QuDQo+Pj4+IOKCrERlZmluZSBlaXRoZXIgYSBuZXcgU0lQIGhl YWRlciBvciBkb2N1bWVudCBhIHJlcHVycG9zZSBvZiBhbiBTSVANCj4+Pj5leGlzdGluZyBoZWFk ZXIgZm9yIENhbGxpbmcgTmFtZSBJZGVudGlmeSBUcnVzdCBkYXRhICDigqxEZWZpbmUgYSBkYXRh DQo+Pj4+bW9kZWwgZm9yIHRoZSBDYWxsaW5nIE5hbWUgSWRlbnRpdHkgVHJ1c3Qgb2JqZWN0IChz KSB3aGljaCBtYXkNCj4+Pj5pbmNsdWRlIHZhcmlvdXMgZm9ybXMgb2YgbXVsdGltZWRpYSBkYXRh ICDigqxEZWxpdmVyIGFuIGFuYWx5c2lzIG9mDQo+Pj4+cHJpdmFjeSBpbXBsaWNhdGlvbnMgb2Yg dGhlIHByb3Bvc2VkIENhbGxpbmcgTmFtZSBJZGVudGl0eSBUcnVzdA0KPj4+Pm1lY2hhbmlzbS4N Cj4+Pj4NCj4+Pj4NCj4+Pj4gTWlsZXN0b25lczoNCj4+Pj4NCj4+Pj4NCj4+Pj4g4oC5DQo+Pj4+ IFJpY2hhcmQgU2hvY2tleQ0KPj4+PiBTaG9ja2V5IENvbnN1bHRpbmcgTExDDQo+Pj4+IENoYWly bWFuIG9mIHRoZSBCb2FyZCBTSVAgRm9ydW0NCj4+Pj4gd3d3LnNob2NrZXkudXMNCj4+Pj4gd3d3 LnNpcGZvcnVtLm9yZw0KPj4+PiByaWNoYXJkPGF0PnNob2NrZXkudXMNCj4+Pj4gU2t5cGUtTGlu a2VkaW4tRmFjZWJvb2sgcnNob2NrZXkxMDEgUFNUTiArMSA3MDMtNTkzLTI2ODMNCj4+Pj4NCj4+ Pj4NCj4+Pj4gRnJvbTogIkRPTExZLCBNQVJUSU4gQyIgPG1kMzEzNUBhdHQuY29tPg0KPj4+PiBE YXRlOiBUdWVzZGF5LCBGZWJydWFyeSAyNCwgMjAxNSBhdCA5OjAyIFBNDQo+Pj4+IFRvOiBSaWNo YXJkIFNob2NrZXkgPHJpY2hhcmRAc2hvY2tleS51cz4NCj4+Pj4gQ2M6ICJIb2xtZXMsIERhdmlk IFcgW0NUT10iIDxEYXZpZC5Ib2xtZXNAc3ByaW50LmNvbT4sDQo+Pj4+ImRpc3BhdGNoQGlldGYu b3JnIiA8ZGlzcGF0Y2hAaWV0Zi5vcmc+LCAibW9kZXJuQGlldGYub3JnIg0KPj4+Pjxtb2Rlcm5A aWV0Zi5vcmc+LCAiUGV0ZXJzb24sIEpvbiIgPGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpej4NCj4+ Pj4gU3ViamVjdDogUmU6IFtNb2Rlcm5dIFtkaXNwYXRjaF0gZHJhZnQgY2hhcnRlcg0KPj4+Pg0K Pj4+PiBJIHN1cHBvcnQgUmljaGFyZCBvbiB0aGlzDQo+Pj4+DQo+Pj4+IE1hcnRpbiBEb2xseQ0K Pj4+PiBMZWFkIE1lbWJlciBvZiBUZWNobmljYWwgU3RhZmYNCj4+Pj4gQ29yZSAmIEdvdid0L1Jl Z3VsYXRvcnkgU3RhbmRhcmRzDQo+Pj4+IEFUJlQgU3RhbmRhcmRzIGFuZA0KPj4+PiBJbmR1c3Ry eSBBbGxpYW5jZXMNCj4+Pj4gKzEtNjA5LTkwMy0zMzkwDQo+Pj4+IFNlbnQgZnJvbSBteSBpUGhv bmUNCj4+Pj4NCj4+Pj4gT24gRmViIDI0LCAyMDE1LCBhdCA2OjM2IFBNLCBSaWNoYXJkIFNob2Nr ZXkgPHJpY2hhcmRAc2hvY2tleS51cz4NCj4+Pj53cm90ZToNCj4+Pj4NCj4+Pj4+DQo+Pj4+PiBF eGNlbGxlbnQgcG9pbnRzIERhdmlkLg0KPj4+Pj4NCj4+Pj4+IE15IGNvbmNlcm4gaGVyZSBpcyBj aGFydGVyIG92ZXJyZWFjaC4gSSByZWFsbHkgd2FudCB0byBrZWVwDQo+Pj4+PkNOQU0rL0NOSVQg b3V0IG9mIHRoaXMuICBJTUhPIHRoYXQgaXMgYSB2ZXJ5IHNlcGFyYXRlIGFuZCBoaWdobHkNCj4+ Pj4+Zm9jdXNlZCBlZmZvcnQgdG8gZGVmaW5lIGJvdGggdGhlIG1vZGlmaWNhdGlvbiBvZiB0aGUg U0lQIGhlYWRlcnMNCj4+Pj4+bmVjZXNzYXJ5IHRvIHN1cHBvcnQgc29tZSBlbmhhbmNlZCBjYWxs aW5nIHBhcnR5IGlkZW50aWZpY2F0aW9uIGFuZA0KPj4+Pj5hIHZlcnkgbGltaXRlZCBlZmZvcnQg dG8gZGVmaW5lIHRoZSBvYmplY3QgYW5kIG9yIHRoZSBTVElSIHZhbGlkYXRpb24NCj4+Pj4+ZGF0 YS4NCj4+Pj4+DQo+Pj4+PiBJwrltIHZpb2xlbnRseSBvcHBvc2VkIHRvIMKzZW5kIHdvcmxkIGh1 bmdlcsKyIFdHwrlzLg0KPj4+Pj4NCj4+Pj4+IElmIHJlZ2lzdHJpZXMgY2FuIGJlIHVzZWQgZmlu ZSBidXQgSSBjZXJ0YWlubHkgd2FudCB0byBzZWUgaG93IHRoaXMNCj4+Pj4+Y2FuIGJlIGFjY29t cGxpc2hlZCBpbiBiaSBsYXRlcmFsIGFncmVlbWVudHMgYmV0d2VlbiBjb25zZW50aW5nDQo+Pj4+ PnNlcnZpY2UgcHJvdmlkZXJzIGFuZCB3b3JrIHdpdGggQ1VBIHZlbmRvcnMgb24gaG93IHRoZSBk YXRhIGlzDQo+Pj4+PmRpc3BsYXllZCBha2EgQXBwbGUsIFNhbXN1bmcsIE1pY3Jvc29mdCBpbiB0 aGUgY29udGV4dCBvZiBhIGZvcm1hbA0KPj4+Pj5saWFpc29uIHdpdGggM0dQUC4NCj4+Pj4+IENl cnRhaW5seSB0aGUgcmVsZXZhbmNlIG9mIENOQU0rL0NOSVQgaW4gZW50ZXJwcmlzZSBhbmQgcmVz aWRlbnRpYWwNCj4+Pj4+YWNjZXNzIG1hcmtldHMgaXMgaW1wb3J0YW50IGJ1dCB3ZSBhbGwga25v dyDCs01vbmV5IGlzIHRoZSBhbnN3ZXINCj4+Pj4+d2hhdCBpcyB0aGUgIHF1ZXN0aW9uIC4uwrIN Cj4+Pj4+DQo+Pj4+PiBJwrl2ZSBhc2tlZCBmb3IgdGltZSBpbiBEaXNwYXRjaCB0byBsb29rIGF0 IHRoZSBDTkFNL0NOSVQgaXNzdWUgYW5kDQo+Pj4+PnJlcG9ydCBvbiB0aGUgSlRGIG9uIE5OSS4g QXMgeW91IHdlbGwga25vdyB3ZSBoYXZlIG1hZGUgY29uc2lkZXJhYmxlDQo+Pj4+PnByb2dyZXNz Lg0KPj4+Pj4NCj4+Pj4+IExhc3Qgd2VlayBJIGdhdmUgYSB0YWxrIG9uIHRoaXMgdG8gYSBwYW5l bCB0aGF0IGluY2x1ZGVkIG1hbnkgb2YNCj4+Pj4+b3VyIGZyaWVuZHMgYW1vbmcgdGhlIG5hdGlv bmFsIHJlZ3VsYXRvcnMuDQo+Pj4+Pg0KPj4+Pj4gaHR0cDovL2FwcHMuZmNjLmdvdi9lY2ZzL2Rv Y3VtZW50L3ZpZXc/aWQ9NjAwMDEwMzMyMTcNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IEZy b206ICJIb2xtZXMsIERhdmlkIFcgW0NUT10iIDxEYXZpZC5Ib2xtZXNAc3ByaW50LmNvbT4NCj4+ Pj4+IERhdGU6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI0LCAyMDE1IGF0IDU6MDYgUE0NCj4+Pj4+IFRv OiAiUGV0ZXJzb24sIEpvbiIgPGpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpej4sICJtb2Rlcm5AaWV0 Zi5vcmciDQo+Pj4+Pjxtb2Rlcm5AaWV0Zi5vcmc+DQo+Pj4+PiBTdWJqZWN0OiBSZTogW01vZGVy bl0gZHJhZnQgY2hhcnRlcg0KPj4+Pj4NCj4+Pj4+IEpvbiwNCj4+Pj4+DQo+Pj4+PiBUaGFuayB5 b3UgZm9yIHRoZSB3b3JrIGluIGFzc2VtYmxpbmcgdGhpcyBkcmFmdCBvZiB0aGUgY2hhcnRlciBm b3INCj4+Pj4+TU9ERVJOLg0KPj4+Pj4NCj4+Pj4+IFdlIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCBz b21lIG1pbm9yIGNsYXJpZmljYXRpb25zIHRvIHRoZSBidWxsZXRzDQo+Pj4+PmRlc2NyaWJpbmcg dGhlIGRlbGl2ZXJhYmxlcywgdG8gYWxpZ24gdGhlbSB3aXRoIHRoZSBzdGF0ZW1lbnQNCj4+Pj4+ cmVnYXJkaW5nIGZsZXhpYmlsaXR5IHRvIHN1cHBvcnQgdGhlIG5lZWRzIG9mIGRpZmZlcmVudCBy ZWd1bGF0b3J5DQo+Pj4+PnJlZ2ltZXMsICYgdGh1cyB0byBlbnN1cmUgdGhhdCBpZiBxdW90ZWQg YWxvbmUgdGhleSBhcmUgbm90IHRha2VuDQo+Pj4+Pm91dCBvZiBjb250ZXh0OyBpLmUuIHRoZSBn cm91cCBwcm9kdWN0IHdpbGwgYmUgdGhlIHByb3RvY29scyB0bw0KPj4+Pj5zdXBwb3J0IHRoZSBh bGxvY2F0aW9uIGV0Yy4gYWN0aXZpdGllcywgJiBpdCB3b3VsZCBub3QgYXR0ZW1wdCB0bw0KPj4+ Pj5kZWZpbmUgdGhlIGFsbG9jYXRpb24gcHJvY2Vzc2VzLiAgV2UgYWxzbyB3b3VsZCBsaWtlIHRo ZSBjaGFydGVyIHRvDQo+Pj4+Pm5vdGUgdGhlIHJlbGV2YW50IHdvcmsgdGhhdCBoYXMgYWxyZWFk eSBiZWVuIHBlcmZvcm1lZCBieSBib3RoIElFVEYNCj4+Pj4+JiB0aGUgQVRJUy9TSVAgRm9ydW0g SlRGLCAmIGluY29ycG9yYXRlIHRoYXQgaW50byB0aGUgb3V0cHV0IGZyb20gdGhlDQo+Pj4+Pk1P REVSTiBXRyBhcyBhcHByb3ByaWF0ZS4NCj4+Pj4+VGhlc2UgY2hhbmdlcy9hZGRpdGlvbnMgYXJl IGhhdmUgYmVlbiBhZGRlZCB0byB5b3VyIHRleHQgaW5saW5lIGJlbG93Lg0KPj4+Pj4NCj4+Pj4+ IFdlIGFyZSBob3BpbmcgdGhhdCB0aGUgTU9ERVJOIHNlc3Npb24gYXQgSUVURiM5MiB3aWxsIGhh dmUgcmVtb3RlDQo+Pj4+PmFjY2VzcywgdG8gYWxsb3cgcGFydGljaXBhdGlvbiBieSB0aG9zZSBv ZiB1cyB0aGF0IGNhbm5vdCBhdHRlbmQgaW4NCj4+Pj4+cGVyc29uIGR1ZSB0byBvdGhlciBjb21t aXRtZW50cyB0aGF0IHdlZWsuDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+DQo+Pj4+PiBE YXZpZC9TcHJpbnQNCj4+Pj4+DQo+Pj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pl9fXw0KPj4+Pj5fDQo+ Pj4+Pl9fX19fXw0KPj4+Pj4NCj4+Pj4+IEZyb206IE1vZGVybiBbbWFpbHRvOm1vZGVybi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+Pj4+UGV0ZXJzb24sIEpvbg0KPj4+Pj4gU2Vu dDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNSA5OjE5IEFNDQo+Pj4+PiBUbzogbW9kZXJu QGlldGYub3JnDQo+Pj4+PiBTdWJqZWN0OiBbTW9kZXJuXSBkcmFmdCBjaGFydGVyDQo+Pj4+Pg0K Pj4+Pj4NCj4+Pj4+IEF0IHRoZSBEYWxsYXMgSUVURiBtZWV0aW5nIGluIE1hcmNoLCB3ZSdkIGxp a2UgdG8gZ2V0IHRvZ2V0aGVyIGFuZA0KPj4+Pj50YWxrIGFib3V0IHdoYXQgYSB3b3JraW5nIGdy b3VwIGZvciBNT0RFUk4gbWlnaHQgbG9vayBsaWtlLiBBcyBhbg0KPj4+Pj5pbml0aWFsIGlucHV0 IHRvIHRoZSBkaXNjdXNzaW9uLCBhIGZldyBvZiB1cyBoYXZlIHB1dCB0b2dldGhlciBhDQo+Pj4+ PnByb3Bvc2VkIGNoYXJ0ZXIuIFdoaWxlIHRoZSBUZVJRIHdvcmsgd2FzIHBvc2l0aXZlbHkgZXZh bHVhdGVkIGluDQo+Pj4+PnRoZSBESVNQQVRDSCBwcm9jZXNzLCB3ZSBmZWVsIHRoaXMgaXMgYnJv YWRlciBlbm91Z2ggaW4gc2NvcGUgdG8NCj4+Pj4+d2FycmFudCBpdHMgb3duIEJvRi4NCj4+Pj4+ DQo+Pj4+PiBDb21tZW50cyBhcmUgd2VsY29tZSwgdGhpcyBpcyBqdXN0IGEgc3RhcnRpbmcgcG9p bnQuDQo+Pj4+Pg0KPj4+Pj4gLS0tLS0tDQo+Pj4+Pg0KPj4+Pj4gTW9kZXJuIGNoYXJ0ZXIgdGV4 dDoNCj4+Pj4+DQo+Pj4+PiBUaGUgTU9ERVJOIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgYSBz ZXQgb2YgSW50ZXJuZXQtYmFzZWQNCj4+Pj4+bWVjaGFuaXNtcyBmb3IgdGhlIHB1cnBvc2VzIG9m IG1hbmFnaW5nIGFuZCByZXNvbHZpbmcgdGVsZXBob25lDQo+Pj4+Pm51bWJlcnMNCj4+Pj4+KFRO cykgaW4gYW4gSVAgZW52aXJvbm1lbnQuICBFeGlzdGluZyBtZWNoYW5pc21zIGZvciB0aGVzZSBw dXJwb3Nlcw0KPj4+Pj5mYWNlIG9ic29sZXNjZW5jZSBhcyB0aGUgdm9pY2UgY29tbXVuaWNhdGlv bnMgaW5mcmFzdHJ1Y3R1cmUgZXZvbHZlcw0KPj4+Pj50byBJUCB0ZWNobm9sb2d5IGFuZCBuZXcg YXBwbGljYXRpb25zIGZvciBUTnMgYmVjb21lIHBvc3NpYmxlLiAgVGhlDQo+Pj4+PnRyYWRpdGlv bmFsIG1vZGVsIG9mIGEgVE4gaGF2aW5nIGFuIGFzc29jaWF0aW9uIHRvIGEgc2luZ2xlIHNlcnZp Y2UNCj4+Pj4+cHJvdmlkZXIgYW5kIGEgc2luZ2xlIGFwcGxpY2F0aW9uIGlzIGJyZWFraW5nIGRv d24uICBJdHMgdXNlIGFzIGENCj4+Pj4+bmV0d29yayBsb2NhdG9yIGlzIGdvaW5nIGF3YXksIGJ1 dCBpdHMgdXNlIGFzIGFuIGlkZW50aWZpZXIgZm9yIGFuDQo+Pj4+PmluZGl2aWR1YWwgb3IgYW4g b3JnYW5pemF0aW9uIHdpbGwgcmVtYWluIGZvciBzb21lIHRpbWUuIERldmljZXMsDQo+Pj4+PmFw cGxpY2F0aW9ucywgYW5kIG5ldHdvcmsgdG9vbHMgaW5jcmVhc2luZ2x5IG5lZWQgdG8gbWFuYWdl IFROcywNCj4+Pj4+aW5jbHVkaW5nIHJlcXVlc3RpbmcgYW5kIGFjcXVpcmluZyBUTiBkZWxlZ2F0 aW9ucyBmcm9tIGF1dGhvcml0aWVzLg0KPj4+Pj4NCj4+Pj4+IFRoZSB3b3JraW5nIGdyb3VwIHdp bGwgZGVmaW5lIGEgZnJhbWV3b3JrIGZvciB0aGUgcm9sZXMgYW5kDQo+Pj4+PmZ1bmN0aW9ucyBp bnZvbHZlZCBpbiBtYW5hZ2luZyBhbmQgcmVzb2x2aW5nIFROcyBpbiBhbiBJUA0KPj4+Pj5lbnZp cm9ubWVudC4gVGhpcyBpbmNsdWRlcyBhIHByb3RvY29sIG1lY2hhbmlzbSBmb3IgYWNxdWlyaW5n IFROcywNCj4+Pj4+d2hpY2ggd2lsbCBwcm92aWRlIGFuIGVucm9sbG1lbnQgcHJvY2VzcyBmb3Ig dGhlIGluZGl2aWR1YWxzIGFuZA0KPj4+Pj5lbnRpdGllcyB0aGF0IHVzZSBhbmQgbWFuYWdlIFRO cy4gVE5zIG1heSBlaXRoZXIgYmUgbWFuYWdlZCBpbiBhDQo+Pj4+PmhpZXJhcmNoaWNhbCB0cmVl LCBvciBpbiBhIGRpc3RyaWJ1dGVkIHBlZXItdG8tcGVlciBhcmNoaXRlY3R1cmUuDQo+Pj4+PlBy aXZhY3kgb2YgdGhlIGVucm9sbG1lbnQgZGF0YSBhbmQgc2VjdXJpdHkgb2YgdGhlIHJlc291cmNl IHdpbGwgYmUNCj4+Pj4+cHJpbWFyeSBjb25zaWRlcmF0aW9ucy4NCj4+Pj4+DQo+Pj4+PiBBZGRp dGlvbmFsbHksIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZGVsaXZlciBhIHByb3RvY29sIG1lY2hh bmlzbQ0KPj4+Pj5mb3IgcmVzb2x2aW5nIFROcyB3aGljaCB3aWxsIGFsbG93IGVudGl0aWVzIHN1 Y2ggYXMgc2VydmljZQ0KPj4+Pj5wcm92aWRlcnMsIGRldmljZXMsIGFuZCBhcHBsaWNhdGlvbnMg dG8gYWNjZXNzIGRhdGEgcmVsYXRlZCB0byBUTnMsDQo+Pj4+PnBvc3NpYmx5IGluY2x1ZGluZyBj YWxsZXIgbmFtZSBkYXRhIChDTkFNKS4gIE1haW50YWluaW5nDQo+Pj4+PnJlbGlhYmlsaXR5LCBy ZWFsIHRpbWUgYXBwbGljYXRpb24gcGVyZm9ybWFuY2UsIHNlY3VyaXR5IGFuZCBwcml2YWN5DQo+ Pj4+PmFyZSBwcmltYXJ5IGNvbnNpZGVyYXRpb25zLiAgVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCB0 YWtlIGludG8NCj4+Pj4+Y29uc2lkZXJhdGlvbiBleGlzdGluZyBJRVRGIHdvcmsgaW5jbHVkaW5n IEVOVU0sIFNQRUVSTUlOVCwgU1RJUiwgYW5kDQo+Pj4+PkRSSU5LUy4NCj4+Pj4+DQo+Pj4+PiBU aGUgd29yayBvZiB0aGlzIGdyb3VwIGlzIGxpbWl0ZWQgdG8gc3BlY2lmeWluZyBhIHNvbHV0aW9u IGZvciBUTnMNCj4+Pj4+YW5kIGNvdmVycyBhbnkgc2VydmljZSB0aGF0IGNhbiBiZSBhZGRyZXNz ZWQgdXNpbmcgYSBUTi4gIEV4cGFuZGluZw0KPj4+Pj50aGUgd29yayB0byBvdGhlciBpZGVudGlm aWVycyBpcyBvdXQgb2Ygc2NvcGUuICBTb2x1dGlvbnMgYW5kDQo+Pj4+Pm1lY2hhbmlzbXMgY3Jl YXRlZCBieSB0aGUgd29ya2luZyBncm91cCB3aWxsIGJlIGZsZXhpYmxlIGVub3VnaCB0bw0KPj4+ Pj5hY2NvbW1vZGF0ZSBkaWZmZXJlbnQgcG9saWNpZXMsIGUuZy4sIGJ5IGRpZmZlcmVudCByZWd1 bGF0b3J5DQo+Pj4+PmFnZW5jaWVzLg0KPj4+Pj4NCj4+Pj4+IFRoZSB3b3JrIGdyb3VwIHdpbGwg ZGVsaXZlciB0aGUgZm9sbG93aW5nOg0KPj4+Pj4NCj4+Pj4+IC0gICAgICAgICAgQW4gYXJjaGl0 ZWN0dXJlIG92ZXJ2aWV3IGRvY3VtZW50IHRoYXQgaW5jbHVkZXMgaGlnaCBsZXZlbA0KPj4+Pj5y ZXF1aXJlbWVudHMgYW5kIHNlY3VyaXR5L3ByaXZhY3kgY29uc2lkZXJhdGlvbnNidWlsdCBvbiB0 aGUgd29yayBvZg0KPj4+Pj5JRVRGICYgdGhlIEFUSVMvU0lQIEZvcnVtIEpURiwgdGhhdCBpbmNs dWRlZDoNCj4+Pj4+IG8gICBDYWxsIHJvdXRpbmcgYXJjaGl0ZWN0dXJlDQo+Pj4+PiBvICAgSW50 ZXItY2FycmllciBOTkkNCj4+Pj4+IG8gICBDcnlwdG9ncmFwaGljYWxseS1lbmFibGVkIEFudGkt c3Bvb2ZpbmcgKFNUSVIpDQo+Pj4+PiBvICAgRW5oYW5jZWQgQ2FsbGluZyBOYW1lIChDTklUL0NO QU0pDQo+Pj4+PiAtICAgICAgICAgIEEgZG9jdW1lbnQgZGVzY3JpYmluZyB0aGUgcHJvdG9jb2xz IHRvIHN1cHBvcnQgZW5yb2xsbWVudA0KPj4+Pj5wcm9jZXNzZXMgZm9yIGV4aXN0aW5nIGFuZCBu ZXcgVE5zIGluY2x1ZGluZyBhbnkgbW9kaWZpY2F0aW9ucyB0bw0KPj4+Pj5tZXRhZGF0YSByZWxh dGVkIHRvIHRob3NlIFROcw0KPj4+Pj4gLSAgICAgICAgICBBIGRvY3VtZW50IGRlc2NyaWJpbmcg cHJvdG9jb2wgbWVjaGFuaXNtcyBmb3IgYWNjZXNzaW5nDQo+Pj4+PmNvbnRhY3QgaW5mb3JtYXRp b24gYXNzb2NpYXRlZCB3aXRoIGVucm9sbG1lbnRzDQo+Pj4+PiAtICAgICAgICAgIEEgZG9jdW1l bnQgZGVzY3JpYmluZyBwcm90b2NvbCBtZWNoYW5pc21zIGZvciByZXNvbHZpbmcNCj4+Pj4+aW5m b3JtYXRpb24gcmVsYXRlZCB0byBUTnMNCj4+Pj4+DQo+Pj4+PiAtDQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+IFRoaXMgZS1tYWlsIG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biBpbnRlbmRlZCBmb3INCj4+Pj4+dGhlIHNvbGUgdXNlIG9mIHRoZSByZWNpcGllbnQocykuIEFu eSB1c2UgYnkgb3RoZXJzIGlzIHByb2hpYml0ZWQuDQo+Pj4+PklmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kDQo+Pj4+PmRl bGV0ZSBhbGwgY29waWVzIG9mIHRoZSBtZXNzYWdlLg0KPj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18gTW9kZXJuIG1haWxpbmcgbGlzdA0KPj4+Pj5N b2Rlcm5AaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tb2Rl cm4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+PiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4+Pj4+IGRpc3BhdGNoQGlldGYub3JnDQo+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIE1vZGVybiBt YWlsaW5nIGxpc3QNCj4+Pj5Nb2Rlcm5AaWV0Zi5vcmcNCj4+Pj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21vZGVybl9fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj5f X18NCj4+Pj5fDQo+Pj4+X19fX19fX19fX19fX19fX19fDQo+Pj4+IGRpc3BhdGNoIG1haWxpbmcg bGlzdA0KPj4+PiBkaXNwYXRjaEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5kaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4+PmRp c3BhdGNoQGlldGYub3JnDQo+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Rpc3BhdGNoDQo+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+TW9kZXJuIG1haWxpbmcgbGlzdA0KPj5Nb2Rlcm5AaWV0Zi5vcmcNCj4+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tb2Rlcm4NCj4+DQo+Pl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pg0KPj5UaGlzIGUtbWFpbCBtYXkgY29udGFp biBTcHJpbnQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZQ0KPj5zb2xl IHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpLiBBbnkgdXNlIGJ5IG90aGVycyBpcyBwcm9oaWJpdGVk LiBJZiB5b3UNCj4+YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFj dCB0aGUgc2VuZGVyIGFuZCBkZWxldGUNCj4+YWxsIGNvcGllcyBvZiB0aGUgbWVzc2FnZS4NCj4N Cj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPlRoaXMgZS1tYWls IG1heSBjb250YWluIFNwcmludCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3Ig dGhlDQo+c29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMg cHJvaGliaXRlZC4gSWYgeW91IGFyZQ0KPm5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsDQo+Y29waWVzIG9mIHRoZSBtZXNz YWdlLg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBlLW1h aWwgbWF5IGNvbnRhaW4gU3ByaW50IHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uIGludGVuZGVkIGZv ciB0aGUgc29sZSB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKS4gQW55IHVzZSBieSBvdGhlcnMgaXMg cHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhlIG1lc3NhZ2Uu DQo= From nobody Tue Mar 10 13:01:08 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5CB1A892E for ; Tue, 10 Mar 2015 13:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2mduPBCPUkT for ; Tue, 10 Mar 2015 13:01:02 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 688EC1A8925 for ; Tue, 10 Mar 2015 13:01:00 -0700 (PDT) Received: (qmail 5917 invoked by uid 0); 10 Mar 2015 20:01:00 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy6.mail.unifiedlayer.com with SMTP; 10 Mar 2015 20:01:00 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id 220t1q01M1MNPNq0120wgV; Tue, 10 Mar 2015 20:00:58 -0600 X-Authority-Analysis: v=2.1 cv=DeWE9JdW c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=emO1SXQWCLwA:10 a=izV7ms69AAAA:8 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=AUd_NHdVAAAA:8 a=zQP7CpKOAAAA:8 a=hGBaWAWWAAAA:8 a=doUQZJtgAAAA:8 a=AxLNCWWRI2xZ_7PomB4A:9 a=Bg1y9zWG01UkAtNh:21 a=q4NwGXh89CQRw-jm:21 a=QEXdDO2ut3YA:10 a=DzjOOp_o1eYA:10 a=ivbTfD_dPm4A:10 a=JpNyA6z_r-EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID:To:From:Subject:Date; bh=1dUIxM7kdknIET+WpgTbewA8ZOw1vYic7zCqkx2J5GU=; b=ivBBRWlGCWUhcndY939G3D8RMlHTa2GZkIt+0/4/sAfLViLv8nj0XRIIqQH0tMe1ZA5GOZZUMYA+NZqpHB+IYehyI7dubAUGhGeswhOQEgTUoNHJtfPEnmxYCFlPbQIO; Received: from [108.56.131.201] (port=50853 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YVQKk-0002MB-Py; Tue, 10 Mar 2015 14:00:55 -0600 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 10 Mar 2015 16:00:48 -0400 From: Richard Shockey To: "Gorman, Pierce A [CTO]" , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Message-ID: Thread-Topic: [Modern] [dispatch] CNIT and Modern Charter Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Subject: Re: [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 20:01:05 -0000 Excellent point you=E2=80=99re absolutely right. Its a perfectly valid use case. On 3/10/15, 3:42 PM, "Gorman, Pierce A [CTO]" wrote: >Why? A common scam is to get someone to call, text, e-mail, browse, to a >location of bad actions. If there was someway to authenticate that the >caller hasn't actually reached the "real" Bank of America, or whatever, >there is some value to the consumer. Just a thought. TLS includes a nod >to mutual authentication. I was just trying to think more about "trust >models" and what they can/should look like. > >Best regards, > > >Pierce Gorman >Voice Architecture >Core Planning/Sprint >913-439-4368 (Desk) > >-----Original Message----- >From: Richard Shockey [mailto:richard@shockey.us] >Sent: March 10, 2015 2:37 PM >To: Gorman, Pierce A [CTO]; Cullen Jennings; cnit@ietf.org; >dispatch@ietf.org; modern@ietf.org >Subject: Re: [dispatch] CNIT and Modern Charter > > >As a matter of principal I wouldn=E2=80=99t rule anything like this out but ther= e >could be some philshing issues. > >My question would be why? Sort of like the old out of band STIR idea >that I=E2=80=99m convinced is going no where. > >I=E2=80=99d like to fix one simple problem reasonably quickly. > > > >On 3/10/15, 2:58 PM, "Gorman, Pierce A [CTO]" >wrote: > >>Should there be mutual authentication? Should the calling party >>receive a called party identity? >> >>Best regards, >> >> >>Pierce Gorman >>Voice Architecture >>Core Planning/Sprint >>913-439-4368 (Desk) >> >>-----Original Message----- >>From: Richard Shockey [mailto:richard@shockey.us] >>Sent: March 10, 2015 1:53 PM >>To: Gorman, Pierce A [CTO]; Cullen Jennings; cnit@ietf.org; >>dispatch@ietf.org; modern@ietf.org >>Subject: Re: [dispatch] CNIT and Modern Charter >> >> >>Exactly=E2=80=A6 studying the trust models are perfectly appropriate. >>Obviously the calling party data can come from different sources though >>I suspect in its earliest models it comes from the originating service >>provider through the SIP signaling mechanism to the terminating CUA. >>Especially in the VoLTE case. >> >>Enterprise to Enterprise would clearly be different. Certainly 3rd >>party databases could be involved in some way. >> >>I would remind folks that the rationale for this is consumers and >>National Regulators are NOT HAPPY AT ALL with the current state of how >>calling party data is presented to the consumer. STIR in and of itself >>is not enough. This is ultimately a consumer protection issue. >> >> >> >> >>On 3/9/15, 6:25 PM, "Gorman, Pierce A [CTO]" >>wrote: >> >>>I don't have any useful charter text. >>>I agree that the IETF should not propose business models, but it seems >>>important to consider trust model(s) to see if it/they drive protocol >>>considerations. >>>We could start with listing assumptions. I'll start by listing two. >>> 1) I assume there would be multiple authorities and multiple >>>levels of trust. >>> 2) I assume there are international tradename, and trademark and >>>the aforementioned UTF-8 international character code spoofing >>>considerations. >>> >>> >>>Best regards, >>> >>> >>>Pierce Gorman >>>Voice Architecture >>>Core Planning/Sprint >>>913-439-4368 (Desk) >>> >>>-----Original Message----- >>>From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Richard >>>Shockey >>>Sent: March 09, 2015 2:18 PM >>>To: Cullen Jennings; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org >>>Subject: Re: [Modern] [dispatch] CNIT and Modern Charter >>> >>> >>>The first order issue is properly defining what this looks like in SIP >>>and where in the headers it should reside. There is ample evidence >>>that any number of other SDO are looking at this and without some >>>proper standardization there will be no interoperability at all >>>especially even for STIR validation data at the CUA and IMHO doing >>>nothing is not a viable option. The basic FROM and PAI usage is not >>>helpful. >>> >>>We are all aware of how smart phones work. This is principally about >>>sessions that would originate outside a select number of phone book >>>entries and some display of whether that information has been >>>validated though we don=C2=B9t have to define policy at this stage and >>>frankly I don=C2=B9t think the IETF should try any more than it could try >>>and establish the business model for how this would deploy. >>> >>>The purpose here is simply adding more information about who >>>originated the session so the called party has more information than >>>they currently have. We already have enough bad actors as it is >>>impersonating tax authorities, banks, health care professionals and >>>other governmental entities. The purpose is to try and bound those >>>problems to a manageable level. There is no silver bullet here. >>> >>>I would appreciate any suggestions on charter text if you have them. >>> >>> >>> >>>=E2=80=B9 >>>Richard Shockey >>>Shockey Consulting LLC >>>Chairman of the Board SIP Forum >>>www.shockey.us >>>www.sipforum.org >>>richardshockey.us >>>Skype-Linkedin-Facebook rshockey101 >>>PSTN +1 703-593-2683 >>> >>> >>> >>> >>> >>>On 3/9/15, 11:10 AM, "Cullen Jennings" wrote: >>> >>>> >>>>On the particular CNAM like topic ... >>>> >>>>I'm not keen on moving forward with something like this unless we can >>>>show the trust and human factors issues is an engineering problem not >>>>a research problem. We have seen the difficulty with human readable >>>>names in SPAM. Particularly when using UTF-8, how do we stop bad >>>>actor getting names that look the same as someone they wish to >>>>impersonate? >>>>Who will validate the names and issue some sort of trust token that >>>>says I can use "Cullen Jennings" or whatever. Who else can use that >>>>name and what about names visually similar to it. >>>> >>>>On the flip side we are seeing most smart phones take the incoming >>>>phone number, and look it up the personal address book of the user >>>>and display the name that the user of the smartphone assigned. We are >>>>seeing enterprise phones that do a similar things using the users >>>>social networks as well as personal address book. >>>> >>>>What would be bad is phone display a display name that some how >>>>claimed to be trustable but was not. That would be worse that the >>>>current situation. Perhaps people have a good way to solve this in >>>>mind but I'm not seeing that that is. >>>> >>>>Cullen (with my individual contribute hat on of course) >>>> >>>> >>>> >>>>> On Feb 25, 2015, at 10:05 AM, Richard Shockey >>>>>wrote: >>>>> >>>>> >>>>> Thanks Martin .. This is my very raw first cut at a charter. Its >>>>>hopefully simple and straight forward. >>>>> >>>>> Send me any edits etc. >>>>> >>>>> ***** >>>>> >>>>> CNIT Charter [Calling Name Identity Trust] >>>>> >>>>> WG Chairs TBD: >>>>> >>>>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII >>>>>Characters of information associated with a specific E.164 calling >>>>>party number in the Public Switched Telephone Network [PSTN]. In >>>>>the PSTN this data is sent by the originating network only at the >>>>>specific request of the terminating network via a SS7 Transaction >>>>>Application Part [TCAP] response message. In the Session Initiation >>>>>Protocol [SIP] this information can be inserted into the FROM: part >>>>>of the originating INVITE message or by other means. >>>>> >>>>> As with the originating source telephone number, this data can be >>>>>altered in transit creating a variety of malicious abuses similar to >>>>>the ones identified by the IETF STIR working group. >>>>> >>>>> The purpose of the CNIT working group will be to define a data >>>>>structure, a new SIP header or repurpose an existing SIP header to >>>>>carry an advanced form of CNAM as well as information from a STIR >>>>>Validation Authority. The purpose of this work is to present to the >>>>>SIP called party trusted information from the calling party in order >>>>>that the called party make a more reasoned and informed judgment on >>>>>whether to accept the INVITE or not. >>>>> >>>>> The working group will not invalidate any existing SIP mechanism >>>>>for anonymous calling. >>>>> >>>>> The working group will, to the best of its ability, reuse existing >>>>>IETF protocols. >>>>> >>>>> Full Internationalization of the Calling Name Identity Trust data >>>>>object(s) is a requirement. >>>>> >>>>> The working group will closely work with the IETF STIR working >>>>> group >>>>> >>>>> The working group will immediately liaison with 3GPP SA-1 in order >>>>>to coordinate efforts. >>>>> >>>>> The working group will coordinate with National Numbering >>>>>Authorities and National Regulatory Authorities as needed. >>>>> >>>>> The working group will deliver the flowing. >>>>> >>>>> =E2=82=ACA problem statement and requirements detailing the current >>>>>deployment environment and situations that motivate work on Calling >>>>>Name Identity Trust. >>>>> =E2=82=ACDefine either a new SIP header or document a repurpose of an SIP >>>>>existing header for Calling Name Identify Trust data =E2=82=ACDefine a data >>>>>model for the Calling Name Identity Trust object (s) which may >>>>>include various forms of multimedia data =E2=82=ACDeliver an analysis of >>>>>privacy implications of the proposed Calling Name Identity Trust >>>>>mechanism. >>>>> >>>>> >>>>> Milestones: >>>>> >>>>> >>>>> =E2=80=B9 >>>>> Richard Shockey >>>>> Shockey Consulting LLC >>>>> Chairman of the Board SIP Forum >>>>> www.shockey.us >>>>> www.sipforum.org >>>>> richardshockey.us >>>>> Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 >>>>> >>>>> >>>>> From: "DOLLY, MARTIN C" >>>>> Date: Tuesday, February 24, 2015 at 9:02 PM >>>>> To: Richard Shockey >>>>> Cc: "Holmes, David W [CTO]" , >>>>>"dispatch@ietf.org" , "modern@ietf.org" >>>>>, "Peterson, Jon" >>>>> Subject: Re: [Modern] [dispatch] draft charter >>>>> >>>>> I support Richard on this >>>>> >>>>> Martin Dolly >>>>> Lead Member of Technical Staff >>>>> Core & Gov't/Regulatory Standards >>>>> AT&T Standards and >>>>> Industry Alliances >>>>> +1-609-903-3390 >>>>> Sent from my iPhone >>>>> >>>>> On Feb 24, 2015, at 6:36 PM, Richard Shockey >>>>>wrote: >>>>> >>>>>> >>>>>> Excellent points David. >>>>>> >>>>>> My concern here is charter overreach. I really want to keep >>>>>>CNAM+/CNIT out of this. IMHO that is a very separate and highly >>>>>>focused effort to define both the modification of the SIP headers >>>>>>necessary to support some enhanced calling party identification and >>>>>>a very limited effort to define the object and or the STIR validation >>>>>>data. >>>>>> >>>>>> I=C2=B9m violently opposed to =C2=B3end world hunger=C2=B2 WG=C2=B9s. >>>>>> >>>>>> If registries can be used fine but I certainly want to see how this >>>>>>can be accomplished in bi lateral agreements between consenting >>>>>>service providers and work with CUA vendors on how the data is >>>>>>displayed aka Apple, Samsung, Microsoft in the context of a formal >>>>>>liaison with 3GPP. >>>>>> Certainly the relevance of CNAM+/CNIT in enterprise and residential >>>>>>access markets is important but we all know =C2=B3Money is the answer >>>>>>what is the question ..=C2=B2 >>>>>> >>>>>> I=C2=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and >>>>>>report on the JTF on NNI. As you well know we have made considerable >>>>>>progress. >>>>>> >>>>>> Last week I gave a talk on this to a panel that included many of >>>>>>our friends among the national regulators. >>>>>> >>>>>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>>>> >>>>>> >>>>>> >>>>>> From: "Holmes, David W [CTO]" >>>>>> Date: Tuesday, February 24, 2015 at 5:06 PM >>>>>> To: "Peterson, Jon" , "modern@ietf.org" >>>>>> >>>>>> Subject: Re: [Modern] draft charter >>>>>> >>>>>> Jon, >>>>>> >>>>>> Thank you for the work in assembling this draft of the charter for >>>>>>MODERN. >>>>>> >>>>>> We would like to suggest some minor clarifications to the bullets >>>>>>describing the deliverables, to align them with the statement >>>>>>regarding flexibility to support the needs of different regulatory >>>>>>regimes, & thus to ensure that if quoted alone they are not taken >>>>>>out of context; i.e. the group product will be the protocols to >>>>>>support the allocation etc. activities, & it would not attempt to >>>>>>define the allocation processes. We also would like the charter to >>>>>>note the relevant work that has already been performed by both IETF >>>>>>& the ATIS/SIP Forum JTF, & incorporate that into the output from the >>>>>>MODERN WG as appropriate. >>>>>>These changes/additions are have been added to your text inline >>>>>>below. >>>>>> >>>>>> We are hoping that the MODERN session at IETF#92 will have remote >>>>>>access, to allow participation by those of us that cannot attend in >>>>>>person due to other commitments that week. >>>>>> >>>>>> Regards, >>>>>> >>>>>> David/Sprint >>>>>> >>>>>>____________________________________________________________________ >>>>>>___ >>>>>>_ >>>>>>______ >>>>>> >>>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of >>>>>>Peterson, Jon >>>>>> Sent: Wednesday, February 11, 2015 9:19 AM >>>>>> To: modern@ietf.org >>>>>> Subject: [Modern] draft charter >>>>>> >>>>>> >>>>>> At the Dallas IETF meeting in March, we'd like to get together and >>>>>>talk about what a working group for MODERN might look like. As an >>>>>>initial input to the discussion, a few of us have put together a >>>>>>proposed charter. While the TeRQ work was positively evaluated in >>>>>>the DISPATCH process, we feel this is broader enough in scope to >>>>>>warrant its own BoF. >>>>>> >>>>>> Comments are welcome, this is just a starting point. >>>>>> >>>>>> ------ >>>>>> >>>>>> Modern charter text: >>>>>> >>>>>> The MODERN working group will define a set of Internet-based >>>>>>mechanisms for the purposes of managing and resolving telephone >>>>>>numbers >>>>>>(TNs) in an IP environment. Existing mechanisms for these purposes >>>>>>face obsolescence as the voice communications infrastructure evolves >>>>>>to IP technology and new applications for TNs become possible. The >>>>>>traditional model of a TN having an association to a single service >>>>>>provider and a single application is breaking down. Its use as a >>>>>>network locator is going away, but its use as an identifier for an >>>>>>individual or an organization will remain for some time. Devices, >>>>>>applications, and network tools increasingly need to manage TNs, >>>>>>including requesting and acquiring TN delegations from authorities. >>>>>> >>>>>> The working group will define a framework for the roles and >>>>>>functions involved in managing and resolving TNs in an IP >>>>>>environment. This includes a protocol mechanism for acquiring TNs, >>>>>>which will provide an enrollment process for the individuals and >>>>>>entities that use and manage TNs. TNs may either be managed in a >>>>>>hierarchical tree, or in a distributed peer-to-peer architecture. >>>>>>Privacy of the enrollment data and security of the resource will be >>>>>>primary considerations. >>>>>> >>>>>> Additionally, the working group will deliver a protocol mechanism >>>>>>for resolving TNs which will allow entities such as service >>>>>>providers, devices, and applications to access data related to TNs, >>>>>>possibly including caller name data (CNAM). Maintaining >>>>>>reliability, real time application performance, security and privacy >>>>>>are primary considerations. The working group will take into >>>>>>consideration existing IETF work including ENUM, SPEERMINT, STIR, and >>>>>>DRINKS. >>>>>> >>>>>> The work of this group is limited to specifying a solution for TNs >>>>>>and covers any service that can be addressed using a TN. Expanding >>>>>>the work to other identifiers is out of scope. Solutions and >>>>>>mechanisms created by the working group will be flexible enough to >>>>>>accommodate different policies, e.g., by different regulatory >>>>>>agencies. >>>>>> >>>>>> The work group will deliver the following: >>>>>> >>>>>> - An architecture overview document that includes high >>>>>>level >>>>>>requirements and security/privacy considerationsbuilt on the work of >>>>>>IETF & the ATIS/SIP Forum JTF, that included: >>>>>> o Call routing architecture >>>>>> o Inter-carrier NNI >>>>>> o Cryptographically-enabled Anti-spoofing (STIR) >>>>>> o Enhanced Calling Name (CNIT/CNAM) >>>>>> - A document describing the protocols to support enrollment >>>>>>processes for existing and new TNs including any modifications to >>>>>>metadata related to those TNs >>>>>> - A document describing protocol mechanisms for accessing >>>>>>contact information associated with enrollments >>>>>> - A document describing protocol mechanisms for resolving >>>>>>information related to TNs >>>>>> >>>>>> - >>>>>> >>>>>> >>>>>> This e-mail may contain Sprint proprietary information intended for >>>>>>the sole use of the recipient(s). Any use by others is prohibited. >>>>>>If you are not the intended recipient, please contact the sender and >>>>>>delete all copies of the message. >>>>>> _______________________________________________ Modern mailing list >>>>>>Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> _______________________________________________ Modern mailing list >>>>>Modern@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/modern_________________________ >>>>>___ >>>>>_ >>>>>__________________ >>>>> 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 >>> >>> >>>_______________________________________________ >>>Modern mailing list >>>Modern@ietf.org >>>https://www.ietf.org/mailman/listinfo/modern >>> >>>________________________________ >>> >>>This e-mail may contain Sprint proprietary information intended for the >>>sole use of the recipient(s). Any use by others is prohibited. If you >>>are not the intended recipient, please contact the sender and delete >>>all copies of the message. >> >> >> >>________________________________ >> >>This e-mail may contain Sprint proprietary information intended for the >>sole use of the recipient(s). Any use by others is prohibited. If you are >>not the intended recipient, please contact the sender and delete all >>copies of the message. > > > >________________________________ > >This e-mail may contain Sprint proprietary information intended for the >sole use of the recipient(s). Any use by others is prohibited. If you are >not the intended recipient, please contact the sender and delete all >copies of the message. >_______________________________________________ >Modern mailing list >Modern@ietf.org >https://www.ietf.org/mailman/listinfo/modern From nobody Tue Mar 10 17:16:15 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B41E1A8AE2 for ; Tue, 10 Mar 2015 17:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l9FtWzPxtzg for ; Tue, 10 Mar 2015 17:16:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842AB1A8830 for ; Tue, 10 Mar 2015 17:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7346; q=dns/txt; s=iport; t=1426032969; x=1427242569; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0lgFmnuNwgY46bWHzjcDmAmLQj7NlhQvMb3ilv2jDKE=; b=J/XCZNtAr7YMudV6JeD9u/8oNMxIhkzqVHwpO6wOHv+iC7mdUeDt+1Af tiISzlWmzyHR6yCZIvyYATQySK2EZDlwMMB8+4IygvU5QJCyrPdmuRjTS jVrSCSwOD5PfjM61yx9aN6QIOu69O9/9fo3VTEvwJwGOu/aYB3cBXRyMY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQDxh/9U/5BdJa1TCYMGUlqDAsAmDoUjSQKBNU0BAQEBAQF8hA8BAQEDAQEBARoxIAkCBQcEAgEIDgMBAgECASMLJwoBFAMGCAIECAYBBAEIEgIEiAYIDcYjAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4oYf4QMBwMHAR0IKwcGgxGBFgWKQoVXg2eFdIEaOYJvhwWIMCOBfQUFFxSBPG8BAQEBAQJ7CReBIQEBAQ X-IronPort-AV: E=Sophos;i="5.11,378,1422921600"; d="scan'208";a="402621145" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 11 Mar 2015 00:16:08 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2B0G7PA025622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Mar 2015 00:16:08 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 10 Mar 2015 19:16:07 -0500 From: "Cullen Jennings (fluffy)" To: Scot Brooksby Thread-Topic: [VRS Interop] Re: [dispatch] New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt Thread-Index: AQHQWpE8yfviE0s1ZUya9nrZrvedL50UtYFAgAG2gFc= Date: Wed, 11 Mar 2015 00:16:07 +0000 Message-ID: <49007A2A-3FE5-4861-A4C5-92334E1295B1@cisco.com> References: <6F2A17BA-AE0D-4370-A613-9E28B052AF16@cisco.com> <54FDE18C.7050800@alum.mit.edu>, <18D75981C159A342A11F851B5CD2DECFCCBD4DF1@SLC-EXMB01.CORP.SRELAY.COM> In-Reply-To: <18D75981C159A342A11F851B5CD2DECFCCBD4DF1@SLC-EXMB01.CORP.SRELAY.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] [VRS Interop] Re: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:16:14 -0000 That's very helpful - thank you=20 > On Mar 9, 2015, at 3:25 PM, Scot Brooksby wrote: >=20 > Cullen, >=20 > The FCC rules for Relay providers can be found at: >=20 > http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=3D1&SID=3D76afe7404ca0539183b= 8ee9b6d78e8be&ty=3DHTML&h=3DL&r=3DPART&n=3Dpt47.3.64#se47.3.64_1604 >=20 > Specifically, you want to look at =A764.604, paragraph (b)(2)(vi) (quoted= below - with my emphasis on the paragraph). >=20 > (2) Call data required from all TRS providers. In addition to the data re= quested by paragraph (c)(5)(iii)(C)(1) of this section, TRS providers seeki= ng compensation from the TRS Fund shall submit the following specific data = associated with each TRS call for which compensation is sought: > (i) The call record ID sequence; > (ii) CA ID number; > (iii) Session start and end times noted at a minimum to the nearest se= cond; > (iv) Conversation start and end times noted at a minimum to the neares= t second; > (v) Incoming telephone number and IP address (if call originates with = an IP-based device) at the time of the call; > (vi) Outbound telephone number (if call terminates to a telephone) and= IP address (if call terminates to an IP-based device) at the time of call; > **(vii) Total conversation minutes; ** > (viii) Total session minutes; > (ix) The call center (by assigned center ID number) that handled the c= all; and > (x) The URL address through which the call is handled. > (3) Additional call data required from Internet-based Relay Providers.= In addition to the data required by paragraph (c)(5)(iii)(C)(2) of this se= ction, Internet-based Relay Providers seeking compensation from the Fund sh= all submit speed of answer compliance data. > (4) Providers submitting call record and speed of answer data in compl= iance with paragraphs (c)(5)(iii)(C)(2) and (c)(5)(iii)(C)(3) of this secti= on shall: > (i) Employ an automated record keeping system to capture such data req= uired pursuant to paragraph (c)(5)(iii)(C)(2) of this section for each TRS = call for which minutes are submitted to the fund administrator for compensa= tion; and > (ii) Submit such data electronically, in a standardized format. For pu= rposes of this subparagraph, an automated record keeping system is a system= that captures data in a computerized and electronic format that does not a= llow human intervention during the call session for either conversation or = session time. >=20 > Thanks, > Scot >=20 > Scot Brooksby > Engineering Director, Architecture and Infrastructure > Sorenson Communications >=20 >=20 >> -------- Forwarded Message -------- >> Subject: Re: [dispatch] New Version Notification for draft-kyzivat-dispa= tch-trs- >> call-info-purpose-00.txt >> Date: Mon, 9 Mar 2015 08:58:51 -0600 >> From: Cullen Jennings >> To: Paul Kyzivat >> CC: dispatch@ietf.org >>=20 >>=20 >> The heart of this draft gives me, ah , heartburn. The issue is >>=20 >> For a provider to receive reimbursement for providing relay service >> on a call the FCC requires that the provider supply call detail >> including the IP address of the device the TRS user is using for the >> call. >>=20 >> First of all what IP. The IP of their phone behind their linksys nat? >> the public IP of the TURN server? the VPN? None of these are a viable >> way to authenticate that the user should receive this services and the >> IETF should implicitly endorse that they are. Furthermore the IETF >> should be just as concerned about privacy for people using a VRS as >> people that do not need one and this sort of reveal my IP address even >> if I want location privacy is not great. >>=20 >> Given the lack of any security around this and the TRS-5 requirement, I >> wonder if one can just look at the via list and use that? >>=20 >> If we do proceed with this, I don't think the call-info is the >> appropriate place to put it. I think a new header would be the right thi= ng. >>=20 >> Can you provide a pointer to the actually FCC rules for this? >>=20 >> If the goal is purely to check the user is in the US, then having the >> VRS check that they were sending media to an IP address inside the US >> seems like it would be a better solution. >>=20 >> Thanks >>=20 >>=20 >>=20 >>> On Jan 13, 2015, at 9:14 AM, Paul Kyzivat wrote= : >>>=20 >>> Dispatchers: >>>=20 >>> I have just submitted a new draft (see below) that needs to be dispatch= ed. It >> defines a new Call-Info 'purpose' parameter value. >>>=20 >>> The intended audience for this draft is quite limited - to the provider= s of the >> Video Relay Service in the US, and to the FCC that sponsors that service= . The >> Intro section explains this. >>>=20 >>> I'm hoping this can be dispatched without causing a lot of bother for a= nybody. >> I don't anticipate that it needs time in Dallas. IIUC documents of this = sort are >> often AD sponsored. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for draft-kyzivat-dispatch-trs-call-i= nfo- >> purpose-00.txt >>> Date: Tue, 13 Jan 2015 07:46:47 -0800 >>> From: internet-drafts@ietf.org >>> To: Paul Kyzivat , "Paul Kyzivat" >> >>>=20 >>>=20 >>> A new version of I-D, draft-kyzivat-dispatch-trs-call-info-purpose-00.t= xt >>> has been successfully submitted by Paul Kyzivat and posted to the >>> IETF repository. >>>=20 >>> Name: draft-kyzivat-dispatch-trs-call-info-purpose >>> Revision: 00 >>> Title: Telecommunications Relay Service Purpose for the Call-Inf= o >> Header Field in the Session Initiation Protocol (SIP) >>> Document date: 2015-01-13 >>> Group: Individual Submission >>> Pages: 4 >>> URL: http://www.ietf.org/internet-drafts/draft-kyzivat-dispatch-trs-cal= l-info- >> purpose-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-kyzivat-dispatch-trs-cal= l-info- >> purpose/ >>> Htmlized: http://tools.ietf.org/html/draft-kyzivat-dispatch-trs-call-in= fo- >> purpose-00 >>>=20 >>>=20 >>> Abstract: >>> This document defines and registers a value of "original-identity" >>> for the "purpose" header field parameter of the Call-Info header >>> field in the Session Initiation Protocol (SIP). >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>=20 >>=20 >>=20 >>=20 >> -- >> You received this message because you are subscribed to the Google Group= s >> "VRS Interop" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to io+unsubscribe@vrs.io. >> To post to this group, send email to io@vrs.io. >> Visit this group at http://groups.google.com/a/vrs.io/group/io/. From nobody Tue Mar 10 17:34:59 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FDF1A90C6 for ; Tue, 10 Mar 2015 17:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.678 X-Spam-Level: X-Spam-Status: No, score=0.678 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6wc4byWBvFK for ; Tue, 10 Mar 2015 17:34:51 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.29]) by ietfa.amsl.com (Postfix) with ESMTP id 52B491A90C3 for ; Tue, 10 Mar 2015 17:34:51 -0700 (PDT) Received: from userPC (unknown [122.178.207.235]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id A833E869635; Wed, 11 Mar 2015 00:34:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1426034090; bh=hX++omaNY97f5sH4kvA5BtyOFO6E/1x6L0+b1bTJ/7A=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=hprxDRJYBi/dNfxn8nvvfH1Rr3DgJeCADrT1Q5QRezU9jS6KLjpDLWyyBizz7jcZV iCardKiWjJMPd+sePJHf+TtABWnWg2aqjKwQxboX5BEnqUqmRhiFyDaqNzLGVKfy+I oXDEGM/ZrTMLa262ovsqNkCrfT8zg4Mo3RFvhA4o= From: "Parthasarathi R" To: , References: <787AE7BB302AE849A7480A190F8B933004924E01@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004924E01@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Wed, 11 Mar 2015 06:04:37 +0530 Message-ID: <012e01d05b93$2c1e2e80$845a8b80$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012F_01D05BC1.45D66A80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBXLaVKHLIA7f4lSRmkPUaU5jCunwEZWgqA Content-Language: en-us X-CTCH-RefID: str=0001.0A020202.54FF8DAA.0186, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: Subject: Re: [dispatch] PCP for SIP Deployments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:34:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012F_01D05BC1.45D66A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 The updated version looks good. =20 Thanks Partha =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Thursday, March 05, 2015 3:48 PM To: Parthasarathi R; dispatch@ietf.org Subject: RE: [dispatch] PCP for SIP Deployments =20 Hi Partha,=20 =20 Thank you for the feedback.=20 =20 I understand more your comment about ICE. I updated the draft = accordingly.=20 =20 Please check the new version and the diff: =20 URL: = http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-ipv6-05.txt Status: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6/ Htmlized: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-05 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-ipv6-05 =20 =20 Thank you. =20 Cheers, Med =20 De : Parthasarathi R [mailto:partha@parthasarathi.co.in]=20 Envoy=E9 : jeudi 5 mars 2015 01:21 =C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org Objet : RE: [dispatch] PCP for SIP Deployments =20 Hi Med, =20 Thanks for incorporating the comments.=20 =20 ICE is used in the context of SIP over WebSocket (RFC 7118) & WebRTC SDP profile within managed networks. TURN has its own limitation in = traversing NAT/FW using UDP transport in case of managed networks. PCP server in = NAT &FW resolves these issues. Of course, the current implementations = (WebRTC devices) have challenges in using ICE + PCP but IMO, it is good have for future works. =20 Thanks Partha =20 From: = mohamed.boucadair@orange.com [ = mailto:mohamed.boucadair@orange.com]=20 Sent: Monday, March 02, 2015 9:56 PM To: Parthasarathi R; dispatch@ietf.org Subject: RE: [dispatch] PCP for SIP Deployments =20 Hi Partha, =20 Many thanks for the review and the comments.=20 =20 I integrated almost all your suggestion, except the one about the ICE discussion. The reason for that is ICE is not deployed in the managed context; as such I=92m afraid there is no value in having such = discussion in the I-D.=20 =20 Please check the diff and let me know if you have further comments.=20 =20 URL: = http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-ipv6-04.txt Status: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6/ Htmlized: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-ipv6-04 =20 Thank you. =20 Cheers, Med =20 =20 De : Parthasarathi R [ mailto:partha@parthasarathi.co.in]=20 Envoy=E9 : vendredi 27 f=E9vrier 2015 23:47 =C0 : BOUCADAIR Mohamed IMT/OLN; = dispatch@ietf.org Objet : RE: [dispatch] PCP for SIP Deployments =20 Hi Med, =20 It is a interesting draft. The current writing provides PCP advantages = in SIP managed network and particularly cellular. The following information = has to be added to provide more clarity about this work: =20 1) Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP = client, PCP server 2) Basic callflow to show how the dialog is established in case P2P = is used 3) The draft title mentions IPv6. My understanding is that this = shall be used for IPv4 network as well. 4) Add more details about how SIP, PCP, ICE interworking happens as = the current reference is related to PCP with rtcweb only. 5) Security implication w.r.t SIP usage of PCP has to be mentioned. 6) Advantage of using PCP over TURN in SIP network shall be = provided in the introduction section for better comparison. =20 Regards Partha =20 From: dispatch [ mailto:dispatch-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Thursday, February 26, 2015 3:02 PM To: dispatch@ietf.org Subject: [dispatch] PCP for SIP Deployments =20 Hi all, =20 I would like to share with this group a short document that explains how = PCP can be of great use in the context SIP-based services: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03=20 =20 As indicated in the I-D, the main benefits include (but not limited to): = =20 o Avoid embedding an ALG in the middleboxes. Note, ALGs are not recommended since the evolution of the service would depend on the ALG maintenance. o Not require any Hosted NAT Traversal function (e.g., [ RFC7362]) to be embedded in the SIP server. Intermediate NATs and firewalls are transparent to the SIP service platform. o Avoid overloading the network with keepalive message to maintain the mapping in intermediate middleboxes. o Work without requiring symmetric RTP/RTCP [ RFC4961]. o Not require symmetric SIP to work (i.e., rport [ RFC3581]). o Easily support unidirectional sessions. =20 When this document was first presented in the PCP WG, I was suggested = that it is better to publish it in RAI with a review from the PCP WG. Hence, = this message to the list.=20 =20 Cheers, Med ------=_NextPart_000_012F_01D05BC1.45D66A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Med,

 

The updated version = looks good.

 

Thanks

Partha

 

From:= mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Thursday, March 05, 2015 3:48 PM
To: Parthasarathi R; dispatch@ietf.org
Subject: RE: [dispatch] PCP for SIP = Deployments

 

Hi Partha,

 

Thank you for the feedback.

 

I understand more your comment about ICE. I updated the = draft accordingly.

 

Please check the new version and the = diff:

 

URL:        =     http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-= ipv6-05.txt

Status:       &nb= sp; <= span lang=3DEN-US>https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv= 6/

Htmlized:       = http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-05

Diff:        = ;   http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-i= pv6-05

 

 

Thank you.

 

Cheers,

Med

 

De : = Parthasarathi R [mailto:partha@parthasarathi.co.in]
Envoy=E9 : jeudi 5 mars 2015 01:21
=C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org
Objet : RE: [dispatch] PCP for SIP = Deployments

 

Hi = Med,

 

Thanks for = incorporating the comments.

 

ICE is used in the = context of SIP over WebSocket (RFC 7118) & WebRTC SDP profile within managed = networks. TURN has its own limitation in traversing NAT/FW using UDP transport in = case of managed networks. PCP server in NAT &FW resolves these issues. Of = course, the current implementations (WebRTC devices) have challenges in using = ICE + PCP but IMO, it is good have for future works.

 

Thanks

Partha

 

From:= = mohamed.bouc= adair@orange.com = [mailto:moham= ed.boucadair@orange.com]
Sent: Monday, March 02, 2015 9:56 PM
To: Parthasarathi R; dispatch@ietf.org
Subject: RE: [dispatch] PCP for SIP = Deployments

 

Hi Partha,

 

Many thanks for the review and the comments. =

 

I integrated almost all your suggestion, except the one = about the ICE discussion. The reason for that is ICE is not deployed in the = managed context; as such I’m afraid there is no value in having such = discussion in the I-D.

 

Please check the diff and let me know if you have further comments.

 

URL:         &n= bsp;  http://www.ietf.org/internet-drafts/draft-boucadair-pcp-sip-ipv6-04= .txt

Status:         = <= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier = New"'>https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6/

Htmlized:       http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-04

Diff:        =    http://www.ietf.org/rfcdiff?url2=3Ddraft-boucadair-pcp-sip-ipv6-04<= /span>

 

Thank you.

 

Cheers,

Med

 

 

De : = Parthasarathi R [mailto:parth= a@parthasarathi.co.in]
Envoy=E9 : vendredi 27 f=E9vrier 2015 23:47
=C0 : BOUCADAIR Mohamed IMT/OLN; dispatch@ietf.org
Objet : RE: [dispatch] PCP for SIP = Deployments

 

Hi = Med,

 

It is a interesting = draft. The current writing provides PCP advantages in SIP managed network and = particularly cellular. The following information has to be added to provide more = clarity about this work:

 

1)      Network diagram/topology with SIP UA, SIP proxy/B2BUA, PCP client, PCP = server

2)      Basic = callflow to show how the dialog is established in case P2P is = used

3)      The draft = title mentions IPv6. My understanding is that this shall be used for IPv4 = network as well.

4)      Add more = details about how SIP, PCP, ICE interworking happens as the current reference is related to PCP with rtcweb only.

5)      Security = implication w.r.t SIP usage of PCP has to be mentioned.

6)      Advantage = of using PCP over TURN in SIP network shall be provided in the introduction = section for better comparison.

 

Regards

Partha

 

From:= dispatch = [mailto:dispa= tch-bounces@ietf.org] On = Behalf Of mohamed.bouc= adair@orange.com
Sent: Thursday, February 26, 2015 3:02 PM
To: dispatch@iet= f.org
Subject: [dispatch] PCP for SIP Deployments

 

Hi all,

 

I would like to share with this group a short document that explains how = PCP can be of great use in the context SIP-based services:

http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03 =

 

As indicated in the I-D, the main benefits include (but not limited to): =

 

   o  Avoid embedding an ALG in the =
middleboxes.  Note, ALGs are not
      recommended since the evolution of =
the service would depend on the
      ALG =
maintenance.
   =
o  Not require any Hosted NAT Traversal function (e.g., =
[RFC7362]) =
to
      be embedded in the SIP =
server.  Intermediate NATs and =
firewalls
      are transparent to the SIP service =
platform.
   =
o  Avoid overloading the network with keepalive message to =
maintain
      the mapping in intermediate =
middleboxes.
   =
o  Work without requiring symmetric RTP/RTCP [RFC4961].
   =
o  Not require symmetric SIP to work (i.e., rport [RFC3581]).
   =
o  Easily support unidirectional sessions.

 

When this document was first presented in the PCP WG, I was suggested that it = is better to publish it in RAI with a review from the PCP WG. Hence, this = message to the list.

 

Cheers,

Med

------=_NextPart_000_012F_01D05BC1.45D66A80-- From nobody Tue Mar 10 17:49:51 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B18F1A9139 for ; Tue, 10 Mar 2015 17:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.178 X-Spam-Level: X-Spam-Status: No, score=0.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz1Y3AnRA7N2 for ; Tue, 10 Mar 2015 17:49:46 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.29]) by ietfa.amsl.com (Postfix) with ESMTP id 961C91A9141 for ; Tue, 10 Mar 2015 17:49:46 -0700 (PDT) Received: from userPC (unknown [122.178.207.235]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 628A8869640; Wed, 11 Mar 2015 00:49:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1426034986; bh=xR8+jmiZCWUvcZSwlmtEyYrVWNFogOBKgmL/Uy0WDVY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ea5fMZjSopNuu5ZnMhztg6SCnGD1GJFtG/YTVg4YvecfC2VBkqAtm120/eR8aw1qD AD43NTnJHC1rQzWuR3mjBv/m7ZRlfBXdzYbg4HR/2M/p0zfTC6Ekn4slOOgzSP6vRh VMf76f5WKN3lw2uZYfLvegEM5tAhFrsa9VaZNnPo= From: "Parthasarathi R" To: "'Cullen Jennings'" , References: <787AE7BB302AE849A7480A190F8B93300491577E@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Wed, 11 Mar 2015 06:19:36 +0530 Message-ID: <02da01d05b95$42935170$c7b9f450$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdBakTf/GX/g29yLQq2lHgcVzsmVsQBA3bXQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020202.54FF912A.000F, ss=1, re=0.001, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.001 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] PCP for SIP Deployments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 00:49:48 -0000 Hi Cullen, In case of PCP+ICE for media (RTP), adding one candidate will serve the purpose as the ICE connectivity check will ensure whether the port is reachable or not. There is no need of extra mechanism. Correct? Regards Partha > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen > Jennings > Sent: Monday, March 09, 2015 8:05 PM > To: mohamed.boucadair@orange.com > Cc: dispatch@ietf.org > Subject: Re: [dispatch] PCP for SIP Deployments > > > I read the draft and it seems like one of the issues is that you don't > know if the PCP nat is the only nat or firewall in path. So it seems > like a more robust solutions is to use PCP along with existing > solutions. So for SIP, one does the PCP to get a port but still relies > on things like rport and outbound to correctly set the return address > (IE use the PCP to open a pin whole but still use private address in > contact). Similarly with the RTP use PCP to get a address on the > outside of the NAT but just add that in as one of the ICE candidates. > > > > > > On Feb 26, 2015, at 2:31 AM, mohamed.boucadair@orange.com wrote: > > > > Hi all, > > > > I would like to share with this group a short document that explains > how PCP can be of great use in the context SIP-based services: > > http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03 > > > > As indicated in the I-D, the main benefits include (but not limited > to): > > > > o Avoid embedding an ALG in the middleboxes. Note, ALGs are not > > recommended since the evolution of the service would depend on > the > > ALG maintenance. > > o Not require any Hosted NAT Traversal function (e.g., [RFC7362]) > to > > be embedded in the SIP server. Intermediate NATs and firewalls > > are transparent to the SIP service platform. > > o Avoid overloading the network with keepalive message to > maintain > > the mapping in intermediate middleboxes. > > o Work without requiring symmetric RTP/RTCP [RFC4961]. > > o Not require symmetric SIP to work (i.e., rport [RFC3581]). > > o Easily support unidirectional sessions. > > > > When this document was first presented in the PCP WG, I was suggested > that it is better to publish it in RAI with a review from the PCP WG. > Hence, this message to the list. > > > > Cheers, > > Med > > _______________________________________________ > > 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 Mar 11 00:05:39 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723031A1BFA for ; Wed, 11 Mar 2015 00:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxQr7g90nRw6 for ; Wed, 11 Mar 2015 00:05:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66CB1A1BE0 for ; Wed, 11 Mar 2015 00:05:34 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id CD8F12AC697; Wed, 11 Mar 2015 08:05:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B0FBD384094; Wed, 11 Mar 2015 08:05:32 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.181]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Wed, 11 Mar 2015 08:05:32 +0100 From: To: Cullen Jennings Thread-Topic: [dispatch] PCP for SIP Deployments Thread-Index: AdBRpv5w7XTmu/weRVKc3+vCrIJ62gIxtgKAAFXwJIA= Date: Wed, 11 Mar 2015 07:05:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300492A2BD@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300491577E@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.11.50918 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] PCP for SIP Deployments X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 07:05:37 -0000 Dear Cullen, Thank you for the comment.=20 I agree with you it is more robust to use PCP along with other mechanisms f= or the generic case. In such case, PCP offer other functionalities that are= not listed in this I-D, e.g., NAT detect.=20 I also agree that if the SIP UA does not use the PCP response to build its = messages, then relying on rport and outbound will be needed even if PCP is = used to instantiate the requested mappings. What we are suggesting in this = draft is that we can disable those features if the SIP UA relies on the ret= urned external IP Address, external port number, the pair(s) of ports that = preserve parity to build an offer/answer. We had this text in the I-D:=20 In deployments where ICE [RFC5245] is required, PCP can be of great help as discussed in [I-D.penno-rtcweb-pcp] for the WebRTC case. ICE can be used in the context of SIP over WebSocket [RFC7118] and WebRTC when deployed within managed networks. Because TURN suffers from limitations in traversing NAT and firewalls over UDP, PCP is a promising solution that can complement ICE in those deployment contexts to soften the experienced high failure rate [ICEFailure]. The point is that this draft was initially scoped to cover the very specifi= c case of SIP service delivery in managed networks. In those networks, PCP = proxies and/or IGD/PCP Inetworking functions can be enabled if needed and j= ustified. E.g., * Deliver SIP service to a DS-Lite serviced customer: there is only one lev= el of NAT that is in the network side. The CPE does not include any NAT. Th= e SIP endpoint can be embedded in the CPE itself or be located behind. =20 * Access to an IPv4 SIP service platform via a NAT64: Only one level of NAT= will be experienced. This is more for the ongoing IPv6-only deployments in= mobile networks.=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Cullen Jennings [mailto:fluffy@cisco.com] > Envoy=E9=A0: lundi 9 mars 2015 15:35 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: dispatch@ietf.org > Objet=A0: Re: [dispatch] PCP for SIP Deployments >=20 >=20 > I read the draft and it seems like one of the issues is that you don't > know if the PCP nat is the only nat or firewall in path. So it seems like > a more robust solutions is to use PCP along with existing solutions. So > for SIP, one does the PCP to get a port but still relies on things like > rport and outbound to correctly set the return address (IE use the PCP to > open a pin whole but still use private address in contact). Similarly wit= h > the RTP use PCP to get a address on the outside of the NAT but just add > that in as one of the ICE candidates. >=20 >=20 >=20 >=20 > > On Feb 26, 2015, at 2:31 AM, mohamed.boucadair@orange.com wrote: > > > > Hi all, > > > > I would like to share with this group a short document that explains ho= w > PCP can be of great use in the context SIP-based services: > > http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-03 > > > > As indicated in the I-D, the main benefits include (but not limited to)= : > > > > o Avoid embedding an ALG in the middleboxes. Note, ALGs are not > > recommended since the evolution of the service would depend on th= e > > ALG maintenance. > > o Not require any Hosted NAT Traversal function (e.g., [RFC7362]) t= o > > be embedded in the SIP server. Intermediate NATs and firewalls > > are transparent to the SIP service platform. > > o Avoid overloading the network with keepalive message to maintain > > the mapping in intermediate middleboxes. > > o Work without requiring symmetric RTP/RTCP [RFC4961]. > > o Not require symmetric SIP to work (i.e., rport [RFC3581]). > > o Easily support unidirectional sessions. > > > > When this document was first presented in the PCP WG, I was suggested > that it is better to publish it in RAI with a review from the PCP WG. > Hence, this message to the list. > > > > Cheers, > > Med > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Mar 11 09:19:44 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCF11ACD2F; Wed, 11 Mar 2015 09:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwKGNNXoI-CD; Wed, 11 Mar 2015 09:19:38 -0700 (PDT) Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id E28101ACCF8; Wed, 11 Mar 2015 09:19:36 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey , Chris Wendt Thread-Topic: [dispatch] CNIT and Modern Charter Thread-Index: AQHQW2Qp9pBDczHOF06tIvLE6j2Plp0Xc6Ur Date: Wed, 11 Mar 2015 16:19:34 +0000 References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> <95353295-617C-4920-A581-4D0DFA02EDE4@chriswendt.net>, 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-1250" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:19:43 -0000 There seem to be two cases:=0A= =0A= (1) The originator of the call also provides the "CNAM" information, e.g., = based on their customer information.=0A= =0A= (2) A third party provides the CNAM information (e.g., a licensing entity o= r Dun & Bradstreet) that essentially says "I certify that the phone number = 212 555 1234 belongs to Citibank")=0A= =0A= Thus, there are two questions:=0A= =0A= (1) What information should be carried?=0A= =0A= (2) How does the cryptographic binding work? =0A= =0A= =0A= For example, would it make sense to have two 4474bis signatures, to address= case #2? Or should there be a separate signature that simply asserts the p= hone number to name binding, but it's not tied to the call itself.=0A= =0A= ________________________________________=0A= From: cnit [cnit-bounces@ietf.org] on behalf of Richard Shockey [richard@sh= ockey.us]=0A= Sent: Tuesday, March 10, 2015 2:57 PM=0A= To: Chris Wendt=0A= Cc: Cullen Jennings; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org=0A= Subject: Re: [cnit] [dispatch] CNIT and Modern Charter=0A= =0A= Exactly. If the IETF is going to remain responsible for core SIP=0A= protocols and signaling its our job to properly define these mechanisms.=0A= There is reason to believe if we don=92t do this it will be done for us.=0A= There were two bills in the US Congress about this last year and who knows= =0A= what elsewhere.=0A= =0A= IMHO the in band model is clearly the first use case. That alone would=0A= help a great deal.=0A= =0A= =0A= =0A= =0A= =0A= On 3/10/15, 2:37 PM, "Chris Wendt" wrote:=0A= =0A= >I agree that this would be useful just from the standpoint that if=0A= >service providers are going to implement in-band signing of caller-id,=0A= >would quite make sense to provide a better payload for delivering=0A= >additional and/or more useful calling party information along with=0A= >signing it as well.=0A= >=0A= >-Chris=0A= >=0A= >> On Mar 9, 2015, at 3:18 PM, Richard Shockey wrote:= =0A= >>=0A= >>=0A= >> The first order issue is properly defining what this looks like in SIP= =0A= >>and=0A= >> where in the headers it should reside. There is ample evidence that any= =0A= >> number of other SDO are looking at this and without some proper=0A= >> standardization there will be no interoperability at all especially even= =0A= >> for STIR validation data at the CUA and IMHO doing nothing is not a=0A= >>viable=0A= >> option. The basic FROM and PAI usage is not helpful.=0A= >>=0A= >> We are all aware of how smart phones work. This is principally about=0A= >> sessions that would originate outside a select number of phone book=0A= >> entries and some display of whether that information has been validated= =0A= >> though we don=B9t have to define policy at this stage and frankly I don= =B9t=0A= >> think the IETF should try any more than it could try and establish the= =0A= >> business model for how this would deploy.=0A= >>=0A= >> The purpose here is simply adding more information about who originated= =0A= >> the session so the called party has more information than they currently= =0A= >> have. We already have enough bad actors as it is impersonating tax=0A= >> authorities, banks, health care professionals and other governmental=0A= >> entities. The purpose is to try and bound those problems to a manageable= =0A= >> level. There is no silver bullet here.=0A= >>=0A= >> I would appreciate any suggestions on charter text if you have them.=0A= >>=0A= >>=0A= >>=0A= >> =8B=0A= >> Richard Shockey=0A= >> Shockey Consulting LLC=0A= >> Chairman of the Board SIP Forum=0A= >> www.shockey.us=0A= >> www.sipforum.org=0A= >> richardshockey.us=0A= >> Skype-Linkedin-Facebook rshockey101=0A= >> PSTN +1 703-593-2683=0A= >>=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> On 3/9/15, 11:10 AM, "Cullen Jennings" wrote:=0A= >>=0A= >>>=0A= >>> On the particular CNAM like topic ...=0A= >>>=0A= >>> I'm not keen on moving forward with something like this unless we can= =0A= >>> show the trust and human factors issues is an engineering problem not a= =0A= >>> research problem. We have seen the difficulty with human readable names= =0A= >>> in SPAM. Particularly when using UTF-8, how do we stop bad actor=0A= >>>getting=0A= >>> names that look the same as someone they wish to impersonate? Who will= =0A= >>> validate the names and issue some sort of trust token that says I can= =0A= >>>use=0A= >>> "Cullen Jennings" or whatever. Who else can use that name and what=0A= >>>about=0A= >>> names visually similar to it.=0A= >>>=0A= >>> On the flip side we are seeing most smart phones take the incoming=0A= >>>phone=0A= >>> number, and look it up the personal address book of the user and=0A= >>>display=0A= >>> the name that the user of the smartphone assigned. We are seeing=0A= >>> enterprise phones that do a similar things using the users social=0A= >>> networks as well as personal address book.=0A= >>>=0A= >>> What would be bad is phone display a display name that some how claimed= =0A= >>> to be trustable but was not. That would be worse that the current=0A= >>> situation. Perhaps people have a good way to solve this in mind but I'm= =0A= >>> not seeing that that is.=0A= >>>=0A= >>> Cullen (with my individual contribute hat on of course)=0A= >>>=0A= >>>=0A= >>>=0A= >>>> On Feb 25, 2015, at 10:05 AM, Richard Shockey =0A= >>>> wrote:=0A= >>>>=0A= >>>>=0A= >>>> Thanks Martin .. This is my very raw first cut at a charter. Its=0A= >>>> hopefully simple and straight forward.=0A= >>>>=0A= >>>> Send me any edits etc.=0A= >>>>=0A= >>>> *****=0A= >>>>=0A= >>>> CNIT Charter [Calling Name Identity Trust]=0A= >>>>=0A= >>>> WG Chairs TBD:=0A= >>>>=0A= >>>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters= =0A= >>>> of information associated with a specific E.164 calling party number= =0A= >>>>in=0A= >>>> the Public Switched Telephone Network [PSTN]. In the PSTN this data= =0A= >>>>is=0A= >>>> sent by the originating network only at the specific request of the=0A= >>>> terminating network via a SS7 Transaction Application Part [TCAP]=0A= >>>> response message. In the Session Initiation Protocol [SIP] this=0A= >>>> information can be inserted into the FROM: part of the originating=0A= >>>> INVITE message or by other means.=0A= >>>>=0A= >>>> As with the originating source telephone number, this data can be=0A= >>>> altered in transit creating a variety of malicious abuses similar to= =0A= >>>>the=0A= >>>> ones identified by the IETF STIR working group.=0A= >>>>=0A= >>>> The purpose of the CNIT working group will be to define a data=0A= >>>> structure, a new SIP header or repurpose an existing SIP header to=0A= >>>>carry=0A= >>>> an advanced form of CNAM as well as information from a STIR Validation= =0A= >>>> Authority. The purpose of this work is to present to the SIP called= =0A= >>>> party trusted information from the calling party in order that the=0A= >>>> called party make a more reasoned and informed judgment on whether to= =0A= >>>> accept the INVITE or not.=0A= >>>>=0A= >>>> The working group will not invalidate any existing SIP mechanism for= =0A= >>>> anonymous calling.=0A= >>>>=0A= >>>> The working group will, to the best of its ability, reuse existing=0A= >>>>IETF=0A= >>>> protocols.=0A= >>>>=0A= >>>> Full Internationalization of the Calling Name Identity Trust data=0A= >>>> object(s) is a requirement.=0A= >>>>=0A= >>>> The working group will closely work with the IETF STIR working group= =0A= >>>>=0A= >>>> The working group will immediately liaison with 3GPP SA-1 in order to= =0A= >>>> coordinate efforts.=0A= >>>>=0A= >>>> The working group will coordinate with National Numbering Authorities= =0A= >>>> and National Regulatory Authorities as needed.=0A= >>>>=0A= >>>> The working group will deliver the flowing.=0A= >>>>=0A= >>>> =80 A problem statement and requirements detailing the current=0A= >>>>deployment=0A= >>>> environment and situations that motivate work on Calling Name Identity= =0A= >>>> Trust.=0A= >>>> =80 Define either a new SIP header or document a repurpose of an SIP= =0A= >>>> existing header for Calling Name Identify Trust data=0A= >>>> =80 Define a data model for the Calling Name Identity Trust object (s= )=0A= >>>> which may include various forms of multimedia data=0A= >>>> =80 Deliver an analysis of privacy implications of the proposed Calli= ng=0A= >>>> Name Identity Trust mechanism.=0A= >>>>=0A= >>>>=0A= >>>> Milestones:=0A= >>>>=0A= >>>>=0A= >>>> =8B=0A= >>>> Richard Shockey=0A= >>>> Shockey Consulting LLC=0A= >>>> Chairman of the Board SIP Forum=0A= >>>> www.shockey.us=0A= >>>> www.sipforum.org=0A= >>>> richardshockey.us=0A= >>>> Skype-Linkedin-Facebook rshockey101=0A= >>>> PSTN +1 703-593-2683=0A= >>>>=0A= >>>>=0A= >>>> From: "DOLLY, MARTIN C" =0A= >>>> Date: Tuesday, February 24, 2015 at 9:02 PM=0A= >>>> To: Richard Shockey =0A= >>>> Cc: "Holmes, David W [CTO]" ,=0A= >>>> "dispatch@ietf.org" , "modern@ietf.org"=0A= >>>> , "Peterson, Jon" =0A= >>>> Subject: Re: [Modern] [dispatch] draft charter=0A= >>>>=0A= >>>> I support Richard on this=0A= >>>>=0A= >>>> Martin Dolly=0A= >>>> Lead Member of Technical Staff=0A= >>>> Core & Gov't/Regulatory Standards=0A= >>>> AT&T Standards and=0A= >>>> Industry Alliances=0A= >>>> +1-609-903-3390=0A= >>>> Sent from my iPhone=0A= >>>>=0A= >>>> On Feb 24, 2015, at 6:36 PM, Richard Shockey =0A= >>>>wrote:=0A= >>>>=0A= >>>>>=0A= >>>>> Excellent points David.=0A= >>>>>=0A= >>>>> My concern here is charter overreach. I really want to keep=0A= >>>>>CNAM+/CNIT=0A= >>>>> out of this. IMHO that is a very separate and highly focused effort= =0A= >>>>>to=0A= >>>>> define both the modification of the SIP headers necessary to support= =0A= >>>>> some enhanced calling party identification and a very limited effort= =0A= >>>>>to=0A= >>>>> define the object and or the STIR validation data.=0A= >>>>>=0A= >>>>> I=B9m violently opposed to =B3end world hunger=B2 WG=B9s.=0A= >>>>>=0A= >>>>> If registries can be used fine but I certainly want to see how this= =0A= >>>>> can be accomplished in bi lateral agreements between consenting=0A= >>>>>service=0A= >>>>> providers and work with CUA vendors on how the data is displayed aka= =0A= >>>>> Apple, Samsung, Microsoft in the context of a formal liaison with=0A= >>>>>3GPP.=0A= >>>>> Certainly the relevance of CNAM+/CNIT in enterprise and residential= =0A= >>>>> access markets is important but we all know =B3Money is the answer wh= at=0A= >>>>> is the question ..=B2=0A= >>>>>=0A= >>>>> I=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and= =0A= >>>>> report on the JTF on NNI. As you well know we have made considerable= =0A= >>>>> progress.=0A= >>>>>=0A= >>>>> Last week I gave a talk on this to a panel that included many of our= =0A= >>>>> friends among the national regulators.=0A= >>>>>=0A= >>>>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> From: "Holmes, David W [CTO]" =0A= >>>>> Date: Tuesday, February 24, 2015 at 5:06 PM=0A= >>>>> To: "Peterson, Jon" , "modern@ietf.org"=0A= >>>>> =0A= >>>>> Subject: Re: [Modern] draft charter=0A= >>>>>=0A= >>>>> Jon,=0A= >>>>>=0A= >>>>> Thank you for the work in assembling this draft of the charter for=0A= >>>>> MODERN.=0A= >>>>>=0A= >>>>> We would like to suggest some minor clarifications to the bullets=0A= >>>>> describing the deliverables, to align them with the statement=0A= >>>>>regarding=0A= >>>>> flexibility to support the needs of different regulatory regimes, &= =0A= >>>>> thus to ensure that if quoted alone they are not taken out of=0A= >>>>>context;=0A= >>>>> i.e. the group product will be the protocols to support the=0A= >>>>>allocation=0A= >>>>> etc. activities, & it would not attempt to define the allocation=0A= >>>>> processes. We also would like the charter to note the relevant work= =0A= >>>>> that has already been performed by both IETF & the ATIS/SIP Forum=0A= >>>>>JTF,=0A= >>>>> & incorporate that into the output from the MODERN WG as appropriate.= =0A= >>>>> These changes/additions are have been added to your text inline=0A= >>>>>below.=0A= >>>>>=0A= >>>>> We are hoping that the MODERN session at IETF#92 will have remote=0A= >>>>> access, to allow participation by those of us that cannot attend in= =0A= >>>>> person due to other commitments that week.=0A= >>>>>=0A= >>>>> Regards,=0A= >>>>>=0A= >>>>> David/Sprint=0A= >>>>>=0A= >>>>>=0A= >>>>>______________________________________________________________________= =0A= >>>>>__=0A= >>>>> ______=0A= >>>>>=0A= >>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson,= =0A= >>>>> Jon=0A= >>>>> Sent: Wednesday, February 11, 2015 9:19 AM=0A= >>>>> To: modern@ietf.org=0A= >>>>> Subject: [Modern] draft charter=0A= >>>>>=0A= >>>>>=0A= >>>>> At the Dallas IETF meeting in March, we'd like to get together and=0A= >>>>> talk about what a working group for MODERN might look like. As an=0A= >>>>> initial input to the discussion, a few of us have put together a=0A= >>>>> proposed charter. While the TeRQ work was positively evaluated in the= =0A= >>>>> DISPATCH process, we feel this is broader enough in scope to warrant= =0A= >>>>> its own BoF.=0A= >>>>>=0A= >>>>> Comments are welcome, this is just a starting point.=0A= >>>>>=0A= >>>>> ------=0A= >>>>>=0A= >>>>> Modern charter text:=0A= >>>>>=0A= >>>>> The MODERN working group will define a set of Internet-based=0A= >>>>> mechanisms for the purposes of managing and resolving telephone=0A= >>>>>numbers=0A= >>>>> (TNs) in an IP environment. Existing mechanisms for these purposes= =0A= >>>>> face obsolescence as the voice communications infrastructure evolves= =0A= >>>>>to=0A= >>>>> IP technology and new applications for TNs become possible. The=0A= >>>>> traditional model of a TN having an association to a single service= =0A= >>>>> provider and a single application is breaking down. Its use as a=0A= >>>>> network locator is going away, but its use as an identifier for an=0A= >>>>> individual or an organization will remain for some time. Devices,=0A= >>>>> applications, and network tools increasingly need to manage TNs,=0A= >>>>> including requesting and acquiring TN delegations from authorities.= =0A= >>>>>=0A= >>>>> The working group will define a framework for the roles and functions= =0A= >>>>> involved in managing and resolving TNs in an IP environment. This=0A= >>>>> includes a protocol mechanism for acquiring TNs, which will provide= =0A= >>>>>an=0A= >>>>> enrollment process for the individuals and entities that use and=0A= >>>>>manage=0A= >>>>> TNs. TNs may either be managed in a hierarchical tree, or in a=0A= >>>>> distributed peer-to-peer architecture. Privacy of the enrollment=0A= >>>>>data=0A= >>>>> and security of the resource will be primary considerations.=0A= >>>>>=0A= >>>>> Additionally, the working group will deliver a protocol mechanism for= =0A= >>>>> resolving TNs which will allow entities such as service providers,=0A= >>>>> devices, and applications to access data related to TNs, possibly=0A= >>>>> including caller name data (CNAM). Maintaining reliability, real=0A= >>>>>time=0A= >>>>> application performance, security and privacy are primary=0A= >>>>> considerations. The working group will take into consideration=0A= >>>>> existing IETF work including ENUM, SPEERMINT, STIR, and DRINKS.=0A= >>>>>=0A= >>>>> The work of this group is limited to specifying a solution for TNs=0A= >>>>>and=0A= >>>>> covers any service that can be addressed using a TN. Expanding the= =0A= >>>>> work to other identifiers is out of scope. Solutions and mechanisms= =0A= >>>>> created by the working group will be flexible enough to accommodate= =0A= >>>>> different policies, e.g., by different regulatory agencies.=0A= >>>>>=0A= >>>>> The work group will deliver the following:=0A= >>>>>=0A= >>>>> - An architecture overview document that includes high level= =0A= >>>>> requirements and security/privacy considerationsbuilt on the work of= =0A= >>>>> IETF & the ATIS/SIP Forum JTF, that included:=0A= >>>>> o Call routing architecture=0A= >>>>> o Inter-carrier NNI=0A= >>>>> o Cryptographically-enabled Anti-spoofing (STIR)=0A= >>>>> o Enhanced Calling Name (CNIT/CNAM)=0A= >>>>> - A document describing the protocols to support enrollment= =0A= >>>>> processes for existing and new TNs including any modifications to=0A= >>>>> metadata related to those TNs=0A= >>>>> - A document describing protocol mechanisms for accessing=0A= >>>>> contact information associated with enrollments=0A= >>>>> - A document describing protocol mechanisms for resolving=0A= >>>>> information related to TNs=0A= >>>>>=0A= >>>>> -=0A= >>>>>=0A= >>>>>=0A= >>>>> This e-mail may contain Sprint proprietary information intended for= =0A= >>>>> the sole use of the recipient(s). Any use by others is prohibited. If= =0A= >>>>> you are not the intended recipient, please contact the sender and=0A= >>>>> delete all copies of the message.=0A= >>>>> _______________________________________________ Modern mailing list= =0A= >>>>> Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern=0A= >>>>> _______________________________________________=0A= >>>>> dispatch mailing list=0A= >>>>> dispatch@ietf.org=0A= >>>>> https://www.ietf.org/mailman/listinfo/dispatch=0A= >>>> _______________________________________________ Modern mailing list=0A= >>>> Modern@ietf.org=0A= >>>>=0A= >>>>https://www.ietf.org/mailman/listinfo/modern___________________________= =0A= >>>>__=0A= >>>> __________________=0A= >>>> dispatch mailing list=0A= >>>> dispatch@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/dispatch=0A= >>>=0A= >>> _______________________________________________=0A= >>> dispatch mailing list=0A= >>> dispatch@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/dispatch=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> dispatch mailing list=0A= >> dispatch@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/dispatch=0A= >=0A= =0A= =0A= _______________________________________________=0A= cnit mailing list=0A= cnit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cnit=0A= From nobody Wed Mar 11 09:22:40 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252ED1ACDA3; Wed, 11 Mar 2015 09:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9cAn7WOdb7Z; Wed, 11 Mar 2015 09:22:34 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1656F1ACDA1; Wed, 11 Mar 2015 09:22:32 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Richard Shockey , Chris Wendt Thread-Topic: [dispatch] CNIT and Modern Charter Thread-Index: AQHQW2Qp9pBDczHOF06tIvLE6j2Plp0Xc6UrgAAELIY= Date: Wed, 11 Mar 2015 16:22:32 +0000 References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> <95353295-617C-4920-A581-4D0DFA02EDE4@chriswendt.net>, , 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-1250" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:22:38 -0000 To clarify, by "originator", I meant the originating service provider (carr= ier), i.e., the entity that holds the phone number. Case #2 would obviously= work in the case where the originating enterprise signs the call using 447= 4bis.=0A= =0A= ________________________________________=0A= From: cnit [cnit-bounces@ietf.org] on behalf of Henning Schulzrinne [Hennin= g.Schulzrinne@fcc.gov]=0A= Sent: Wednesday, March 11, 2015 12:19 PM=0A= To: Richard Shockey; Chris Wendt=0A= Cc: Cullen Jennings; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org=0A= Subject: Re: [cnit] [dispatch] CNIT and Modern Charter=0A= =0A= There seem to be two cases:=0A= =0A= (1) The originator of the call also provides the "CNAM" information, e.g., = based on their customer information.=0A= =0A= (2) A third party provides the CNAM information (e.g., a licensing entity o= r Dun & Bradstreet) that essentially says "I certify that the phone number = 212 555 1234 belongs to Citibank")=0A= =0A= Thus, there are two questions:=0A= =0A= (1) What information should be carried?=0A= =0A= (2) How does the cryptographic binding work?=0A= =0A= =0A= For example, would it make sense to have two 4474bis signatures, to address= case #2? Or should there be a separate signature that simply asserts the p= hone number to name binding, but it's not tied to the call itself.=0A= =0A= ________________________________________=0A= From: cnit [cnit-bounces@ietf.org] on behalf of Richard Shockey [richard@sh= ockey.us]=0A= Sent: Tuesday, March 10, 2015 2:57 PM=0A= To: Chris Wendt=0A= Cc: Cullen Jennings; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org=0A= Subject: Re: [cnit] [dispatch] CNIT and Modern Charter=0A= =0A= Exactly. If the IETF is going to remain responsible for core SIP=0A= protocols and signaling its our job to properly define these mechanisms.=0A= There is reason to believe if we don=92t do this it will be done for us.=0A= There were two bills in the US Congress about this last year and who knows= =0A= what elsewhere.=0A= =0A= IMHO the in band model is clearly the first use case. That alone would=0A= help a great deal.=0A= =0A= =0A= =0A= =0A= =0A= On 3/10/15, 2:37 PM, "Chris Wendt" wrote:=0A= =0A= >I agree that this would be useful just from the standpoint that if=0A= >service providers are going to implement in-band signing of caller-id,=0A= >would quite make sense to provide a better payload for delivering=0A= >additional and/or more useful calling party information along with=0A= >signing it as well.=0A= >=0A= >-Chris=0A= >=0A= >> On Mar 9, 2015, at 3:18 PM, Richard Shockey wrote:= =0A= >>=0A= >>=0A= >> The first order issue is properly defining what this looks like in SIP= =0A= >>and=0A= >> where in the headers it should reside. There is ample evidence that any= =0A= >> number of other SDO are looking at this and without some proper=0A= >> standardization there will be no interoperability at all especially even= =0A= >> for STIR validation data at the CUA and IMHO doing nothing is not a=0A= >>viable=0A= >> option. The basic FROM and PAI usage is not helpful.=0A= >>=0A= >> We are all aware of how smart phones work. This is principally about=0A= >> sessions that would originate outside a select number of phone book=0A= >> entries and some display of whether that information has been validated= =0A= >> though we don=B9t have to define policy at this stage and frankly I don= =B9t=0A= >> think the IETF should try any more than it could try and establish the= =0A= >> business model for how this would deploy.=0A= >>=0A= >> The purpose here is simply adding more information about who originated= =0A= >> the session so the called party has more information than they currently= =0A= >> have. We already have enough bad actors as it is impersonating tax=0A= >> authorities, banks, health care professionals and other governmental=0A= >> entities. The purpose is to try and bound those problems to a manageable= =0A= >> level. There is no silver bullet here.=0A= >>=0A= >> I would appreciate any suggestions on charter text if you have them.=0A= >>=0A= >>=0A= >>=0A= >> =8B=0A= >> Richard Shockey=0A= >> Shockey Consulting LLC=0A= >> Chairman of the Board SIP Forum=0A= >> www.shockey.us=0A= >> www.sipforum.org=0A= >> richardshockey.us=0A= >> Skype-Linkedin-Facebook rshockey101=0A= >> PSTN +1 703-593-2683=0A= >>=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> On 3/9/15, 11:10 AM, "Cullen Jennings" wrote:=0A= >>=0A= >>>=0A= >>> On the particular CNAM like topic ...=0A= >>>=0A= >>> I'm not keen on moving forward with something like this unless we can= =0A= >>> show the trust and human factors issues is an engineering problem not a= =0A= >>> research problem. We have seen the difficulty with human readable names= =0A= >>> in SPAM. Particularly when using UTF-8, how do we stop bad actor=0A= >>>getting=0A= >>> names that look the same as someone they wish to impersonate? Who will= =0A= >>> validate the names and issue some sort of trust token that says I can= =0A= >>>use=0A= >>> "Cullen Jennings" or whatever. Who else can use that name and what=0A= >>>about=0A= >>> names visually similar to it.=0A= >>>=0A= >>> On the flip side we are seeing most smart phones take the incoming=0A= >>>phone=0A= >>> number, and look it up the personal address book of the user and=0A= >>>display=0A= >>> the name that the user of the smartphone assigned. We are seeing=0A= >>> enterprise phones that do a similar things using the users social=0A= >>> networks as well as personal address book.=0A= >>>=0A= >>> What would be bad is phone display a display name that some how claimed= =0A= >>> to be trustable but was not. That would be worse that the current=0A= >>> situation. Perhaps people have a good way to solve this in mind but I'm= =0A= >>> not seeing that that is.=0A= >>>=0A= >>> Cullen (with my individual contribute hat on of course)=0A= >>>=0A= >>>=0A= >>>=0A= >>>> On Feb 25, 2015, at 10:05 AM, Richard Shockey =0A= >>>> wrote:=0A= >>>>=0A= >>>>=0A= >>>> Thanks Martin .. This is my very raw first cut at a charter. Its=0A= >>>> hopefully simple and straight forward.=0A= >>>>=0A= >>>> Send me any edits etc.=0A= >>>>=0A= >>>> *****=0A= >>>>=0A= >>>> CNIT Charter [Calling Name Identity Trust]=0A= >>>>=0A= >>>> WG Chairs TBD:=0A= >>>>=0A= >>>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters= =0A= >>>> of information associated with a specific E.164 calling party number= =0A= >>>>in=0A= >>>> the Public Switched Telephone Network [PSTN]. In the PSTN this data= =0A= >>>>is=0A= >>>> sent by the originating network only at the specific request of the=0A= >>>> terminating network via a SS7 Transaction Application Part [TCAP]=0A= >>>> response message. In the Session Initiation Protocol [SIP] this=0A= >>>> information can be inserted into the FROM: part of the originating=0A= >>>> INVITE message or by other means.=0A= >>>>=0A= >>>> As with the originating source telephone number, this data can be=0A= >>>> altered in transit creating a variety of malicious abuses similar to= =0A= >>>>the=0A= >>>> ones identified by the IETF STIR working group.=0A= >>>>=0A= >>>> The purpose of the CNIT working group will be to define a data=0A= >>>> structure, a new SIP header or repurpose an existing SIP header to=0A= >>>>carry=0A= >>>> an advanced form of CNAM as well as information from a STIR Validation= =0A= >>>> Authority. The purpose of this work is to present to the SIP called= =0A= >>>> party trusted information from the calling party in order that the=0A= >>>> called party make a more reasoned and informed judgment on whether to= =0A= >>>> accept the INVITE or not.=0A= >>>>=0A= >>>> The working group will not invalidate any existing SIP mechanism for= =0A= >>>> anonymous calling.=0A= >>>>=0A= >>>> The working group will, to the best of its ability, reuse existing=0A= >>>>IETF=0A= >>>> protocols.=0A= >>>>=0A= >>>> Full Internationalization of the Calling Name Identity Trust data=0A= >>>> object(s) is a requirement.=0A= >>>>=0A= >>>> The working group will closely work with the IETF STIR working group= =0A= >>>>=0A= >>>> The working group will immediately liaison with 3GPP SA-1 in order to= =0A= >>>> coordinate efforts.=0A= >>>>=0A= >>>> The working group will coordinate with National Numbering Authorities= =0A= >>>> and National Regulatory Authorities as needed.=0A= >>>>=0A= >>>> The working group will deliver the flowing.=0A= >>>>=0A= >>>> =80 A problem statement and requirements detailing the current=0A= >>>>deployment=0A= >>>> environment and situations that motivate work on Calling Name Identity= =0A= >>>> Trust.=0A= >>>> =80 Define either a new SIP header or document a repurpose of an SIP= =0A= >>>> existing header for Calling Name Identify Trust data=0A= >>>> =80 Define a data model for the Calling Name Identity Trust object (s= )=0A= >>>> which may include various forms of multimedia data=0A= >>>> =80 Deliver an analysis of privacy implications of the proposed Calli= ng=0A= >>>> Name Identity Trust mechanism.=0A= >>>>=0A= >>>>=0A= >>>> Milestones:=0A= >>>>=0A= >>>>=0A= >>>> =8B=0A= >>>> Richard Shockey=0A= >>>> Shockey Consulting LLC=0A= >>>> Chairman of the Board SIP Forum=0A= >>>> www.shockey.us=0A= >>>> www.sipforum.org=0A= >>>> richardshockey.us=0A= >>>> Skype-Linkedin-Facebook rshockey101=0A= >>>> PSTN +1 703-593-2683=0A= >>>>=0A= >>>>=0A= >>>> From: "DOLLY, MARTIN C" =0A= >>>> Date: Tuesday, February 24, 2015 at 9:02 PM=0A= >>>> To: Richard Shockey =0A= >>>> Cc: "Holmes, David W [CTO]" ,=0A= >>>> "dispatch@ietf.org" , "modern@ietf.org"=0A= >>>> , "Peterson, Jon" =0A= >>>> Subject: Re: [Modern] [dispatch] draft charter=0A= >>>>=0A= >>>> I support Richard on this=0A= >>>>=0A= >>>> Martin Dolly=0A= >>>> Lead Member of Technical Staff=0A= >>>> Core & Gov't/Regulatory Standards=0A= >>>> AT&T Standards and=0A= >>>> Industry Alliances=0A= >>>> +1-609-903-3390=0A= >>>> Sent from my iPhone=0A= >>>>=0A= >>>> On Feb 24, 2015, at 6:36 PM, Richard Shockey =0A= >>>>wrote:=0A= >>>>=0A= >>>>>=0A= >>>>> Excellent points David.=0A= >>>>>=0A= >>>>> My concern here is charter overreach. I really want to keep=0A= >>>>>CNAM+/CNIT=0A= >>>>> out of this. IMHO that is a very separate and highly focused effort= =0A= >>>>>to=0A= >>>>> define both the modification of the SIP headers necessary to support= =0A= >>>>> some enhanced calling party identification and a very limited effort= =0A= >>>>>to=0A= >>>>> define the object and or the STIR validation data.=0A= >>>>>=0A= >>>>> I=B9m violently opposed to =B3end world hunger=B2 WG=B9s.=0A= >>>>>=0A= >>>>> If registries can be used fine but I certainly want to see how this= =0A= >>>>> can be accomplished in bi lateral agreements between consenting=0A= >>>>>service=0A= >>>>> providers and work with CUA vendors on how the data is displayed aka= =0A= >>>>> Apple, Samsung, Microsoft in the context of a formal liaison with=0A= >>>>>3GPP.=0A= >>>>> Certainly the relevance of CNAM+/CNIT in enterprise and residential= =0A= >>>>> access markets is important but we all know =B3Money is the answer wh= at=0A= >>>>> is the question ..=B2=0A= >>>>>=0A= >>>>> I=B9ve asked for time in Dispatch to look at the CNAM/CNIT issue and= =0A= >>>>> report on the JTF on NNI. As you well know we have made considerable= =0A= >>>>> progress.=0A= >>>>>=0A= >>>>> Last week I gave a talk on this to a panel that included many of our= =0A= >>>>> friends among the national regulators.=0A= >>>>>=0A= >>>>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> From: "Holmes, David W [CTO]" =0A= >>>>> Date: Tuesday, February 24, 2015 at 5:06 PM=0A= >>>>> To: "Peterson, Jon" , "modern@ietf.org"=0A= >>>>> =0A= >>>>> Subject: Re: [Modern] draft charter=0A= >>>>>=0A= >>>>> Jon,=0A= >>>>>=0A= >>>>> Thank you for the work in assembling this draft of the charter for=0A= >>>>> MODERN.=0A= >>>>>=0A= >>>>> We would like to suggest some minor clarifications to the bullets=0A= >>>>> describing the deliverables, to align them with the statement=0A= >>>>>regarding=0A= >>>>> flexibility to support the needs of different regulatory regimes, &= =0A= >>>>> thus to ensure that if quoted alone they are not taken out of=0A= >>>>>context;=0A= >>>>> i.e. the group product will be the protocols to support the=0A= >>>>>allocation=0A= >>>>> etc. activities, & it would not attempt to define the allocation=0A= >>>>> processes. We also would like the charter to note the relevant work= =0A= >>>>> that has already been performed by both IETF & the ATIS/SIP Forum=0A= >>>>>JTF,=0A= >>>>> & incorporate that into the output from the MODERN WG as appropriate.= =0A= >>>>> These changes/additions are have been added to your text inline=0A= >>>>>below.=0A= >>>>>=0A= >>>>> We are hoping that the MODERN session at IETF#92 will have remote=0A= >>>>> access, to allow participation by those of us that cannot attend in= =0A= >>>>> person due to other commitments that week.=0A= >>>>>=0A= >>>>> Regards,=0A= >>>>>=0A= >>>>> David/Sprint=0A= >>>>>=0A= >>>>>=0A= >>>>>______________________________________________________________________= =0A= >>>>>__=0A= >>>>> ______=0A= >>>>>=0A= >>>>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson,= =0A= >>>>> Jon=0A= >>>>> Sent: Wednesday, February 11, 2015 9:19 AM=0A= >>>>> To: modern@ietf.org=0A= >>>>> Subject: [Modern] draft charter=0A= >>>>>=0A= >>>>>=0A= >>>>> At the Dallas IETF meeting in March, we'd like to get together and=0A= >>>>> talk about what a working group for MODERN might look like. As an=0A= >>>>> initial input to the discussion, a few of us have put together a=0A= >>>>> proposed charter. While the TeRQ work was positively evaluated in the= =0A= >>>>> DISPATCH process, we feel this is broader enough in scope to warrant= =0A= >>>>> its own BoF.=0A= >>>>>=0A= >>>>> Comments are welcome, this is just a starting point.=0A= >>>>>=0A= >>>>> ------=0A= >>>>>=0A= >>>>> Modern charter text:=0A= >>>>>=0A= >>>>> The MODERN working group will define a set of Internet-based=0A= >>>>> mechanisms for the purposes of managing and resolving telephone=0A= >>>>>numbers=0A= >>>>> (TNs) in an IP environment. Existing mechanisms for these purposes= =0A= >>>>> face obsolescence as the voice communications infrastructure evolves= =0A= >>>>>to=0A= >>>>> IP technology and new applications for TNs become possible. The=0A= >>>>> traditional model of a TN having an association to a single service= =0A= >>>>> provider and a single application is breaking down. Its use as a=0A= >>>>> network locator is going away, but its use as an identifier for an=0A= >>>>> individual or an organization will remain for some time. Devices,=0A= >>>>> applications, and network tools increasingly need to manage TNs,=0A= >>>>> including requesting and acquiring TN delegations from authorities.= =0A= >>>>>=0A= >>>>> The working group will define a framework for the roles and functions= =0A= >>>>> involved in managing and resolving TNs in an IP environment. This=0A= >>>>> includes a protocol mechanism for acquiring TNs, which will provide= =0A= >>>>>an=0A= >>>>> enrollment process for the individuals and entities that use and=0A= >>>>>manage=0A= >>>>> TNs. TNs may either be managed in a hierarchical tree, or in a=0A= >>>>> distributed peer-to-peer architecture. Privacy of the enrollment=0A= >>>>>data=0A= >>>>> and security of the resource will be primary considerations.=0A= >>>>>=0A= >>>>> Additionally, the working group will deliver a protocol mechanism for= =0A= >>>>> resolving TNs which will allow entities such as service providers,=0A= >>>>> devices, and applications to access data related to TNs, possibly=0A= >>>>> including caller name data (CNAM). Maintaining reliability, real=0A= >>>>>time=0A= >>>>> application performance, security and privacy are primary=0A= >>>>> considerations. The working group will take into consideration=0A= >>>>> existing IETF work including ENUM, SPEERMINT, STIR, and DRINKS.=0A= >>>>>=0A= >>>>> The work of this group is limited to specifying a solution for TNs=0A= >>>>>and=0A= >>>>> covers any service that can be addressed using a TN. Expanding the= =0A= >>>>> work to other identifiers is out of scope. Solutions and mechanisms= =0A= >>>>> created by the working group will be flexible enough to accommodate= =0A= >>>>> different policies, e.g., by different regulatory agencies.=0A= >>>>>=0A= >>>>> The work group will deliver the following:=0A= >>>>>=0A= >>>>> - An architecture overview document that includes high level= =0A= >>>>> requirements and security/privacy considerationsbuilt on the work of= =0A= >>>>> IETF & the ATIS/SIP Forum JTF, that included:=0A= >>>>> o Call routing architecture=0A= >>>>> o Inter-carrier NNI=0A= >>>>> o Cryptographically-enabled Anti-spoofing (STIR)=0A= >>>>> o Enhanced Calling Name (CNIT/CNAM)=0A= >>>>> - A document describing the protocols to support enrollment= =0A= >>>>> processes for existing and new TNs including any modifications to=0A= >>>>> metadata related to those TNs=0A= >>>>> - A document describing protocol mechanisms for accessing=0A= >>>>> contact information associated with enrollments=0A= >>>>> - A document describing protocol mechanisms for resolving=0A= >>>>> information related to TNs=0A= >>>>>=0A= >>>>> -=0A= >>>>>=0A= >>>>>=0A= >>>>> This e-mail may contain Sprint proprietary information intended for= =0A= >>>>> the sole use of the recipient(s). Any use by others is prohibited. If= =0A= >>>>> you are not the intended recipient, please contact the sender and=0A= >>>>> delete all copies of the message.=0A= >>>>> _______________________________________________ Modern mailing list= =0A= >>>>> Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern=0A= >>>>> _______________________________________________=0A= >>>>> dispatch mailing list=0A= >>>>> dispatch@ietf.org=0A= >>>>> https://www.ietf.org/mailman/listinfo/dispatch=0A= >>>> _______________________________________________ Modern mailing list=0A= >>>> Modern@ietf.org=0A= >>>>=0A= >>>>https://www.ietf.org/mailman/listinfo/modern___________________________= =0A= >>>>__=0A= >>>> __________________=0A= >>>> dispatch mailing list=0A= >>>> dispatch@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/dispatch=0A= >>>=0A= >>> _______________________________________________=0A= >>> dispatch mailing list=0A= >>> dispatch@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/dispatch=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> dispatch mailing list=0A= >> dispatch@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/dispatch=0A= >=0A= =0A= =0A= _______________________________________________=0A= cnit mailing list=0A= cnit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cnit=0A= =0A= _______________________________________________=0A= cnit mailing list=0A= cnit@ietf.org=0A= https://www.ietf.org/mailman/listinfo/cnit=0A= From nobody Wed Mar 11 09:25:49 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF901ACDBD; Wed, 11 Mar 2015 09:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhVyKjatS2CX; Wed, 11 Mar 2015 09:25:43 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 688771ACDB6; Wed, 11 Mar 2015 09:25:43 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Chris Wendt , Richard Shockey Thread-Topic: [Modern] [dispatch] CNIT and Modern Charter Thread-Index: AQHQWpFRPfjWBZZcskWPDn6pyztOXJ0UyXCAgAGHEwCAASoZpg== Date: Wed, 11 Mar 2015 16:25:41 +0000 References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> , <95353295-617C-4920-A581-4D0DFA02EDE4@chriswendt.net> In-Reply-To: <95353295-617C-4920-A581-4D0DFA02EDE4@chriswendt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:25:45 -0000 Would a simple vCard (RFC 7095) model work?=0A= =0A= ________________________________________=0A= From: Modern [modern-bounces@ietf.org] on behalf of Chris Wendt [chris-ietf= @chriswendt.net]=0A= Sent: Tuesday, March 10, 2015 2:37 PM=0A= To: Richard Shockey=0A= Cc: Cullen Jennings; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org=0A= Subject: Re: [Modern] [dispatch] CNIT and Modern Charter=0A= =0A= I agree that this would be useful just from the standpoint that if service = providers are going to implement in-band signing of caller-id, would quite = make sense to provide a better payload for delivering additional and/or mor= e useful calling party information along with signing it as well.=0A= =0A= -Chris=0A= =0A= From nobody Wed Mar 11 09:33:00 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD44C1A1A67; Wed, 11 Mar 2015 09:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arywO1wefGf5; Wed, 11 Mar 2015 09:32:54 -0700 (PDT) Received: from DC-IP-2.fcc.gov (dc-ip-2.fcc.gov [192.104.54.91]) by ietfa.amsl.com (Postfix) with ESMTP id 97EC61A1A65; Wed, 11 Mar 2015 09:32:53 -0700 (PDT) Message-ID: From: Henning Schulzrinne To: Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Thread-Topic: [dispatch] CNIT and Modern Charter Thread-Index: AQHQWpFRPfjWBZZcskWPDn6pyztOXJ0Xeygy Date: Wed, 11 Mar 2015 16:32:52 +0000 References: , <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> In-Reply-To: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:32:57 -0000 I think this highlights two options:=0A= =0A= (1) In-band delivery of the content, signed. The receiving device would nee= d to decide whether it trusts the signer.=0A= =0A= (2) Third-party lookup, where the number (STIR-signed) is used as a lookup = into a trustable database, rather similar to the CNAM model, but maybe with= additional cryptographic signing. In other words, the database contains si= gned vCards. The hard part is coordinating the databases in that case.=0A= =0A= (3) A combination of the two, where the Call-Info header provides the point= er. (That obviously already exists.)=0A= =0A= Henning=0A= =0A= ________________________________________=0A= From: dispatch [dispatch-bounces@ietf.org] on behalf of Cullen Jennings [fl= uffy@cisco.com]=0A= Sent: Monday, March 09, 2015 11:10 AM=0A= To: cnit@ietf.org; dispatch@ietf.org; modern@ietf.org=0A= Subject: [dispatch] CNIT and Modern Charter=0A= =0A= On the particular CNAM like topic ...=0A= =0A= I'm not keen on moving forward with something like this unless we can show = the trust and human factors issues is an engineering problem not a research= problem. We have seen the difficulty with human readable names in SPAM. Pa= rticularly when using UTF-8, how do we stop bad actor getting names that lo= ok the same as someone they wish to impersonate? Who will validate the name= s and issue some sort of trust token that says I can use "Cullen Jennings" = or whatever. Who else can use that name and what about names visually simil= ar to it.=0A= =0A= On the flip side we are seeing most smart phones take the incoming phone nu= mber, and look it up the personal address book of the user and display the = name that the user of the smartphone assigned. We are seeing enterprise pho= nes that do a similar things using the users social networks as well as pe= rsonal address book.=0A= =0A= What would be bad is phone display a display name that some how claimed to = be trustable but was not. That would be worse that the current situation. P= erhaps people have a good way to solve this in mind but I'm not seeing that= that is.=0A= =0A= Cullen (with my individual contribute hat on of course)=0A= =0A= From nobody Wed Mar 11 09:43:35 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CD41A0194 for ; Wed, 11 Mar 2015 09:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UL_Zb8AK_Of for ; Wed, 11 Mar 2015 09:43:33 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id D22B31A1A51 for ; Wed, 11 Mar 2015 09:43:31 -0700 (PDT) Received: (qmail 5313 invoked by uid 0); 11 Mar 2015 16:43:27 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 11 Mar 2015 16:43:27 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id 2NjL1q0161MNPNq01NjPGs; Wed, 11 Mar 2015 16:43:26 -0600 X-Authority-Analysis: v=2.1 cv=GJqbTI9K c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=kj9zAlcOel0A:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=emO1SXQWCLwA:10 a=48vgC7mUAAAA:8 a=w1VtefKfAAAA:8 a=u2-l-pxlSrty6TQNgx4A:9 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID:CC:To:From:Subject:Date; bh=uvisAnkW/2OPrfkLvOw5+kC6yXRjZNMGDtuFely2cAM=; b=QmWYDlXaI7yuQt0arTJHZF76+h8F1wkkuEEPiIfWUEvuqB6DMp6LoVYl5Pl28hIgIQl8ttCL+ES0hO0HVKi70x9z5jNMYw4mTg98aYVjXPJg9pL8zVpiYt9KxH4UNKKf; Received: from [108.56.131.201] (port=50644 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YVjj8-0000n3-17; Wed, 11 Mar 2015 10:43:22 -0600 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Wed, 11 Mar 2015 12:43:15 -0400 From: Richard Shockey To: Henning Schulzrinne , Chris Wendt Message-ID: Thread-Topic: [cnit] [Modern] [dispatch] CNIT and Modern Charter Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [cnit] [Modern] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:43:34 -0000 That was certainly my initial idea. URI in the Call-Info header at the very least. Something useful. On 3/11/15, 12:25 PM, "Henning Schulzrinne" wrote: >Would a simple vCard (RFC 7095) model work? > >________________________________________ >From: Modern [modern-bounces@ietf.org] on behalf of Chris Wendt >[chris-ietf@chriswendt.net] >Sent: Tuesday, March 10, 2015 2:37 PM >To: Richard Shockey >Cc: Cullen Jennings; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org >Subject: Re: [Modern] [dispatch] CNIT and Modern Charter > >I agree that this would be useful just from the standpoint that if >service providers are going to implement in-band signing of caller-id, >would quite make sense to provide a better payload for delivering >additional and/or more useful calling party information along with >signing it as well. > >-Chris > > >_______________________________________________ >cnit mailing list >cnit@ietf.org >https://www.ietf.org/mailman/listinfo/cnit From nobody Wed Mar 11 11:32:43 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E021A711A for ; Wed, 11 Mar 2015 11:32:37 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 Sz1BfNhd28ga for ; Wed, 11 Mar 2015 11:32:33 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (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 36FF11A7013 for ; Wed, 11 Mar 2015 11:32:33 -0700 (PDT) Received: by qcvp6 with SMTP id p6so12569978qcv.1 for ; Wed, 11 Mar 2015 11:32:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=qH8TFh+0BnHdoR2sncbvPCRg+ymPRAz6cpSy9WBT0XQ=; b=O3jjq5jfeqAT0LbW6jevTb88U7aXSa1/eVVeTBRCtLS6EFe7ZxhF+45W/6+cRzstvm MqvwVy/BGCsGgPKeeZZK+H5qn/dYSQBoZViHqKifSIobf+8992aqPe/JNUy4km7W9xkE sfMedT6OLiu4YieaIyQ+B9EBBmo36S6RKKs0cuFveNFacPk4iHxLcjjpQaqRCVVFHn/4 Phd39Q+P4c0M0bNEl9Hi6f8bYMKyTFhRuNSnYHt/Z5mPUQQX4bqyiLpQ5pSIFByTkq61 VZGlLqFSIfAEMPDV/qdtCtmYwUnJj/95H5dQOVsP8DjEq+wmYxxD/UKEzDUNyOUTF1oS bzxQ== X-Gm-Message-State: ALoCoQn/HSxFOQbiMh68zyMBQZDliERJ4Snj9+wItFDdeT6MZQINUwpPE+5SHmy8t66cjZsLlU64 X-Received: by 10.55.42.37 with SMTP id q37mr64123807qkh.90.1426098752498; Wed, 11 Mar 2015 11:32:32 -0700 (PDT) Received: from chriss-mbp.lan (c-69-247-98-104.hsd1.pa.comcast.net. [69.247.98.104]) by mx.google.com with ESMTPSA id n41sm3097448qkh.3.2015.03.11.11.32.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Mar 2015 11:32:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2081\)) From: Chris Wendt In-Reply-To: Date: Wed, 11 Mar 2015 14:32:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <84A855FD-5E80-491A-9DAC-D953AC3FDED8@chriswendt.net> References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> <, <95353295-617C-4920-A581-4D0DFA02EDE4@chriswendt.net> <>> To: Henning Schulzrinne X-Mailer: Apple Mail (2.2081) Archived-At: Cc: Cullen Jennings , "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:32:38 -0000 I think that makes a lot of sense. > On Mar 11, 2015, at 12:25 PM, Henning Schulzrinne = wrote: >=20 > Would a simple vCard (RFC 7095) model work? >=20 > ________________________________________ > From: Modern [modern-bounces@ietf.org] on behalf of Chris Wendt = [chris-ietf@chriswendt.net] > Sent: Tuesday, March 10, 2015 2:37 PM > To: Richard Shockey > Cc: Cullen Jennings; cnit@ietf.org; dispatch@ietf.org; modern@ietf.org > Subject: Re: [Modern] [dispatch] CNIT and Modern Charter >=20 > I agree that this would be useful just from the standpoint that if = service providers are going to implement in-band signing of caller-id, = would quite make sense to provide a better payload for delivering = additional and/or more useful calling party information along with = signing it as well. >=20 > -Chris >=20 From nobody Sun Mar 15 18:26:57 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C871A1EEE; Sun, 15 Mar 2015 18:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.908 X-Spam-Level: X-Spam-Status: No, score=0.908 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUhwLJ6kmtdZ; Sun, 15 Mar 2015 18:26:53 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DD11A1EEA; Sun, 15 Mar 2015 18:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=rNh+JK+13BSF0qi1MnNt4gikrZ3LkllFyYmkdPG6eug=; b=h9kUaHTOzTik4zWYwwBPsHjSHJFBKM7BJl3uqVFZQKrnz15zoTYeW5X9l3re8TwE7bMB/V67DO1aPAJVMO7Hldiv9Kde+njWSLlOcwMh3Z9EwYtZ//bM7h/hDVBiBvBUTgUSE4sjmujmibrI6jIICZg9f62P/OiHx5T34eHGdNE=; Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:52063 helo=[192.168.15.131]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YXJnr-0004Gf-4a; Sun, 15 Mar 2015 18:26:50 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_72043189-C87C-4B87-8471-FE7DBB1E61EA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b5 From: Eric Burger In-Reply-To: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> Date: Sun, 15 Mar 2015 21:26:47 -0400 Message-Id: <5DA45143-E51A-483E-8191-5F9DBFD9BD3E@standardstrack.com> References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> To: cnit@ietf.org, "dispatch@ietf.org" , "modern@ietf.org" X-Mailer: Apple Mail (2.2070.6) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 01:26:56 -0000 --Apple-Mail=_72043189-C87C-4B87-8471-FE7DBB1E61EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is IDN all over again. On the one hand, we need to be aware that = some bad people will try to =CF=81=CE=B7=CE=B9=CF=82=CE=B7 instead of = =CF=86=CE=B9=CF=83, because the former looks like phish. On the other = hand, last I looked, this is the IETF, and a US-centric or = Roman-script-centric solution is not going to be internationally = acceptable. Sincerely, =E6=9F=8F=E5=B0=94=E7=AB=8B P.S., while we are expanding the charter to encompass the ocean, can I = specify =E2=80=9CEric Burger=E2=80=9D for domestic calls and = "=E6=9F=8F=E5=B0=94=E7=AB=8B=E2=80=9D for calls to China? ;-) > On Mar 9, 2015, at 11:10 AM, Cullen Jennings wrote: >=20 >=20 > On the particular CNAM like topic ... >=20 > I'm not keen on moving forward with something like this unless we can = show the trust and human factors issues is an engineering problem not a = research problem. We have seen the difficulty with human readable names = in SPAM. Particularly when using UTF-8, how do we stop bad actor getting = names that look the same as someone they wish to impersonate? Who will = validate the names and issue some sort of trust token that says I can = use "Cullen Jennings" or whatever. Who else can use that name and what = about names visually similar to it. >=20 > On the flip side we are seeing most smart phones take the incoming = phone number, and look it up the personal address book of the user and = display the name that the user of the smartphone assigned. We are seeing = enterprise phones that do a similar things using the users social = networks as well as personal address book. >=20 > What would be bad is phone display a display name that some how = claimed to be trustable but was not. That would be worse that the = current situation. Perhaps people have a good way to solve this in mind = but I'm not seeing that that is. >=20 > Cullen (with my individual contribute hat on of course) >=20 >=20 >=20 >> On Feb 25, 2015, at 10:05 AM, Richard Shockey = wrote: >>=20 >>=20 >> Thanks Martin .. This is my very raw first cut at a charter. Its = hopefully simple and straight forward. >>=20 >> Send me any edits etc. >>=20 >> ***** >>=20 >> CNIT Charter [Calling Name Identity Trust] >>=20 >> WG Chairs TBD: >>=20 >> Calling Name Delivery [CNAM] is a string of up to 15 ASCII Characters = of information associated with a specific E.164 calling party number in = the Public Switched Telephone Network [PSTN]. In the PSTN this data is = sent by the originating network only at the specific request of the = terminating network via a SS7 Transaction Application Part [TCAP] = response message. In the Session Initiation Protocol [SIP] this = information can be inserted into the FROM: part of the originating = INVITE message or by other means. >>=20 >> As with the originating source telephone number, this data can be = altered in transit creating a variety of malicious abuses similar to the = ones identified by the IETF STIR working group. >>=20 >> The purpose of the CNIT working group will be to define a data = structure, a new SIP header or repurpose an existing SIP header to carry = an advanced form of CNAM as well as information from a STIR Validation = Authority. The purpose of this work is to present to the SIP called = party trusted information from the calling party in order that the = called party make a more reasoned and informed judgment on whether to = accept the INVITE or not. >>=20 >> The working group will not invalidate any existing SIP mechanism for = anonymous calling. >>=20 >> The working group will, to the best of its ability, reuse existing = IETF protocols. >>=20 >> Full Internationalization of the Calling Name Identity Trust data = object(s) is a requirement. >>=20 >> The working group will closely work with the IETF STIR working group >>=20 >> The working group will immediately liaison with 3GPP SA-1 in order to = coordinate efforts. >>=20 >> The working group will coordinate with National Numbering Authorities = and National Regulatory Authorities as needed. >>=20 >> The working group will deliver the flowing. >>=20 >> =E2=80=A2 A problem statement and requirements detailing the = current deployment environment and situations that motivate work on = Calling Name Identity Trust. >> =E2=80=A2 Define either a new SIP header or document a repurpose = of an SIP existing header for Calling Name Identify Trust data >> =E2=80=A2 Define a data model for the Calling Name Identity Trust = object (s) which may include various forms of multimedia data >> =E2=80=A2 Deliver an analysis of privacy implications of the = proposed Calling Name Identity Trust mechanism. >>=20 >>=20 >> Milestones: >>=20 >>=20 >> =E2=80=94 >> Richard Shockey >> Shockey Consulting LLC >> Chairman of the Board SIP Forum >> www.shockey.us >> www.sipforum.org >> richardshockey.us >> Skype-Linkedin-Facebook rshockey101 >> PSTN +1 703-593-2683 >>=20 >>=20 >> From: "DOLLY, MARTIN C" >> Date: Tuesday, February 24, 2015 at 9:02 PM >> To: Richard Shockey >> Cc: "Holmes, David W [CTO]" , = "dispatch@ietf.org" , "modern@ietf.org" = , "Peterson, Jon" >> Subject: Re: [Modern] [dispatch] draft charter >>=20 >> I support Richard on this >>=20 >> Martin Dolly >> Lead Member of Technical Staff >> Core & Gov't/Regulatory Standards >> AT&T Standards and >> Industry Alliances >> +1-609-903-3390 >> Sent from my iPhone >>=20 >> On Feb 24, 2015, at 6:36 PM, Richard Shockey = wrote: >>=20 >>>=20 >>> Excellent points David. >>>=20 >>> My concern here is charter overreach. I really want to keep = CNAM+/CNIT out of this. IMHO that is a very separate and highly focused = effort to define both the modification of the SIP headers necessary to = support some enhanced calling party identification and a very limited = effort to define the object and or the STIR validation data. >>>=20 >>> I=E2=80=99m violently opposed to =E2=80=9Cend world hunger=E2=80=9D = WG=E2=80=99s. >>>=20 >>> If registries can be used fine but I certainly want to see how this = can be accomplished in bi lateral agreements between consenting service = providers and work with CUA vendors on how the data is displayed aka = Apple, Samsung, Microsoft in the context of a formal liaison with 3GPP. = Certainly the relevance of CNAM+/CNIT in enterprise and residential = access markets is important but we all know =E2=80=9CMoney is the answer = what is the question ..=E2=80=9D >>>=20 >>> I=E2=80=99ve asked for time in Dispatch to look at the CNAM/CNIT = issue and report on the JTF on NNI. As you well know we have made = considerable progress. >>>=20 >>> Last week I gave a talk on this to a panel that included many of our = friends among the national regulators. >>>=20 >>> http://apps.fcc.gov/ecfs/document/view?id=3D60001033217 >>>=20 >>>=20 >>>=20 >>> From: "Holmes, David W [CTO]" >>> Date: Tuesday, February 24, 2015 at 5:06 PM >>> To: "Peterson, Jon" , "modern@ietf.org" = >>> Subject: Re: [Modern] draft charter >>>=20 >>> Jon, >>>=20 >>> Thank you for the work in assembling this draft of the charter for = MODERN. >>>=20 >>> We would like to suggest some minor clarifications to the bullets = describing the deliverables, to align them with the statement regarding = flexibility to support the needs of different regulatory regimes, & thus = to ensure that if quoted alone they are not taken out of context; i.e. = the group product will be the protocols to support the allocation etc. = activities, & it would not attempt to define the allocation processes. = We also would like the charter to note the relevant work that has = already been performed by both IETF & the ATIS/SIP Forum JTF, & = incorporate that into the output from the MODERN WG as appropriate. = These changes/additions are have been added to your text inline below. >>>=20 >>> We are hoping that the MODERN session at IETF#92 will have remote = access, to allow participation by those of us that cannot attend in = person due to other commitments that week. >>>=20 >>> Regards, >>>=20 >>> David/Sprint >>> = __________________________________________________________________________= ____ >>>=20 >>> From: Modern [mailto:modern-bounces@ietf.org] On Behalf Of Peterson, = Jon >>> Sent: Wednesday, February 11, 2015 9:19 AM >>> To: modern@ietf.org >>> Subject: [Modern] draft charter >>>=20 >>>=20 >>> At the Dallas IETF meeting in March, we'd like to get together and = talk about what a working group for MODERN might look like. As an = initial input to the discussion, a few of us have put together a = proposed charter. While the TeRQ work was positively evaluated in the = DISPATCH process, we feel this is broader enough in scope to warrant its = own BoF. >>>=20 >>> Comments are welcome, this is just a starting point. >>>=20 >>> ------ >>>=20 >>> Modern charter text: >>>=20 >>> The MODERN working group will define a set of Internet-based = mechanisms for the purposes of managing and resolving telephone numbers = (TNs) in an IP environment. Existing mechanisms for these purposes face = obsolescence as the voice communications infrastructure evolves to IP = technology and new applications for TNs become possible. The = traditional model of a TN having an association to a single service = provider and a single application is breaking down. Its use as a = network locator is going away, but its use as an identifier for an = individual or an organization will remain for some time. Devices, = applications, and network tools increasingly need to manage TNs, = including requesting and acquiring TN delegations from authorities. >>>=20 >>> The working group will define a framework for the roles and = functions involved in managing and resolving TNs in an IP environment. = This includes a protocol mechanism for acquiring TNs, which will provide = an enrollment process for the individuals and entities that use and = manage TNs. TNs may either be managed in a hierarchical tree, or in a = distributed peer-to-peer architecture. Privacy of the enrollment data = and security of the resource will be primary considerations. >>>=20 >>> Additionally, the working group will deliver a protocol mechanism = for resolving TNs which will allow entities such as service providers, = devices, and applications to access data related to TNs, possibly = including caller name data (CNAM). Maintaining reliability, real time = application performance, security and privacy are primary = considerations. The working group will take into consideration existing = IETF work including ENUM, SPEERMINT, STIR, and DRINKS. >>>=20 >>> The work of this group is limited to specifying a solution for TNs = and covers any service that can be addressed using a TN. Expanding the = work to other identifiers is out of scope. Solutions and mechanisms = created by the working group will be flexible enough to accommodate = different policies, e.g., by different regulatory agencies. >>>=20 >>> The work group will deliver the following: >>>=20 >>> - An architecture overview document that includes high = level requirements and security/privacy considerationsbuilt on the work = of IETF & the ATIS/SIP Forum JTF, that included: >>> o Call routing architecture >>> o Inter-carrier NNI >>> o Cryptographically-enabled Anti-spoofing (STIR) >>> o Enhanced Calling Name (CNIT/CNAM) >>> - A document describing the protocols to support enrollment = processes for existing and new TNs including any modifications to = metadata related to those TNs >>> - A document describing protocol mechanisms for accessing = contact information associated with enrollments >>> - A document describing protocol mechanisms for resolving = information related to TNs >>>=20 >>> - >>>=20 >>>=20 >>> This e-mail may contain Sprint proprietary information intended for = the sole use of the recipient(s). Any use by others is prohibited. If = you are not the intended recipient, please contact the sender and delete = all copies of the message. >>> _______________________________________________ Modern mailing list = Modern@ietf.org https://www.ietf.org/mailman/listinfo/modern >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ Modern mailing list = Modern@ietf.org = https://www.ietf.org/mailman/listinfo/modern______________________________= _________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > Modern mailing list > Modern@ietf.org > https://www.ietf.org/mailman/listinfo/modern --Apple-Mail=_72043189-C87C-4B87-8471-FE7DBB1E61EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJVBjFYAAoJEDY/T2tCIPW3lpQP/010irvCSHB5rHoTcr+MDEG9 SL6WWrEAVRkMFfatT5w8IEShai0wccnHSuv52gEZpbwWNbaIfy+6F1VpztghFxJc XVniFYKNVqfpzKc0YzHboS46wA0yhIuaGLIsQsB5/EBWBZxLC1MtTmpbOmz8fZli mdGrP65YoZQPHJYsuSAgf23XbNRyDR131Ox7Y5x48Aa7Y4iNYArHgFD5b3OAu/j6 gIGQUf4iL4LwEO0FwL4yS29ykD1rOacaFIoE8oaICcYDCsied0lwX9N1Ip6E1Kga +Y1PmGOQOPrUi2zc9wJhhLtLUvJ4I8EXV5uhrcBrd4cblkpoKWTRmwtYafdVpsn1 tQTPKzNa3NuiAcD/XTeKaIy7QmHUsYF/1GB5tVCjQOVTHsX5wZpeeSdYNwfBBw0A iJAfNxHDDvmhENpD2ax4KS3czx3IxZkgxpCpXza+VV22ZU+mtfAw0ZoJghOavj/Y C8OxkOisb/JwtXwQZyER+wYkJfX4Bq1bpulmWG2Vpai1iR0iOvrZ8q/DAVLhGt5D Jhp00hN4rreCw8B5YD9Zq4BDaLdFKotSC8otGvTqoj1CI1Z4pwdx/hSrWmTX9yKN lluWW//POFUmULI7rglqfnoKEmDfDqEZaaVTp6yKVYrloHge21qnsIwNlXCsQ1Pk d2qJpLsUdYwZOLQc2iQ0 =mMAC -----END PGP SIGNATURE----- --Apple-Mail=_72043189-C87C-4B87-8471-FE7DBB1E61EA-- From nobody Sun Mar 15 18:52:40 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C880C1A212A for ; Sun, 15 Mar 2015 18:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jpeuhWLzrYf for ; Sun, 15 Mar 2015 18:52:37 -0700 (PDT) Received: from millet.cc.columbia.edu (millet.cc.columbia.edu [128.59.72.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FFB1A1EFE for ; Sun, 15 Mar 2015 18:52:37 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t2G1p25A028543 for ; Sun, 15 Mar 2015 21:52:36 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 9777F7E for ; Sun, 15 Mar 2015 21:52:36 -0400 (EDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by hazelnut (Postfix) with ESMTP id 7FF747E for ; Sun, 15 Mar 2015 21:52:36 -0400 (EDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2G1qarL022675 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 15 Mar 2015 21:52:36 -0400 (EDT) Received: by qgez64 with SMTP id z64so29221901qge.2 for ; Sun, 15 Mar 2015 18:52:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0Ho7rYc/U6sRAr3W7PDffmcKXr+FjjF592AZ8VaE6kQ=; b=A458RiBmiht75f3splO0KZ8ap9ZnKB1lCWzsqGAr+wE3BHkkuzMVlUt25PDkAc9qw3 UNEc/hecYiRA8prAIGjya2S3UX/UNdgThKpyHZjTj6Mu74AyHOTsi/lxCMO7ZwK5VpUa 3m/kKTTTej/Q5SrYXTj8rhQBNmXBRGTqdicK+n31BYsgHX9IXv4y2wlqbMDQQSFxeHwX JwWnwFKbyV5UqUnAhujijt8JJEWihBpQEEv91r+EyXzaBoQpBOfJEvykqnRa3UoJrhtI xFfRWYiDrHSZfDYALaW1VF/+2OSVLdvjHGsIYwS9RPZe471m6qFTHSTtCFRKxuBUYvMm 1zHQ== X-Gm-Message-State: ALoCoQm6yEX9AXUQdMgTsT0JKi1lsVZrq0DSWKQkcyTk6hS7zPM2UIp7W5OnSd1jknx8BYQ0ZlmZGVrZV0RKKZvi/b1oO9SHA6GW0yCnay5IkXnW9G+yQh5Wb5VJ9SgQ3X0on49xDIdW X-Received: by 10.55.31.101 with SMTP id f98mr75197086qkf.34.1426470756093; Sun, 15 Mar 2015 18:52:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.31.101 with SMTP id f98mr75197077qkf.34.1426470756008; Sun, 15 Mar 2015 18:52:36 -0700 (PDT) Received: by 10.140.250.2 with HTTP; Sun, 15 Mar 2015 18:52:35 -0700 (PDT) In-Reply-To: <5DA45143-E51A-483E-8191-5F9DBFD9BD3E@standardstrack.com> References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> <5DA45143-E51A-483E-8191-5F9DBFD9BD3E@standardstrack.com> Date: Sun, 15 Mar 2015 21:52:35 -0400 Message-ID: From: Henning Schulzrinne To: Eric Burger Content-Type: multipart/alternative; boundary=001a11478920b1de2705115e1a26 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Archived-At: Cc: cnit@ietf.org, "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 01:52:39 -0000 --001a11478920b1de2705115e1a26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This seems like a separable problem, i.e., where the mechanism of preventing IDN impersonation is left to the certifying entity. Unlike for web pages, these entities are likely to be domestic so that a callee is likely to be suspicious if it receives a Russian-certified caller that kind of looks like Citibank. But you illustrate a good reason why certifying the type of entity (e.g., FDIC-insured bank, registered medical provider) may be more important than relying on a name alone. Henning On Sun, Mar 15, 2015 at 9:26 PM, Eric Burger wrote: > This is IDN all over again. On the one hand, we need to be aware that som= e > bad people will try to =CF=81=CE=B7=CE=B9=CF=82=CE=B7 instead of =CF=86= =CE=B9=CF=83, because the former looks like > phish. On the other hand, last I looked, this is the IETF, and a US-centr= ic > or Roman-script-centric solution is not going to be internationally > acceptable. > > Sincerely, > =E6=9F=8F=E5=B0=94=E7=AB=8B > > P.S., while we are expanding the charter to encompass the ocean, can I > specify =E2=80=9CEric Burger=E2=80=9D for domestic calls and "=E6=9F=8F= =E5=B0=94=E7=AB=8B=E2=80=9D for calls to China? ;-) > > --001a11478920b1de2705115e1a26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems like a separable problem, i.e., where the mecha= nism of preventing IDN impersonation is left to the certifying entity. Unli= ke for web pages, these entities are likely to be domestic so that a callee= is likely to be suspicious if it receives a Russian-certified caller that = kind of looks like Citibank. But you illustrate a good reason why certifyin= g the type of entity (e.g., FDIC-insured bank, registered medical provider)= may be more important than relying on a name alone.

--001a11478920b1de2705115e1a26-- From nobody Mon Mar 16 04:12:58 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D0B1A00CD; Mon, 16 Mar 2015 04:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auxnq3I06GIZ; Mon, 16 Mar 2015 04:12:51 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14841A00B8; Mon, 16 Mar 2015 04:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:Date:Subject:From:Cc:Message-Id:Content-Transfer-Encoding:Content-Type:In-Reply-To:Mime-Version:References; bh=iED45oqTAZDrOgSQ2WAtGWIY7u2UUEO9RaQxZuVl76c=; b=JDqlRWa4GRakoFdA/wr9VKbIPbqmTd3Eu0uYkz8KWeRkVREj2pM8+tCghr/Pzryti0+8Fo55WCtnXAg674VUCU+DHfLU/f1qpitZm8Ae04imhSST27UBPwbCADr+6xoXbJodQpXM0hoYRsiYVvX9JKxxA2w8GobNFS0MtjonIzA=; Received: from ip68-100-74-115.dc.dc.cox.net ([68.100.74.115]:60950 helo=[192.168.15.138]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YXSwx-0001yD-5Y; Mon, 16 Mar 2015 04:12:50 -0700 References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> <5DA45143-E51A-483E-8191-5F9DBFD9BD3E@standardstrack.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-70C7F696-3365-4648-BDAB-46E64ECCF41A Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (12B466) From: Eric Burger Date: Mon, 16 Mar 2015 07:12:50 -0400 To: Henning Schulzrinne X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Cc: "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 11:12:55 -0000 --Apple-Mail-70C7F696-3365-4648-BDAB-46E64ECCF41A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In principle this makes sense. However, if we cannot get the world to agree o= n countries (e.g., Tibet, Taiwan, etc.), how are we going to get an agreed l= ist of enterprise types? We could go the ITU route and define the protocol m= achinery and leave the enterprise definitions a local matter. However, that d= oes not foster global interoperability. Moreover, your state-sponsored sourc= e of foreign currency might look to me to be a criminal enterprise. Would it= be a registered bank or a registered 'trading' company? -- Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF= LEMONADE for mobile email! See > On Mar 15, 2015, at 9:52 PM, Henning Schulzrinne wro= te: >=20 > This seems like a separable problem, i.e., where the mechanism of preventi= ng IDN impersonation is left to the certifying entity. Unlike for web pages,= these entities are likely to be domestic so that a callee is likely to be s= uspicious if it receives a Russian-certified caller that kind of looks like C= itibank. But you illustrate a good reason why certifying the type of entity (= e.g., FDIC-insured bank, registered medical provider) may be more important t= han relying on a name alone. >=20 > Henning >=20 >> On Sun, Mar 15, 2015 at 9:26 PM, Eric Burger = wrote: >> This is IDN all over again. On the one hand, we need to be aware that som= e bad people will try to =CF=81=CE=B7=CE=B9=CF=82=CE=B7 instead of =CF=86=CE= =B9=CF=83, because the former looks like phish. On the other hand, last I lo= oked, this is the IETF, and a US-centric or Roman-script-centric solution is= not going to be internationally acceptable. >>=20 >> Sincerely, >> =E6=9F=8F=E5=B0=94=E7=AB=8B >>=20 >> P.S., while we are expanding the charter to encompass the ocean, can I sp= ecify =E2=80=9CEric Burger=E2=80=9D for domestic calls and "=E6=9F=8F=E5=B0=94= =E7=AB=8B=E2=80=9D for calls to China? ;-) --Apple-Mail-70C7F696-3365-4648-BDAB-46E64ECCF41A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Mar 15, 2015, at 9:52 PM,= Henning Schulzrinne <hgs@cs.colum= bia.edu> wrote:

This seems like a separable problem, i.e., where the mechanism of prev= enting IDN impersonation is left to the certifying entity. Unlike for web pa= ges, these entities are likely to be domestic so that a callee is likely to b= e suspicious if it receives a Russian-certified caller that kind of looks li= ke Citibank. But you illustrate a good reason why certifying the type of ent= ity (e.g., FDIC-insured bank, registered medical provider) may be more impor= tant than relying on a name alone.

Henning

On Sun, Mar 15, 2015 at 9:26 PM= , Eric Burger <eburger@standardstrack.com> wrote:
=
This is IDN all over again. On the one hand, w= e need to be aware that some bad people will try to =CF=81=CE=B7=CE=B9=CF=82= =CE=B7 instead of =CF=86=CE=B9=CF=83, because the former looks like phish. O= n the other hand, last I looked, this is the IETF, and a US-centric or Roman= -script-centric solution is not going to be internationally acceptable.

Sincerely,
=E6=9F=8F=E5=B0=94=E7=AB=8B

P.S., while we are expanding the charter to encompass the ocean, can I speci= fy =E2=80=9CEric Burger=E2=80=9D for domestic calls and "=E6=9F=8F=E5=B0=94=E7= =AB=8B=E2=80=9D for calls to China? ;-)

= --Apple-Mail-70C7F696-3365-4648-BDAB-46E64ECCF41A-- From nobody Mon Mar 16 05:10:39 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D2F1A8707 for ; Mon, 16 Mar 2015 05:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B8dej_omL37 for ; Mon, 16 Mar 2015 05:10:36 -0700 (PDT) Received: from buckwheat.cc.columbia.edu (buckwheat.cc.columbia.edu [128.59.72.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316D61A8702 for ; Mon, 16 Mar 2015 05:10:36 -0700 (PDT) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by buckwheat.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t2GC834r021135 for ; Mon, 16 Mar 2015 08:10:35 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 00ECA7E for ; Mon, 16 Mar 2015 08:10:35 -0400 (EDT) Received: from salak.cc.columbia.edu (salak.cc.columbia.edu [128.59.29.6]) by hazelnut (Postfix) with ESMTP id DCFD27E for ; Mon, 16 Mar 2015 08:10:34 -0400 (EDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by salak.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2GCAYNl010354 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 16 Mar 2015 08:10:34 -0400 (EDT) Received: by qgfa8 with SMTP id a8so37478282qgf.0 for ; Mon, 16 Mar 2015 05:10:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0HOC0YpW7umXrMUmNgK7SyczIv34BhMBu1IfybdF7hc=; b=H0Mx+Ac8vXjuiEtve+IY/ia/7rgOYOo2gjD5Oc146gO2uUaslXxmSr+P1ec7+mrvQm e9jFWcxDJhu/QjMtK8xSD+Dz1fI4HouD097xN6HAzZrtLSbMhMbld2Y6aLhDpuubErnI QocPYfY89Vm1N+RDKAyMePpzNhyilyTWkZBkan3xuvoic4pzFwS6zFOh2czN2jq9VP9h lDssFPpC06XABQAeQkofQiyVEDvjkF6P5YlBJ0BglCsqVO+ADxdbBm+OB6oUtKlpR+ke eKNed2PGmXQ4aDFp/ju54p7SagO1pRM8UKdwda6SH23Qegpz1zq5SevUQ/sVvQbMAkEd stAg== X-Gm-Message-State: ALoCoQmMWE8lO4zK/ZRCA3Dv3XYsJkh5s+r3xe24ujV8+hakUPOgzpxjQ6NGg18RATEyogNamB2cuVvlHN+ktPjEsuKnl6Lrsm0o0K+N00GsBD7JPznGr/ZumQDh20YIWNLNi/pS+OUD X-Received: by 10.55.55.81 with SMTP id e78mr120060533qka.107.1426507834455; Mon, 16 Mar 2015 05:10:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.55.55.81 with SMTP id e78mr120060507qka.107.1426507834338; Mon, 16 Mar 2015 05:10:34 -0700 (PDT) Received: by 10.140.250.2 with HTTP; Mon, 16 Mar 2015 05:10:34 -0700 (PDT) In-Reply-To: References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> <5DA45143-E51A-483E-8191-5F9DBFD9BD3E@standardstrack.com> Date: Mon, 16 Mar 2015 08:10:34 -0400 Message-ID: From: Henning Schulzrinne To: Eric Burger Content-Type: multipart/alternative; boundary=001a11490ac8bc41d1051166bc28 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Archived-At: Cc: "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 12:10:38 -0000 --001a11490ac8bc41d1051166bc28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My general approach is not to make the problem more difficult than it has to be. Otherwise, positing problems that are hypothetical corner cases prevent the solution of the real problem. Almost all (legitimate) business calls that most people receive are either from their own country or a country they are familiar with (e.g., because they are first or second generation immigrants). Thus, how Nigeria classifies or regulates financial institutions is of little concern to me since I don't expect to receive a call from a Nigerian bank or "bank". Also, there is very little legitimate cold-calling from businesses; most cold-calling falls into the illegal side of the TCPA (the US law governing telemarketing). The goal is to be able to tell that if I get a call from the IRS or Bank of America, that they are indeed who they claim to be, without having to remember what phone numbers they use. Henning On Mon, Mar 16, 2015 at 7:12 AM, Eric Burger wrote: > In principle this makes sense. However, if we cannot get the world to > agree on countries (e.g., Tibet, Taiwan, etc.), how are we going to get a= n > agreed list of enterprise types? We could go the ITU route and define the > protocol machinery and leave the enterprise definitions a local matter. > However, that does not foster global interoperability. Moreover, your > state-sponsored source of foreign currency might look to me to be a > criminal enterprise. Would it be a registered bank or a registered > 'trading' company? > > -- > Sent from a mobile device. Sorry for typos or weird auto-correct. Thank > IETF LEMONADE for mobile email! See < > http://www.standardstrack.com/ietf/lemonade/> > > On Mar 15, 2015, at 9:52 PM, Henning Schulzrinne > wrote: > > This seems like a separable problem, i.e., where the mechanism of > preventing IDN impersonation is left to the certifying entity. Unlike for > web pages, these entities are likely to be domestic so that a callee is > likely to be suspicious if it receives a Russian-certified caller that ki= nd > of looks like Citibank. But you illustrate a good reason why certifying t= he > type of entity (e.g., FDIC-insured bank, registered medical provider) may > be more important than relying on a name alone. > > Henning > > On Sun, Mar 15, 2015 at 9:26 PM, Eric Burger > wrote: > >> This is IDN all over again. On the one hand, we need to be aware that >> some bad people will try to =CF=81=CE=B7=CE=B9=CF=82=CE=B7 instead of = =CF=86=CE=B9=CF=83, because the former looks >> like phish. On the other hand, last I looked, this is the IETF, and a >> US-centric or Roman-script-centric solution is not going to be >> internationally acceptable. >> >> Sincerely, >> =E6=9F=8F=E5=B0=94=E7=AB=8B >> >> P.S., while we are expanding the charter to encompass the ocean, can I >> specify =E2=80=9CEric Burger=E2=80=9D for domestic calls and "=E6=9F=8F= =E5=B0=94=E7=AB=8B=E2=80=9D for calls to China? ;-) >> >> --001a11490ac8bc41d1051166bc28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My general approach is not to make the problem more diffic= ult than it has to be. Otherwise, positing problems that are hypothetical c= orner cases prevent the solution of the real problem.

Al= most all (legitimate) business calls that most people receive are either fr= om their own country or a country they are familiar with (e.g., because the= y are first or second generation immigrants). Thus, how Nigeria classifies = or regulates financial institutions is of little concern to me since I don&= #39;t expect to receive a call from a Nigerian bank or "bank". Al= so, there is very little legitimate cold-calling from businesses; most cold= -calling falls into the illegal side of the TCPA (the US law governing tele= marketing). The goal is to be able to tell that if I get a call from the IR= S or Bank of America, that they are indeed who they claim to be, without ha= ving to remember what phone numbers they use.

Henning

On= Mon, Mar 16, 2015 at 7:12 AM, Eric Burger <eburger@standardstrac= k.com> wrote:
In principle this makes sense. However, if we cannot get the worl= d to agree on countries (e.g., Tibet, Taiwan, etc.), how are we going to ge= t an agreed list of enterprise types? We could go the ITU route and define = the protocol machinery and leave the enterprise definitions a local matter.= However, that does not foster global interoperability. Moreover, your stat= e-sponsored source of foreign currency might look to me to be a criminal en= terprise. Would it be a registered bank or a registered 'trading' c= ompany?

--
Sent from a mobile device. Sorry for typos or weird a= uto-correct. Thank IETF LEMONADE for mobile email! See <http://www.stand= ardstrack.com/ietf/lemonade/>

On Mar 15, 2015, a= t 9:52 PM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:

This seems like a separable problem, = i.e., where the mechanism of preventing IDN impersonation is left to the ce= rtifying entity. Unlike for web pages, these entities are likely to be dome= stic so that a callee is likely to be suspicious if it receives a Russian-c= ertified caller that kind of looks like Citibank. But you illustrate a good= reason why certifying the type of entity (e.g., FDIC-insured bank, registe= red medical provider) may be more important than relying on a name alone.
Henning

On Sun, Mar 15, 2015 at 9:26 PM, Eric Burger = <eburger= @standardstrack.com> wrote:
This is IDN all over again. On the one hand, we need to be aware that some= bad people will try to =CF=81=CE=B7=CE=B9=CF=82=CE=B7 instead of =CF=86=CE= =B9=CF=83, because the former looks like phish. On the other hand, last I l= ooked, this is the IETF, and a US-centric or Roman-script-centric solution = is not going to be internationally acceptable.

Sincerely,
=E6=9F=8F=E5=B0=94=E7=AB=8B

P.S., while we are expanding the charter to encompass the ocean, can I spec= ify =E2=80=9CEric Burger=E2=80=9D for domestic calls and "=E6=9F=8F=E5= =B0=94=E7=AB=8B=E2=80=9D for calls to China? ;-)


--001a11490ac8bc41d1051166bc28-- From nobody Mon Mar 16 05:38:38 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310C41A8716; Mon, 16 Mar 2015 05:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 989xqSrcMa2c; Mon, 16 Mar 2015 05:38:34 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206091A8714; Mon, 16 Mar 2015 05:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Content-Type:MIME-Version:Cc:To:From:Message-ID:Subject:Date; bh=CUY1JrsPHPjqmTSwDBGwMHBuOYXwOOxnyIa1VdHpFNA=; b=sjOec8lbUEQLIXCNwKPSBH91JmdX3XFCuZn4/JKjMm2POcJXacIj0o+kB60AAUSMCrl/Vpkt+Pt4zdhtOx4zmV8gGK1F7EqSugpfInf0kHFMm787dwh5Ys3dGNw3WB7UGjdur+5zO8jSL1Nl6rasNIp7H2+LW5k4bVOTdqHglUo=; Received: from 69.sub-70-192-204.myvzw.com ([70.192.204.69]:5206 helo=[100.76.224.81]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.82) (envelope-from ) id 1YXUHm-0008KX-Ut; Mon, 16 Mar 2015 05:38:29 -0700 Date: Mon, 16 Mar 2015 08:38:19 -0400 Message-ID: Importance: normal From: Eric Burger To: Henning Schulzrinne MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_104603094177580" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Cc: "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 12:38:36 -0000 ----_com.android.email_104603094177580 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RG8gd2UgbmVlZCBtb3JlIHRoYW4gRVYgY2VydGlmaWNhdGVzPyBLbm93aW5nIHRoYXQgYSBjYWxs IGZyb20gZm9vQGJhbmtvZmFtZXJpY2EuY29tIGlzIGZyb20gQmFuayBvZiBBbWVyaWNhIG1pZ2h0 IGJlIHN1ZmZpY2llbnQsIGFuZCB0aGUgYmVzdCB3ZSBjYW4gcmVhbGx5IGhvcGUgZm9yLsKgCgoK U2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2UuIFRoYW5rcyBiZSB0byBMRU1PTkFERTogaHR0cDov L3d3dy5zdGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFkZQoKPGRpdj4tLS0tLS0tLSBPcmln aW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBIZW5uaW5nIFNjaHVsenJpbm5l IDxoZ3NAY3MuY29sdW1iaWEuZWR1PiA8L2Rpdj48ZGl2PkRhdGU6MDMvMTYvMjAxNSAgODoxMCBB TSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5UbzogRXJpYyBCdXJnZXIgPGVidXJnZXJAc3RhbmRh cmRzdHJhY2suY29tPiA8L2Rpdj48ZGl2PkNjOiBjbml0QGlldGYub3JnLGRpc3BhdGNoQGlldGYu b3JnLG1vZGVybkBpZXRmLm9yZyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFtN b2Rlcm5dIENOSVQgYW5kIE1vZGVybiBDaGFydGVyIDwvZGl2PjxkaXY+CjwvZGl2Pk15IGdlbmVy YWwgYXBwcm9hY2ggaXMgbm90IHRvIG1ha2UgdGhlIHByb2JsZW0gbW9yZSBkaWZmaWN1bHQgdGhh biBpdCBoYXMgdG8gYmUuIE90aGVyd2lzZSwgcG9zaXRpbmcgcHJvYmxlbXMgdGhhdCBhcmUgaHlw b3RoZXRpY2FsIGNvcm5lciBjYXNlcyBwcmV2ZW50IHRoZSBzb2x1dGlvbiBvZiB0aGUgcmVhbCBw cm9ibGVtLgoKQWxtb3N0IGFsbCAobGVnaXRpbWF0ZSkgYnVzaW5lc3MgY2FsbHMgdGhhdCBtb3N0 IHBlb3BsZSByZWNlaXZlIGFyZSBlaXRoZXIgZnJvbSB0aGVpciBvd24gY291bnRyeSBvciBhIGNv dW50cnkgdGhleSBhcmUgZmFtaWxpYXIgd2l0aCAoZS5nLiwgYmVjYXVzZSB0aGV5IGFyZSBmaXJz dCBvciBzZWNvbmQgZ2VuZXJhdGlvbiBpbW1pZ3JhbnRzKS4gVGh1cywgaG93IE5pZ2VyaWEgY2xh c3NpZmllcyBvciByZWd1bGF0ZXMgZmluYW5jaWFsIGluc3RpdHV0aW9ucyBpcyBvZiBsaXR0bGUg Y29uY2VybiB0byBtZSBzaW5jZSBJIGRvbid0IGV4cGVjdCB0byByZWNlaXZlIGEgY2FsbCBmcm9t IGEgTmlnZXJpYW4gYmFuayBvciAiYmFuayIuIEFsc28sIHRoZXJlIGlzIHZlcnkgbGl0dGxlIGxl Z2l0aW1hdGUgY29sZC1jYWxsaW5nIGZyb20gYnVzaW5lc3NlczsgbW9zdCBjb2xkLWNhbGxpbmcg ZmFsbHMgaW50byB0aGUgaWxsZWdhbCBzaWRlIG9mIHRoZSBUQ1BBICh0aGUgVVMgbGF3IGdvdmVy bmluZyB0ZWxlbWFya2V0aW5nKS4gVGhlIGdvYWwgaXMgdG8gYmUgYWJsZSB0byB0ZWxsIHRoYXQg aWYgSSBnZXQgYSBjYWxsIGZyb20gdGhlIElSUyBvciBCYW5rIG9mIEFtZXJpY2EsIHRoYXQgdGhl eSBhcmUgaW5kZWVkIHdobyB0aGV5IGNsYWltIHRvIGJlLCB3aXRob3V0IGhhdmluZyB0byByZW1l bWJlciB3aGF0IHBob25lIG51bWJlcnMgdGhleSB1c2UuCgpIZW5uaW5nCgpPbiBNb24sIE1hciAx NiwgMjAxNSBhdCA3OjEyIEFNLCBFcmljIEJ1cmdlciA8ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5j b20+IHdyb3RlOgpJbiBwcmluY2lwbGUgdGhpcyBtYWtlcyBzZW5zZS4gSG93ZXZlciwgaWYgd2Ug Y2Fubm90IGdldCB0aGUgd29ybGQgdG8gYWdyZWUgb24gY291bnRyaWVzIChlLmcuLCBUaWJldCwg VGFpd2FuLCBldGMuKSwgaG93IGFyZSB3ZSBnb2luZyB0byBnZXQgYW4gYWdyZWVkIGxpc3Qgb2Yg ZW50ZXJwcmlzZSB0eXBlcz8gV2UgY291bGQgZ28gdGhlIElUVSByb3V0ZSBhbmQgZGVmaW5lIHRo ZSBwcm90b2NvbCBtYWNoaW5lcnkgYW5kIGxlYXZlIHRoZSBlbnRlcnByaXNlIGRlZmluaXRpb25z IGEgbG9jYWwgbWF0dGVyLiBIb3dldmVyLCB0aGF0IGRvZXMgbm90IGZvc3RlciBnbG9iYWwgaW50 ZXJvcGVyYWJpbGl0eS4gTW9yZW92ZXIsIHlvdXIgc3RhdGUtc3BvbnNvcmVkIHNvdXJjZSBvZiBm b3JlaWduIGN1cnJlbmN5IG1pZ2h0IGxvb2sgdG8gbWUgdG8gYmUgYSBjcmltaW5hbCBlbnRlcnBy aXNlLiBXb3VsZCBpdCBiZSBhIHJlZ2lzdGVyZWQgYmFuayBvciBhIHJlZ2lzdGVyZWQgJ3RyYWRp bmcnIGNvbXBhbnk/CgotLQpTZW50IGZyb20gYSBtb2JpbGUgZGV2aWNlLiBTb3JyeSBmb3IgdHlw b3Mgb3Igd2VpcmQgYXV0by1jb3JyZWN0LiBUaGFuayBJRVRGIExFTU9OQURFIGZvciBtb2JpbGUg ZW1haWwhIFNlZSA8aHR0cDovL3d3dy5zdGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFkZS8+ CgpPbiBNYXIgMTUsIDIwMTUsIGF0IDk6NTIgUE0sIEhlbm5pbmcgU2NodWx6cmlubmUgPGhnc0Bj cy5jb2x1bWJpYS5lZHU+IHdyb3RlOgoKVGhpcyBzZWVtcyBsaWtlIGEgc2VwYXJhYmxlIHByb2Js ZW0sIGkuZS4sIHdoZXJlIHRoZSBtZWNoYW5pc20gb2YgcHJldmVudGluZyBJRE4gaW1wZXJzb25h dGlvbiBpcyBsZWZ0IHRvIHRoZSBjZXJ0aWZ5aW5nIGVudGl0eS4gVW5saWtlIGZvciB3ZWIgcGFn ZXMsIHRoZXNlIGVudGl0aWVzIGFyZSBsaWtlbHkgdG8gYmUgZG9tZXN0aWMgc28gdGhhdCBhIGNh bGxlZSBpcyBsaWtlbHkgdG8gYmUgc3VzcGljaW91cyBpZiBpdCByZWNlaXZlcyBhIFJ1c3NpYW4t Y2VydGlmaWVkIGNhbGxlciB0aGF0IGtpbmQgb2YgbG9va3MgbGlrZSBDaXRpYmFuay4gQnV0IHlv dSBpbGx1c3RyYXRlIGEgZ29vZCByZWFzb24gd2h5IGNlcnRpZnlpbmcgdGhlIHR5cGUgb2YgZW50 aXR5IChlLmcuLCBGRElDLWluc3VyZWQgYmFuaywgcmVnaXN0ZXJlZCBtZWRpY2FsIHByb3ZpZGVy KSBtYXkgYmUgbW9yZSBpbXBvcnRhbnQgdGhhbiByZWx5aW5nIG9uIGEgbmFtZSBhbG9uZS4KCkhl bm5pbmcKCk9uIFN1biwgTWFyIDE1LCAyMDE1IGF0IDk6MjYgUE0sIEVyaWMgQnVyZ2VyIDxlYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbT4gd3JvdGU6ClRoaXMgaXMgSUROIGFsbCBvdmVyIGFnYWlu LiBPbiB0aGUgb25lIGhhbmQsIHdlIG5lZWQgdG8gYmUgYXdhcmUgdGhhdCBzb21lIGJhZCBwZW9w bGUgd2lsbCB0cnkgdG8gz4HOt865z4LOtyBpbnN0ZWFkIG9mIM+GzrnPgywgYmVjYXVzZSB0aGUg Zm9ybWVyIGxvb2tzIGxpa2UgcGhpc2guIE9uIHRoZSBvdGhlciBoYW5kLCBsYXN0IEkgbG9va2Vk LCB0aGlzIGlzIHRoZSBJRVRGLCBhbmQgYSBVUy1jZW50cmljIG9yIFJvbWFuLXNjcmlwdC1jZW50 cmljIHNvbHV0aW9uIGlzIG5vdCBnb2luZyB0byBiZSBpbnRlcm5hdGlvbmFsbHkgYWNjZXB0YWJs ZS4KClNpbmNlcmVseSwK5p+P5bCU56uLCgpQLlMuLCB3aGlsZSB3ZSBhcmUgZXhwYW5kaW5nIHRo ZSBjaGFydGVyIHRvIGVuY29tcGFzcyB0aGUgb2NlYW4sIGNhbiBJIHNwZWNpZnkg4oCcRXJpYyBC dXJnZXLigJ0gZm9yIGRvbWVzdGljIGNhbGxzIGFuZCAi5p+P5bCU56uL4oCdIGZvciBjYWxscyB0 byBDaGluYT8gOy0pCgoK ----_com.android.email_104603094177580 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5EbyB3ZSBuZWVkIG1vcmUg dGhhbiBFViBjZXJ0aWZpY2F0ZXM/IEtub3dpbmcgdGhhdCBhIGNhbGwgZnJvbSBmb29AYmFua29m YW1lcmljYS5jb20gaXMgZnJvbSBCYW5rIG9mIEFtZXJpY2EgbWlnaHQgYmUgc3VmZmljaWVudCwg YW5kIHRoZSBiZXN0IHdlIGNhbiByZWFsbHkgaG9wZSBmb3IuJm5ic3A7PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48YnI+PC9kaXY+U2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2UuIFRoYW5rcyBi ZSB0byBMRU1PTkFERTogaHR0cDovL3d3dy5zdGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFk ZTxicj48YnI+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRp dj5Gcm9tOiBIZW5uaW5nIFNjaHVsenJpbm5lIDxoZ3NAY3MuY29sdW1iaWEuZWR1PiA8L2Rpdj48 ZGl2PkRhdGU6MDMvMTYvMjAxNSAgODoxMCBBTSAgKEdNVC0wNTowMCkgPC9kaXY+PGRpdj5Ubzog RXJpYyBCdXJnZXIgPGVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tPiA8L2Rpdj48ZGl2PkNjOiBj bml0QGlldGYub3JnLGRpc3BhdGNoQGlldGYub3JnLG1vZGVybkBpZXRmLm9yZyA8L2Rpdj48ZGl2 PlN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFtNb2Rlcm5dIENOSVQgYW5kIE1vZGVybiBDaGFydGVy IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgZGlyPSJsdHIiPk15IGdlbmVyYWwgYXBwcm9hY2gg aXMgbm90IHRvIG1ha2UgdGhlIHByb2JsZW0gbW9yZSBkaWZmaWN1bHQgdGhhbiBpdCBoYXMgdG8g YmUuIE90aGVyd2lzZSwgcG9zaXRpbmcgcHJvYmxlbXMgdGhhdCBhcmUgaHlwb3RoZXRpY2FsIGNv cm5lciBjYXNlcyBwcmV2ZW50IHRoZSBzb2x1dGlvbiBvZiB0aGUgcmVhbCBwcm9ibGVtLjxkaXY+ PGJyPjwvZGl2PjxkaXY+QWxtb3N0IGFsbCAobGVnaXRpbWF0ZSkgYnVzaW5lc3MgY2FsbHMgdGhh dCBtb3N0IHBlb3BsZSByZWNlaXZlIGFyZSBlaXRoZXIgZnJvbSB0aGVpciBvd24gY291bnRyeSBv ciBhIGNvdW50cnkgdGhleSBhcmUgZmFtaWxpYXIgd2l0aCAoZS5nLiwgYmVjYXVzZSB0aGV5IGFy ZSBmaXJzdCBvciBzZWNvbmQgZ2VuZXJhdGlvbiBpbW1pZ3JhbnRzKS4gVGh1cywgaG93IE5pZ2Vy aWEgY2xhc3NpZmllcyBvciByZWd1bGF0ZXMgZmluYW5jaWFsIGluc3RpdHV0aW9ucyBpcyBvZiBs aXR0bGUgY29uY2VybiB0byBtZSBzaW5jZSBJIGRvbid0IGV4cGVjdCB0byByZWNlaXZlIGEgY2Fs bCBmcm9tIGEgTmlnZXJpYW4gYmFuayBvciAiYmFuayIuIEFsc28sIHRoZXJlIGlzIHZlcnkgbGl0 dGxlIGxlZ2l0aW1hdGUgY29sZC1jYWxsaW5nIGZyb20gYnVzaW5lc3NlczsgbW9zdCBjb2xkLWNh bGxpbmcgZmFsbHMgaW50byB0aGUgaWxsZWdhbCBzaWRlIG9mIHRoZSBUQ1BBICh0aGUgVVMgbGF3 IGdvdmVybmluZyB0ZWxlbWFya2V0aW5nKS4gVGhlIGdvYWwgaXMgdG8gYmUgYWJsZSB0byB0ZWxs IHRoYXQgaWYgSSBnZXQgYSBjYWxsIGZyb20gdGhlIElSUyBvciBCYW5rIG9mIEFtZXJpY2EsIHRo YXQgdGhleSBhcmUgaW5kZWVkIHdobyB0aGV5IGNsYWltIHRvIGJlLCB3aXRob3V0IGhhdmluZyB0 byByZW1lbWJlciB3aGF0IHBob25lIG51bWJlcnMgdGhleSB1c2UuPGRpdj48YnI+PC9kaXY+PGRp dj5IZW5uaW5nPC9kaXY+PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBNYXIgMTYsIDIwMTUgYXQgNzoxMiBBTSwg RXJpYyBCdXJnZXIgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86ZWJ1cmdlckBz dGFuZGFyZHN0cmFjay5jb20iIHRhcmdldD0iX2JsYW5rIj5lYnVyZ2VyQHN0YW5kYXJkc3RyYWNr LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBkaXI9ImF1dG8iPjxkaXY+SW4gcHJpbmNpcGxlIHRoaXMg bWFrZXMgc2Vuc2UuIEhvd2V2ZXIsIGlmIHdlIGNhbm5vdCBnZXQgdGhlIHdvcmxkIHRvIGFncmVl IG9uIGNvdW50cmllcyAoZS5nLiwgVGliZXQsIFRhaXdhbiwgZXRjLiksIGhvdyBhcmUgd2UgZ29p bmcgdG8gZ2V0IGFuIGFncmVlZCBsaXN0IG9mIGVudGVycHJpc2UgdHlwZXM/IFdlIGNvdWxkIGdv IHRoZSBJVFUgcm91dGUgYW5kIGRlZmluZSB0aGUgcHJvdG9jb2wgbWFjaGluZXJ5IGFuZCBsZWF2 ZSB0aGUgZW50ZXJwcmlzZSBkZWZpbml0aW9ucyBhIGxvY2FsIG1hdHRlci4gSG93ZXZlciwgdGhh dCBkb2VzIG5vdCBmb3N0ZXIgZ2xvYmFsIGludGVyb3BlcmFiaWxpdHkuIE1vcmVvdmVyLCB5b3Vy IHN0YXRlLXNwb25zb3JlZCBzb3VyY2Ugb2YgZm9yZWlnbiBjdXJyZW5jeSBtaWdodCBsb29rIHRv IG1lIHRvIGJlIGEgY3JpbWluYWwgZW50ZXJwcmlzZS4gV291bGQgaXQgYmUgYSByZWdpc3RlcmVk IGJhbmsgb3IgYSByZWdpc3RlcmVkICd0cmFkaW5nJyBjb21wYW55Pzxicj48YnI+LS08ZGl2PlNl bnQgZnJvbSBhIG1vYmlsZSBkZXZpY2UuIFNvcnJ5IGZvciB0eXBvcyBvciB3ZWlyZCBhdXRvLWNv cnJlY3QuIFRoYW5rIElFVEYgTEVNT05BREUgZm9yIG1vYmlsZSBlbWFpbCEgU2VlICZsdDs8YSBo cmVmPSJodHRwOi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHA6Ly93d3cuc3RhbmRhcmRzdHJhY2suY29tL2lldGYvbGVtb25hZGUvPC9h PiZndDs8L2Rpdj48L2Rpdj48ZGl2Pjxicj5PbiBNYXIgMTUsIDIwMTUsIGF0IDk6NTIgUE0sIEhl bm5pbmcgU2NodWx6cmlubmUgJmx0OzxhIGhyZWY9Im1haWx0bzpoZ3NAY3MuY29sdW1iaWEuZWR1 IiB0YXJnZXQ9Il9ibGFuayI+aGdzQGNzLmNvbHVtYmlhLmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj48 YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48ZGl2IGRpcj0ibHRyIj5UaGlz IHNlZW1zIGxpa2UgYSBzZXBhcmFibGUgcHJvYmxlbSwgaS5lLiwgd2hlcmUgdGhlIG1lY2hhbmlz bSBvZiBwcmV2ZW50aW5nIElETiBpbXBlcnNvbmF0aW9uIGlzIGxlZnQgdG8gdGhlIGNlcnRpZnlp bmcgZW50aXR5LiBVbmxpa2UgZm9yIHdlYiBwYWdlcywgdGhlc2UgZW50aXRpZXMgYXJlIGxpa2Vs eSB0byBiZSBkb21lc3RpYyBzbyB0aGF0IGEgY2FsbGVlIGlzIGxpa2VseSB0byBiZSBzdXNwaWNp b3VzIGlmIGl0IHJlY2VpdmVzIGEgUnVzc2lhbi1jZXJ0aWZpZWQgY2FsbGVyIHRoYXQga2luZCBv ZiBsb29rcyBsaWtlIENpdGliYW5rLiBCdXQgeW91IGlsbHVzdHJhdGUgYSBnb29kIHJlYXNvbiB3 aHkgY2VydGlmeWluZyB0aGUgdHlwZSBvZiBlbnRpdHkgKGUuZy4sIEZESUMtaW5zdXJlZCBiYW5r LCByZWdpc3RlcmVkIG1lZGljYWwgcHJvdmlkZXIpIG1heSBiZSBtb3JlIGltcG9ydGFudCB0aGFu IHJlbHlpbmcgb24gYSBuYW1lIGFsb25lLjxkaXY+PGJyPjwvZGl2PjxkaXY+SGVubmluZzxicj48 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBT dW4sIE1hciAxNSwgMjAxNSBhdCA5OjI2IFBNLCBFcmljIEJ1cmdlciA8c3BhbiBkaXI9Imx0ciI+ Jmx0OzxhIGhyZWY9Im1haWx0bzplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxi cj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhl eDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5UaGlzIGlzIElE TiBhbGwgb3ZlciBhZ2Fpbi4gT24gdGhlIG9uZSBoYW5kLCB3ZSBuZWVkIHRvIGJlIGF3YXJlIHRo YXQgc29tZSBiYWQgcGVvcGxlIHdpbGwgdHJ5IHRvIM+BzrfOuc+CzrcgaW5zdGVhZCBvZiDPhs65 z4MsIGJlY2F1c2UgdGhlIGZvcm1lciBsb29rcyBsaWtlIHBoaXNoLiBPbiB0aGUgb3RoZXIgaGFu ZCwgbGFzdCBJIGxvb2tlZCwgdGhpcyBpcyB0aGUgSUVURiwgYW5kIGEgVVMtY2VudHJpYyBvciBS b21hbi1zY3JpcHQtY2VudHJpYyBzb2x1dGlvbiBpcyBub3QgZ29pbmcgdG8gYmUgaW50ZXJuYXRp b25hbGx5IGFjY2VwdGFibGUuPGJyPgo8YnI+ClNpbmNlcmVseSw8YnI+Cuafj+WwlOerizxicj4K PGJyPgpQLlMuLCB3aGlsZSB3ZSBhcmUgZXhwYW5kaW5nIHRoZSBjaGFydGVyIHRvIGVuY29tcGFz cyB0aGUgb2NlYW4sIGNhbiBJIHNwZWNpZnkg4oCcRXJpYyBCdXJnZXLigJ0gZm9yIGRvbWVzdGlj IGNhbGxzIGFuZCAi5p+P5bCU56uL4oCdIGZvciBjYWxscyB0byBDaGluYT8gOy0pPGJyPgo8YnI+ PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pgo8L2Rpdj48L2Jsb2NrcXVvdGU+ PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj4KPC9ib2R5Pg== ----_com.android.email_104603094177580-- From nobody Mon Mar 16 05:44:25 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAD31A871B for ; Mon, 16 Mar 2015 05:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP3Uu18abqAv for ; Mon, 16 Mar 2015 05:44:19 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id C25F41A8718 for ; Mon, 16 Mar 2015 05:44:19 -0700 (PDT) Received: (qmail 14441 invoked by uid 0); 16 Mar 2015 12:44:17 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy10.mail.unifiedlayer.com with SMTP; 16 Mar 2015 12:44:17 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id 4Ck91q00W1MNPNq01CkCcV; Mon, 16 Mar 2015 06:44:15 -0600 X-Authority-Analysis: v=2.1 cv=d8xml3TE c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=Jklo8jbM_8AA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=emO1SXQWCLwA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=bfLuiRfvAAAA:8 a=48vgC7mUAAAA:8 a=2v-M-Dt2RGnFbw3qsFEA:9 a=fZ5K4kkc3Pz60D1d:21 a=bala89Op0qkPP6u-:21 a=QEXdDO2ut3YA:10 a=85dsBfuqSrNicqq9a_UA:9 a=ekvCneL12DxKXmND:21 a=xtFAOjYpFN2jBSqL:21 a=09fW17ZFg-VNEqfH:21 a=_W_S_7VecoQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=z5Neg38Rap54LE2p3DjBSheduiZMKDi4vE4WqsD16ME=; b=ZLIDdyL9F4jDnkf5fHmhT3CgxW4GkQO1HbA2BSTBOI1ELfw1/PP8Lspt8cSxGku0tXd4rAyrQbRwKxaypPdOabbJfv+r7FOx6DrtbYAaMeiG6/ZmowBjiXEd9uIdojcT; Received: from [108.56.131.201] (port=50073 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YXUNO-0008Ge-U8; Mon, 16 Mar 2015 06:44:11 -0600 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Mon, 16 Mar 2015 08:44:05 -0400 From: Richard Shockey To: Henning Schulzrinne , Eric Burger Message-ID: Thread-Topic: [dispatch] [Modern] CNIT and Modern Charter References: <92CB9546-6458-4286-B880-C485488C63B7@cisco.com> <5DA45143-E51A-483E-8191-5F9DBFD9BD3E@standardstrack.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3509340250_673764" X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: Cc: "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 12:44:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3509340250_673764 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Its the boil the ocean problem I=E2=80=99d like to avoid. As a first pass I would strongly argue that the only relevant items to address initially are what header to use for CNAM/CNIT and what is the data object(s). Constrict the initial charter to those things then build on success through recharter. MARTINI comes to mind. In this case some of us would propose a simple reuse of an existing header and and a simple reuse existing data object. Path to RFC might be within this decade.=20 From: Henning Schulzrinne Date: Monday, March 16, 2015 at 8:10 AM To: Eric Burger Cc: "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [dispatch] [Modern] CNIT and Modern Charter My general approach is not to make the problem more difficult than it has t= o be. Otherwise, positing problems that are hypothetical corner cases prevent the solution of the real problem. Almost all (legitimate) business calls that most people receive are either from their own country or a country they are familiar with (e.g., because they are first or second generation immigrants). Thus, how Nigeria classifies or regulates financial institutions is of little concern to me since I don't expect to receive a call from a Nigerian bank or "bank". Also= , there is very little legitimate cold-calling from businesses; most cold-calling falls into the illegal side of the TCPA (the US law governing telemarketing). The goal is to be able to tell that if I get a call from th= e IRS or Bank of America, that they are indeed who they claim to be, without having to remember what phone numbers they use. Henning On Mon, Mar 16, 2015 at 7:12 AM, Eric Burger wrote: > In principle this makes sense. However, if we cannot get the world to agr= ee on > countries (e.g., Tibet, Taiwan, etc.), how are we going to get an agreed = list > of enterprise types? We could go the ITU route and define the protocol > machinery and leave the enterprise definitions a local matter. However, t= hat > does not foster global interoperability. Moreover, your state-sponsored s= ource > of foreign currency might look to me to be a criminal enterprise. Would i= t be > a registered bank or a registered 'trading' company? >=20 > -- > Sent from a mobile device. Sorry for typos or weird auto-correct. Thank I= ETF > LEMONADE for mobile email! See >=20 > On Mar 15, 2015, at 9:52 PM, Henning Schulzrinne wr= ote: >=20 >> This seems like a separable problem, i.e., where the mechanism of preven= ting >> IDN impersonation is left to the certifying entity. Unlike for web pages= , >> these entities are likely to be domestic so that a callee is likely to b= e >> suspicious if it receives a Russian-certified caller that kind of looks = like >> Citibank. But you illustrate a good reason why certifying the type of en= tity >> (e.g., FDIC-insured bank, registered medical provider) may be more impor= tant >> than relying on a name alone. >>=20 >> Henning >>=20 >> On Sun, Mar 15, 2015 at 9:26 PM, Eric Burger >> wrote: >>> This is IDN all over again. On the one hand, we need to be aware that s= ome >>> bad people will try to =CF=81=CE=B7=CE=B9=CF=82=CE=B7 instead of =CF=86=CE=B9=CF=83, because the former= looks like >>> phish. On the other hand, last I looked, this is the IETF, and a US-cen= tric >>> or Roman-script-centric solution is not going to be internationally >>> acceptable. >>>=20 >>> Sincerely, >>> =E6=9F=8F=E5=B0=94=E7=AB=8B >>>=20 >>> P.S., while we are expanding the charter to encompass the ocean, can I >>> specify =E2=80=9CEric Burger=E2=80=9D for domestic calls and "=E6=9F=8F=E5=B0=94=E7=AB=8B=E2=80=9D for call= s to China? ;-) >>>=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --B_3509340250_673764 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Its the boil the ocean problem I’d like to avoid.
As a first pass I would strongly argue that the only relevant i= tems to address initially are what header to use for CNAM/CNIT and what is t= he data object(s). Constrict the initial charter to those things then build = on success through recharter. 

MARTINI comes t= o mind.  

In this case some of us would propos= e a simple reuse of an existing header and and a simple reuse existing data = object. Path to RFC might be within this decade. 

<= span id=3D"OLK_SRC_BODY_SECTION">
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Monday, March 16, 2015 at 8:10 AM
To: Eric Burger <eburger@standardstrack.com>
Cc: "cnit@ietf.org" <cnit@ietf.org>, "dispatch@ietf.org" <di= spatch@ietf.org>, "modern@ietf.org" <modern@ietf.org>
Subject: Re: [dispatch] [Modern] CNIT and Mod= ern Charter

My general approach is no= t to make the problem more difficult than it has to be. Otherwise, positing = problems that are hypothetical corner cases prevent the solution of the real= problem.

Almost all (legitimate) business calls that mos= t people receive are either from their own country or a country they are fam= iliar with (e.g., because they are first or second generation immigrants). T= hus, how Nigeria classifies or regulates financial institutions is of little= concern to me since I don't expect to receive a call from a Nigerian bank o= r "bank". Also, there is very little legitimate cold-calling from businesses= ; most cold-calling falls into the illegal side of the TCPA (the US law gove= rning telemarketing). The goal is to be able to tell that if I get a call fr= om the IRS or Bank of America, that they are indeed who they claim to be, wi= thout having to remember what phone numbers they use.

Hen= ning

= On Mon, Mar 16, 2015 at 7:12 AM, Eric Burger <eburger@standardstrack.com<= /a>> wrote:

On Mar 15, 2015, at 9:52 PM, Henning Schulzrinne <hgs@cs.columbia.edu&g= t; wrote:

This seem= s like a separable problem, i.e., where the mechanism of preventing IDN impe= rsonation is left to the certifying entity. Unlike for web pages, these enti= ties are likely to be domestic so that a callee is likely to be suspicious i= f it receives a Russian-certified caller that kind of looks like Citibank. B= ut you illustrate a good reason why certifying the type of entity (e.g., FDI= C-insured bank, registered medical provider) may be more important than rely= ing on a name alone.

Henning
=
On Sun, Mar 15, 2015 at 9:26 PM, Eric Burger <eburger@standardstrack.com> wrote:
This is IDN all over again. On the one hand, we need to be aware that so= me bad people will try to =CF=81=CE=B7=CE=B9=CF=82=CE=B7 instead of =CF=86=CE=B9=CF=83, because the former l= ooks like phish. On the other hand, last I looked, this is the IETF, and a U= S-centric or Roman-script-centric solution is not going to be internationall= y acceptable.

Sincerely,
=E6=9F=8F=E5=B0=94=E7=AB=8B

P.S., while we are expanding the charter to encompass the ocean, can I spec= ify “Eric Burger” for domestic calls and "=E6=9F=8F=E5=B0=94=E7=AB=8B” for c= alls to China? ;-)


_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.o= rg/mailman/listinfo/dispatch --B_3509340250_673764-- From nobody Mon Mar 16 09:21:11 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360FA1A888E for ; Mon, 16 Mar 2015 09:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PNK4nDX6HvX for ; Mon, 16 Mar 2015 09:21:08 -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 DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7708F1A888D for ; Mon, 16 Mar 2015 09:21:08 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-10v.sys.comcast.net with comcast id 4GLc1q0022PT3Qt01GM7Wt; Mon, 16 Mar 2015 16:21:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-14v.sys.comcast.net with comcast id 4GM61q00Y3Ge9ey01GM7K3; Mon, 16 Mar 2015 16:21:07 +0000 Message-ID: <550702F2.3090805@alum.mit.edu> Date: Mon, 16 Mar 2015 12:21:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Cullen Jennings References: <20150113154647.9128.69519.idtracker@ietfa.amsl.com> <54B54462.8060308@alum.mit.edu> <6F2A17BA-AE0D-4370-A613-9E28B052AF16@cisco.com> In-Reply-To: <6F2A17BA-AE0D-4370-A613-9E28B052AF16@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1426522867; bh=ZjJskqqiy8lG64XavuHPE/485Z+kcdhp02NveF6M+lU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sFY1Ib9sC56rFNz4GX3A3HS2ZRoJw84uguwMP8ygbIm4CqRUJ5OWWggoUjgG2uz2u YrLWKWmywhIzoSTzcHwKw84gkIJfe3oedvGeTR/Rh7014TjBsYKomgFEEAZ5hvvFe6 hRsQHFZ0vijiAeHnHxPlhWVh1UHTebCyhcGj9P0/0zQNPbhxbHGl7Pm6xEeYqGzqYZ oYwpQ4hnNB08ugTzxBmrEEa2t3V1K0pdH4clOesMpwtE14GVwCJsvcg5SWAqLCJho0 qIC1oY3XpnmwtMafU075rDyjTp75WEyig98v/eUELe2cCgefOkHW6KJd+YtRsM9zJ0 2s1412R94WPXQ== Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 16:21:10 -0000 Cullen, On 3/9/15 10:58 AM, Cullen Jennings wrote: > > The heart of this draft gives me, ah , heartburn. The issue is > > For a provider to receive reimbursement for providing relay service > on a call the FCC requires that the provider supply call detail > including the IP address of the device the TRS user is using for the > call. > > First of all what IP. The IP of their phone behind their linksys nat? the public IP of the TURN server? the VPN? None of these are a viable way to authenticate that the user should receive this services and the IETF should implicitly endorse that they are. Furthermore the IETF should be just as concerned about privacy for people using a VRS as people that do not need one and this sort of reveal my IP address even if I want location privacy is not great. The address the FCC is interested in is the public IP of the user's device as seen by the VRS provider that the device connects to. The specifics depend on how the device connects to that provider. This gets complicated because the provider the device connects to may not be the provider that actually provides the reimbursable service. > Given the lack of any security around this and the TRS-5 requirement, I wonder if one can just look at the via list and use that? The actual IP of the device may not be in the via list. It could be an H.323 endpoint that is being gatewayed by the default provider. (This will be common initially.) > If we do proceed with this, I don't think the call-info is the appropriate place to put it. I think a new header would be the right thing. We considered this, and thought that Call-Info was a more appropriate choice. But either is acceptable to us. > Can you provide a pointer to the actually FCC rules for this? Already done in a prior reply. > If the goal is purely to check the user is in the US, then having the VRS check that they were sending media to an IP address inside the US seems like it would be a better solution. Perhaps, if the FCC agreed. Maybe it could be done as an interpretation. But it may also not be visible due to media relaying by the default provider. Thanks, Paul > Thanks > > > >> On Jan 13, 2015, at 9:14 AM, Paul Kyzivat wrote: >> >> Dispatchers: >> >> I have just submitted a new draft (see below) that needs to be dispatched. It defines a new Call-Info 'purpose' parameter value. >> >> The intended audience for this draft is quite limited - to the providers of the Video Relay Service in the US, and to the FCC that sponsors that service. The Intro section explains this. >> >> I'm hoping this can be dispatched without causing a lot of bother for anybody. I don't anticipate that it needs time in Dallas. IIUC documents of this sort are often AD sponsored. >> >> Thanks, >> Paul >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt >> Date: Tue, 13 Jan 2015 07:46:47 -0800 >> From: internet-drafts@ietf.org >> To: Paul Kyzivat , "Paul Kyzivat" >> >> >> A new version of I-D, draft-kyzivat-dispatch-trs-call-info-purpose-00.txt >> has been successfully submitted by Paul Kyzivat and posted to the >> IETF repository. >> >> Name: draft-kyzivat-dispatch-trs-call-info-purpose >> Revision: 00 >> Title: Telecommunications Relay Service Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) >> Document date: 2015-01-13 >> Group: Individual Submission >> Pages: 4 >> URL: http://www.ietf.org/internet-drafts/draft-kyzivat-dispatch-trs-call-info-purpose-00.txt >> Status: https://datatracker.ietf.org/doc/draft-kyzivat-dispatch-trs-call-info-purpose/ >> Htmlized: http://tools.ietf.org/html/draft-kyzivat-dispatch-trs-call-info-purpose-00 >> >> >> Abstract: >> This document defines and registers a value of "original-identity" >> for the "purpose" header field parameter of the Call-Info header >> field in the Session Initiation Protocol (SIP). >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > From nobody Mon Mar 16 11:03:22 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170EA1A896C for ; Mon, 16 Mar 2015 11:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecOgfhQalM0q for ; Mon, 16 Mar 2015 11:03:19 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (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 767811A8942 for ; Mon, 16 Mar 2015 11:03:19 -0700 (PDT) Received: by pdbop1 with SMTP id op1so64657571pdb.2 for ; Mon, 16 Mar 2015 11:03:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=YrmxBr1MAHzu0v8KPK8sIV3R/mT39xpDZiMTfXwxtPY=; b=PPMFu9I33mvpJxLOjJXsAKBTgSu2U9HcJTVsryw09fdS2ms2XhXHhX5iLOPd1GkHg/ lFxqNpMx2SEztGNa47eNKAk30JbbXzY+L9PlLQFU1Ra/sDh5Z2uBbO43Y7iwJQ/qcecX u5hfuS1HOzDHcVO6revHvAgwwDDB09Xaj144yHSsvmnqg2FTNIN1tzU5MEEaowZgoEpX NNo80UgLUfwb6nOZxLHnjpjpxcVwzVZb49rgUrMgzKKYRSbosuAv3uc2P5X9+1w8NXhD VC1p4T7ke3r8lPlU8aL6azn/7XOZpkE56yojDwc/yZGZQvyeeOlfsvo5LkFMnl/pg8Lf DA4w== X-Gm-Message-State: ALoCoQnHz6G+gXe+ehQRdVoozxVEcyIDyQ5NJJe2WUXTZky2mkYQFbFVmULZeUMPH9bVxwd81+tF X-Received: by 10.66.146.100 with SMTP id tb4mr108336840pab.104.1426528999150; Mon, 16 Mar 2015 11:03:19 -0700 (PDT) Received: from [10.206.92.95] ([67.142.235.252]) by mx.google.com with ESMTPSA id ae7sm18430970pac.19.2015.03.16.11.03.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Mar 2015 11:03:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Brian Rosen In-Reply-To: <550702F2.3090805@alum.mit.edu> Date: Mon, 16 Mar 2015 14:03:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D23251D-9FF7-4F9C-99CD-42DA2D189533@brianrosen.net> References: <20150113154647.9128.69519.idtracker@ietfa.amsl.com> <54B54462.8060308@alum.mit.edu> <6F2A17BA-AE0D-4370-A613-9E28B052AF16@cisco.com> <550702F2.3090805@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Cullen Jennings , "dispatch@ietf.org" Subject: Re: [dispatch] New Version Notification for draft-kyzivat-dispatch-trs-call-info-purpose-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:03:21 -0000 >> If we do proceed with this, I don't think the call-info is the = appropriate place to put it. I think a new header would be the right = thing. >=20 > We considered this, and thought that Call-Info was a more appropriate = choice. But either is acceptable to us. It is, exactly, information about the call, but I agree that a new = header is an acceptable solution. >> If the goal is purely to check the user is in the US, then having the = VRS check that they were sending media to an IP address inside the US = seems like it would be a better solution. >=20 > Perhaps, if the FCC agreed. Maybe it could be done as an = interpretation. > But it may also not be visible due to media relaying by the default = provider. >=20 Yeah, ubiquitous use of SBCs pretty much makes any addresses seen by the = recipient a non-starter. Please also note that the providers want the check to be the = responsibility of the provider who is actually providing the interpreter = service, and they explicitly support the =E2=80=9Cdial around=E2=80=9D = case that requires this work. While a VPN would fool the check, any form of NAT on an ISP or home = network is fine. Like anything else, this check merely increases the = cost of fraud, it doesn=E2=80=99t stop it. I also point out that use can be restricted to a private networks (the = one that interconnects providers). It=E2=80=99s pretty much in = everyone=E2=80=99s interests to strip the header if the call goes = outside the domain of interest. We can make that text as strict as we = want.= From nobody Mon Mar 23 05:58:10 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05971A1B89 for ; Mon, 23 Mar 2015 05:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.739 X-Spam-Level: X-Spam-Status: No, score=-101.739 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, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0J2e-9M-TBO7 for ; Mon, 23 Mar 2015 05:58:02 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284A71A1B24 for ; Mon, 23 Mar 2015 05:58:02 -0700 (PDT) Received: by lagg8 with SMTP id g8so133330339lag.1 for ; Mon, 23 Mar 2015 05:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rjKu81fkrq9YfdJOzjHw9gzOVRNxd9Bz7nokRAXQWNQ=; b=u5sRRsSzTxtx1DMtYmTIn8E+eeHJND1sLsu4o278oooHZym+1GE3UoLqR3WSxfiGsN /lZZPrpQpziFHUMUWcxZHoyq0Tw9xkOQwDGWv0laU2dO2Yf+U5beWharj1McDIyI1vHn OvixbuZD01wHKcKxYQ1nN30XI7FuBkofWWMxKvLFA24KeFsSMGlHcqGE7IsqHNeKb9oU SscCcSd7GKK88hHLR+ugav2xpwanf9cEoO6ZC9KhllM6YlBh7WluwgscJrbi4UnuR2xh +lrgVBUBqtt8O0mqtf+J1NGyGn+ibKu+6CTrQI8Zr7WJJHE8fvfVxRgH/E6dOvYavx7S Z83w== MIME-Version: 1.0 X-Received: by 10.113.11.12 with SMTP id ee12mr83213701lbd.5.1427115480566; Mon, 23 Mar 2015 05:58:00 -0700 (PDT) Received: by 10.25.17.195 with HTTP; Mon, 23 Mar 2015 05:58:00 -0700 (PDT) Date: Mon, 23 Mar 2015 07:58:00 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a1133a5b445cfe90511f4378f Archived-At: Subject: [dispatch] Call for notetakers, jabber scribe and remote queue manager X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 12:58:08 -0000 --001a1133a5b445cfe90511f4378f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, We have a very full agenda for this afternoon, so we'd like to solicit volunteers for notetakers(2), jabber scribe and a manager for the remote queue. The latter volunteer is needed due to an experiment we're running at this IETF with managing the queue for remote participants using Meetecho and providing audio input for the remote participants. Here are more details on the experiment that all WG participants (remote and physical should be aware of. There will be 2 queues - a virtual queue and an actual (in-room) queue Remote attendees will log into the Meetecho platform and will have a virtual mic line that they can enter if they have a question or comment. In-room participants will continue to use normal mic lines. This means that there will be a minimum of two queues =E2=80=94 one = physical in-room queue and one virtual =E2=80=94 and the chair (or delegate) will ne= ed to move back and forth between the two, giving people turns. When someone in the virtual queue has a turn, Meetecho will inject their audio the room so that they can speak directly to/with everyone in the actual meeting room. Thanks, Mary & Cullen --001a1133a5b445cfe90511f4378f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We have a very full agenda for = this afternoon, so we'd like to solicit volunteers for notetakers(2), j= abber scribe and a manager for the remote queue.=C2=A0 The latter volunteer= is needed due to an experiment we're running at this IETF with managin= g the queue for remote participants using Meetecho and providing audio inpu= t for the remote participants. =C2=A0=C2=A0

Here a= re more details on the experiment that all WG participants (remote and phys= ical should be aware of.=C2=A0 There will be 2 queues -=C2=A0=C2=A0a virtual queue and an actual (in-room= ) queue=C2=A0Remote att= endees will log into the=C2=A0Meetecho=C2=A0platform and will have a virtual mic line that they can enter if t= hey have a question or comment. In-room participants will continue to use n= ormal mic lines. This means that there will be a minimum of two queues =E2= =80=94 one physical in-room queue and one virtual =E2=80=94 and the chair (= or delegate) will need to move back and forth between the two, giving peopl= e turns. When someone in the virtual queue has a turn,=C2=A0Meetecho=C2=A0will inject their audio the room so= that they can speak directly to/with everyone in the actual meeting room.<= /span>

Thanks,
Mary & Cullen
--001a1133a5b445cfe90511f4378f-- From nobody Mon Mar 23 09:23:02 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8601A92B6 for ; Mon, 23 Mar 2015 09:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIYTsg78EDSc for ; Mon, 23 Mar 2015 09:22:59 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888A51ACC91 for ; Mon, 23 Mar 2015 09:22:59 -0700 (PDT) X-ASG-Debug-ID: 1427127776-05f27518b92e23c40001-qAklQb Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id BHTEPt7i3VMSfghj (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 17:22:56 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from dhcp-a24a.meeting.ietf.org (dhcp-a24a.meeting.ietf.org [31.133.162.74]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id t2NGMrPh023735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 17:22:55 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_C91EB416-853A-4FCB-8273-5D4135CA149C" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [dispatch] Call for notetakers, jabber scribe and remote queue manager In-Reply-To: Date: Mon, 23 Mar 2015 17:22:52 +0100 Message-Id: References: To: Mary Barnes X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1427127776 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 31.133.162.74 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_SA085, BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.17071 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail 0.10 BSF_SC0_SA085 Custom Rule SA085 Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Call for notetakers, jabber scribe and remote queue manager X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:23:02 -0000 --Apple-Mail=_C91EB416-853A-4FCB-8273-5D4135CA149C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello to everybody, if you want to familiarize with the moderation experiment (and = associated roles), here you can find summary information as well as = three short youtube video tutorials.: http://ietf92.conf.meetecho.com/index.php/UMPIRE_Project = Cheers, Simon > On 23/mar/2015, at 13:58, Mary Barnes = wrote: >=20 > Hi all, >=20 > We have a very full agenda for this afternoon, so we'd like to solicit = volunteers for notetakers(2), jabber scribe and a manager for the remote = queue. The latter volunteer is needed due to an experiment we're = running at this IETF with managing the queue for remote participants = using Meetecho and providing audio input for the remote participants. =20= >=20 > Here are more details on the experiment that all WG participants = (remote and physical should be aware of. There will be 2 queues - a = virtual queue and an actual (in-room) queue Remote attendees will log = into the Meetecho platform and will have a virtual mic line that they = can enter if they have a question or comment. In-room participants will = continue to use normal mic lines. This means that there will be a = minimum of two queues =E2=80=94 one physical in-room queue and one = virtual =E2=80=94 and the chair (or delegate) will need to move back and = forth between the two, giving people turns. When someone in the virtual = queue has a turn, Meetecho will inject their audio the room so that they = can speak directly to/with everyone in the actual meeting room. >=20 > Thanks, > Mary & Cullen > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_C91EB416-853A-4FCB-8273-5D4135CA149C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello to everybody,

if you want to familiarize with the moderation experiment = (and associated roles), here you can find summary information as well as = three short youtube video tutorials.:

http://ietf92.conf.meetecho.com/index.php/UMPIRE_Project

Cheers,

Simon


On = 23/mar/2015, at 13:58, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Hi all,

We = have a very full agenda for this afternoon, so we'd like to solicit = volunteers for notetakers(2), jabber scribe and a manager for the remote = queue.  The latter volunteer is needed due to an experiment we're = running at this IETF with managing the queue for remote participants = using Meetecho and providing audio input for the remote participants. =   

Here are more details on the experiment that all WG = participants (remote and physical should be aware of.  There will = be 2 queues -  a virtual queue and an actual (in-room) = queue Remote attendees will log into the Meetecho platform and = will have a virtual mic line that they can enter if they have a question = or comment. In-room participants will continue to use normal mic lines. = This means that there will be a minimum of two queues =E2=80=94 one = physical in-room queue and one virtual =E2=80=94 and the chair (or = delegate) will need to move back and forth between the two, giving = people turns. When someone in the virtual queue has a = turn, Meetecho will inject = their audio the room so that they can speak directly to/with everyone in = the actual meeting room.

Thanks,
Mary = & Cullen
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

  =                   =   =        = _\\|//_
            =                 =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                =      = Simon Pietro Romano
      =          Universita' di Napoli = Federico II
          =            =  Computer Engineering Department 
  =            Phone: +39 081 7683823 -- Fax: = +39 081 7683816
          =                     =              e-mail: spromano@unina.it

    = <<Molti mi dicono che lo scoraggiamento =C3=A8 l'alibi = degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
           =      =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   )
=                 =                   \_) =          ) /
    =                     =                     =                     =        (_/






= --Apple-Mail=_C91EB416-853A-4FCB-8273-5D4135CA149C-- From nobody Mon Mar 23 12:56:37 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B4A1A039A for ; Mon, 23 Mar 2015 12:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.087 X-Spam-Level: X-Spam-Status: No, score=-114.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_GREY=0.424, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcIZzfz_sbHm for ; Mon, 23 Mar 2015 12:56:35 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDC31A0385 for ; Mon, 23 Mar 2015 12:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=359; q=dns/txt; s=iport; t=1427140595; x=1428350195; h=from:content-transfer-encoding:date:subject:to: message-id:mime-version; bh=ipZu9prald7rLtblwH3OhCmHCRS+gGPw2fvcPZMoD1I=; b=gupRmmZv82SZTBUmnBJHeRuvr8cbDvi1TXz7WljwvhYlw+bVg9FAQ/4H +OfSZNwM595xfDDkIw43T5x/ihpfB987dsTfOpffPZjffJ1Fyn9pR9iWI GqoCjIBPAeXgUbwZpVxxU4X3oLNJ6tRugEIYsLJnEQI+eMnhX21rsexlf M=; X-IronPort-AV: E=Sophos;i="5.11,453,1422921600"; d="scan'208";a="134588532" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 23 Mar 2015 19:56:34 +0000 Received: from [127.0.0.1] (ssh-sjc-2.cisco.com [171.68.46.188]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t2NJuYjF003079; Mon, 23 Mar 2015 19:56:34 GMT From: Cullen Jennings Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Mar 2015 14:56:34 -0500 To: IETF Dispatch Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [dispatch] Meetecho virtual queueing experiment X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 19:56:36 -0000 Thanks for your willingness to participate in the Meetecho virtual = queueing experiment. We=E2=80=99ve prepared a short (5 question) survey = here: https://www.surveymonkey.com/s/92dispatch that I=E2=80=99d like to = ask you to share with WG participants. The feedback will be very helpful = as we work to improve services, both this week and beyond. From nobody Mon Mar 23 13:45:21 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD29E1B2A2A; Mon, 23 Mar 2015 13:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbAE5jCTk2BZ; Mon, 23 Mar 2015 13:45:15 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (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 4B08A1B2A0C; Mon, 23 Mar 2015 13:45:15 -0700 (PDT) Received: by labto5 with SMTP id to5so36395677lab.0; Mon, 23 Mar 2015 13:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JY5MKIgxpQASX3P+P8Pp5kNrv85F8kZwvhwi2Or/k80=; b=L/GSP62OeF/c1UV0NzmtzlS1t4nG0tfxqjJXmjChpyAUBiJULIcTZjbZuKLlpVgLgm zxGXpLOAGL3PaZ1xXgq/eg8mg9zp9+waPxMejfUbBpDW9AbrTTOq8h8mmgGs2ejnou8X PbdpdaUdE3fhRFIFLVfLInLgtn/RX2IHULLPvjLjgg0DIlK/urShAQ3xUXwT6i7TSNqI wZd9gh20KpYKGzBIO+T5elZjqy81ihJREQz6K2oN6/bhJWoVgIEZc7yegYgR9Tz08we3 HsQ7pzY4KOIfrq/+lJ4qvOFfh5JUrvIZ7mLkXmQV3tbXsfyk+q5W2XOH8rwe4H5PQfOc CbFw== MIME-Version: 1.0 X-Received: by 10.152.236.42 with SMTP id ur10mr763601lac.37.1427143513559; Mon, 23 Mar 2015 13:45:13 -0700 (PDT) Received: by 10.25.17.195 with HTTP; Mon, 23 Mar 2015 13:45:13 -0700 (PDT) In-Reply-To: <55105867.881fec0a.614d.fffffc9eSMTPIN_ADDED_BROKEN@mx.google.com> References: <55105867.881fec0a.614d.fffffc9eSMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 23 Mar 2015 15:45:13 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a113465f82b56370511fabeac Archived-At: Cc: SIPCORE Subject: [dispatch] Fwd: [SIPForum-techwg] SIPNOC 2015 Call for Presentations Deadline Extended To April 1st X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:45:18 -0000 --001a113465f82b56370511fabeac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI...this was one of the items mentioned during the WG session today. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Mon, Mar 23, 2015 at 1:14 PM Subject: [SIPForum-techwg] SIPNOC 2015 Call for Presentations Deadline Extended To April 1st To: techwg@sipforum.org Dear SIP Forum TechWG Members, Based on a number of requests for an extension to submit speaking proposals for SIPNOC 2015, we have decided to extend the CFP deadline to April 1, 2015. SIPNOC 2015 Call for Presentations proposals can be submitted by visiting the SIP Forum SIPNOC 2015 Call for Presentations webpage . Possible topics can include SIP peering, SIP trunking, Emergency Services, Congestion Control, Scaling and Capacity Issues, SIP-based applications, Routing, Security, SIP-Network Operations Center Best Practices, IPv6 deployment challenges, NNI, HD Voice, Standardization Issues and Progress, HD voice deployments, Video Interoperability, WebRTC and SIP, Testing or other issues facing SIP network operations. SIPNOC 2015 offers several different types of speaking opportunities including: - General Session Talks: A General Session presentation should be on a topic of interest to the general SIPNOC audience, and may be up to 30 minutes long (including time for Q&A). - General Session Panels: Panels are sessions with a moderator and a team of panelists. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will be organized. Panel selection is based on the importance, originality, focus and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. - Special Workshops: The SIPNOC 2015 program has been expanded to include special workshops that run for 1-2 hours, providing time to focu= s in-depth on a variety of issues important to the SIPNOC community. Topic= s can include a review of SIP RFCs and standards development, the regulato= ry environment, etc. - Research Topics: Researchers are invited to present short summaries of their work for operator feedback. Topics may include call routing, netwo= rk performance, statistical measurement and analysis and protocol developme= nt and implementation. Studies presented may be works in progress. Research= ers from academia, government, and industry are encouraged to present. - BOFs: BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the SIPNOC community. BOFs = may be held in break=E2=80=90out areas or in an unscheduled room. Requests f= or scheduled BOFs can be made at any time, including on site at the confere= nce. Presented by the SIP Forum, the leading industry association focused on the advancement of IP communications products and services based on the Session Initiation Protocol (SIP), the fifth annual SIPNOC conference is a unique event for service providers and carriers to gather to discuss the challenges of deploying and implementing SIP-based communications technology, and to learn the best-practices and strategies that enable the successful and profitable operation of SIP-based services and applications. SIPNOC 2015 attendees will include telecommunications providers, major backbone operators, interconnect and wholesale solution providers, ISPs, cable operators, wireless network operators as well as large enterprises deploying major SIP initiatives. ------------------------------ *SIPNOC 2015 General Info* The SIPNOC 2015 event website is located at www.sipnoc.org. To view the official call for presentations, which includes instructions on submitting material and specific SIPNOC policies, please visit www.sipforum.org/content/view/374/275/. To submit, visit https://www.easychair.org/conferences/?conf=3Dsipnoc2015. Registration for SIPNOC 2015 is officially open! The regular SIPNOC 2015 conference registration fee is $995 for one full day of SIP Training and two days of conference proceedings, including all meals (breakfasts, lunches and dinners) and break refreshments. *Individuals from SIP Forum Full Member companies are entitled to special savings! Please contact Marc Robins, SIP Forum President and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full Member discount code.* Register today at http://www.regonline.com/sipnoc2015. ------------------------------ *SIPNOC 2015 Sponsorship Information* For information about corporate sponsorship opportunities at SIPNOC 2015, please contact Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 or marc.robins@sipforum.org. ------------------------------ All best, Marc ************************* Marc Robins President and Managing Director SIP Forum http://www.sipforum.org Mobile: 203-829-6307 SkypeMe! marcrobins ************************* _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --001a113465f82b56370511fabeac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI...this was one of the items mentioned during the WG se= ssion today. =C2=A0=C2=A0

Regards,
Mary.
=

---------- Forwarded message ----------=
From: Marc Robins &= lt;marc.robins@sipforum.org= >
Date: Mon, Mar 23, 2015 at 1:14 PM
Subject: [SIPForum-tec= hwg] SIPNOC 2015 Call for Presentations Deadline Extended To April 1st
T= o: techwg@sipforum.org

Dear SIP Forum Tec= hWG Members,

<= p>Ba= sed on a number of requests for an extension to submit speaking proposals f= or SIPNOC 2015, we have decided to extend the CFP deadline to April 1, 2015= .

SIPNOC 2015 Call for Presentations proposals can b= e submitted by visiting the SIP Forum SIPNOC 2015 Call for Presentations w= ebpage. Possible topics can include SIP peering, SIP trunking, Emergenc= y Services, Congestion Control, Scaling and Capacity Issues, SIP-based appl= ications, Routing, Security, SIP-Network Operations Center Best Practices, = IPv6 deployment challenges, NNI, HD Voice, Standardization Issues and Progr= ess, HD voice deployments, Video Interoperability, WebRTC and SIP, Testing = or other issues facing SIP network operations.

= SIPN= OC 2015 offers several different types of speaking opportunities including:=

  • General Session Talks: A General Session presentat= ion should be on a topic of interest to the general SIPNOC audience, and ma= y be up to 30 minutes long (including time for Q&A).
  • General Se= ssion Panels: Panels are sessions with a moderator and a team of panelists.= The panel moderator should submit an abstract on the panel topic, a list o= f panelists, and how the panel will be organized. Panel selection is based = on the importance, originality, focus and timeliness of the topic, expertis= e of proposed panelists, as well as the potential for informative and contr= oversial discussion.
  • Special Workshops: The SIPNOC 2015 program has = been expanded to include special workshops that run for 1-2 hours, providin= g time to focus in-depth on a variety of issues important to the SIPNOC com= munity. Topics can include a review of SIP RFCs and standards development, = the regulatory environment, etc.
  • Research Topics: Researchers are in= vited to present short summaries of their work for operator feedback. Topic= s may include call routing, network performance, statistical measurement an= d analysis and protocol development and implementation. Studies presented m= ay be works in progress. Researchers from academia, government, and industr= y are encouraged to present.
  • BOFs: BOFs (Birds of a Feather sessions) are informal se= ssions on topics which are of interest to a portion of the SIPNOC community= . BOFs may be held in break=E2=80=90out areas or in an unscheduled room. Re= quests for scheduled BOFs can be made at any time, including on site at the= conference.

Presented by the SIP Forum= , the leading industry association focused on the advancement of IP communi= cations products and services based on the Session Initiation Protocol (SIP= ), the fifth annual SIPNOC conference is a unique event for service provide= rs and carriers to gather to discuss the challenges of deploying and implem= enting SIP-based communications technology, and to learn the best-practices= and strategies that enable the successful and profitable operation of SIP-= based services and applications.

SIPNOC 2015 attendees wil= l include telecommunications providers, major backbone operators, interconn= ect and wholesale solution providers, ISPs, cable operators, wireless netwo= rk operators as well as large enterprises deploying major SIP initiatives.<= u>

SIPNOC 2015 General Info

The SIPNOC 2015 event website is located at www.sipnoc.org.

To view the official call for presentations, which includes instructio= ns on submitting material and specific SIPNOC policies, please visit www.s= ipforum.org/content/view/374/275/. To submit, visit https:/= /www.easychair.org/conferences/?conf=3Dsipnoc2015.=

Registration for SIPNOC 2015 is officially open!

= The regular SIPNOC 2015 conference registration fee is $995 for one full da= y of SIP Training and two days of conference proceedings, including all mea= ls (breakfasts, lunches and dinners) and break refreshments.<= /span>

Individuals from SIP Forum Full Member companies a= re entitled to special savings! Please contact Marc Robins, SIP Forum Presi= dent and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full= Member discount code.

Register today at http://www.regon= line.com/sipnoc2015.=C2=A0

<= span style=3D"font-family:"Calibri","sans-serif"">SIPNO= C 2015 Sponsorship Information

For information= about corporate sponsorship opportunities at SIPNOC 2015, please contact M= arc Robins, SIP Forum President and Managing Director, at 203-829-6307 or marc.robins@sip= forum.org.

= =C2=A0

All best,

<= p class=3D"MsoNormal">=C2=A0

Marc

=C2=A0

*************************

Marc Robins

President and Managing Directo= r

SIP Forum

http= ://www.sipforum.org

Mobile: 203-829-6307

SkypeMe! marcrobins<= u>

=C2=A0

*************************

=C2=A0


_________________________________= ______________
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at:=C2=A0 http://sipforum.org/mailman/listinfo/t= echwg


--001a113465f82b56370511fabeac-- From nobody Wed Mar 25 16:27:33 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F701B2A9F for ; Wed, 25 Mar 2015 16:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hor1YZlQd4vs for ; Wed, 25 Mar 2015 16:27:23 -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 216261B29E7 for ; Wed, 25 Mar 2015 16:27:22 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-c9-551344587bee Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.32.28835.85443155; Thu, 26 Mar 2015 00:27:20 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.210.2; Thu, 26 Mar 2015 00:27:19 +0100 Message-ID: <55134454.9050302@ericsson.com> Date: Wed, 25 Mar 2015 18:27:16 -0500 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: DISPATCH list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKJMWRmVeSWpSXmKPExsUyM+JvjW6Ei3CowZLtahZLJy1gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrczt9kKnmtVTHp6gr2BcaVyFyMnh4SAicSlf5NYIGwxiQv3 1rOB2EICRxglJs8T7mLkArKXM0pM/fmfHSTBK6AtcfDBGmYQm0VAVWL/5UZWEJtNwELi5o9G sGZRgWCJn+27mSDqBSVOznwCtkAEqH7X7AdgtrCAh8SrDWsZuxg5OJgFNCXW79IHCTMLyEs0 b53NDHGDtkRDUwfrBEa+WUgmzULomIWkYwEj8ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2M wHA6uOW31Q7Gg88dDzEKcDAq8fBuUBEKFWJNLCuuzD3EKM3BoiTOa2d8KERIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QDo+6NAMWUV/vZnuw1edNmeOrf3vO8B1p1fBqPOc/6k/L6c/HjM8v5 3JYvvHku6vtLhwesUYsKDeLL/zTvL77HLP9YrbDi57O/KRr+jz2PNH3+u6eZS23OZ/n81OzW hH2/N+2f6nVv68ojylOM3i5Z+TLwlOqGT49nFe0VebvQIO3OlR6bXu9bb0WVWIozEg21mIuK EwEnBvwCCAIAAA== Archived-At: Subject: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 23:27:31 -0000 Dispatch, AVTCORE WG has discussed a couple of proposals that discusses end-to-end security in centralized RTP based conferences. Drafts for these Proposals: https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framework/ https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ In these discussions one has reached the conclusion that this work requires its own venue to continue the work. Therefore a number of interested has put together a initial draft charter for a new WG. Please review and provide feedback. Name: Privacy Enhanced RTP Conferencing (PERC) Area: ART Chairs: TBD Mailing List: Motivation for new WG --------------------- RTP-based real-time multi-party interactive media conferencing is today in widespread use. Many of the deployments uses one or more centrally located media distribution devices that perform selective forwarding or mixes media streams received from the participating endpoints. The media transport protocol commonly used is RTP (RFC3550). There are various signaling systems used to establish these multi-party conferences. These conferences require security to ensure that the RTP media and related meta data of the conference is kept private to the set of invited participants and only other devices trusted by those participants with their media. At the same time, multi-party media conferences do need source authentication and integrity checks to protect against modifications, insertions or replay attacks. Media distribution devices supporting these conferences may also perform RTP header changes and often consume and create RTCP messages for efficient media handling. To date, deployment models for these multi-party media distribution devices do not enable them to perform their functions without having keys to decrypt the participants’ media, primarily using Secure RTP (RFC3711) to provide session security. A new architecture model and related specifications is needed, with a focused effort from the RTP and Security communities. WG Objectives ------------- This WG will work on a solution that enables centralized SRTP based conferencing where the central device distributing the media is not required to be trusted with the keys to decrypt the participant’s media. The media must be kept confidential and authenticated between an originating endpoint and the explicitly allowed receiving endpoints or other devices. Further it is desired that a solution still provide replay protection so that the media distribution devices can’t replay previous parts of the media. The solution must also provide security for each hop between endpoints and multi-party media distribution devices and between multi-party media distribution devices. The RTCP messages and RTP header extensions required for the media distribution device to perform the selective media forwarding may require both source authentication and integrity as well as confidentiality. The solution may also consider providing end-to-end security for a subset of the RTCP messages or header extensions. The solution should be usable from both SIP and WebRTC endpoints that implement the extension defined by this WG. This WG will perform the following work: 1. Define a general architecture and RTP topology(s) that enables end-to-end media security for multi-party RTP conferencing. 2. Define the trust model and describe the resulting security properties. 3. Specify any necessary extensions to SRTP. 4. Define a Key Management Function that distributes the keys. The system needs to be able to bind the media to the sender of the media’s identity and/or the identity of the conference. Collaboration ------------- If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. Potential work that might require work in other WGs are DTLS extensions (TLS) as well as RTP header extensions (AVTEXT). This requires strong collaboration with the security area. We will notify SIPREC, W3C WebRTC, AVTCore, and other related groups about this work. Non-Goals --------- The WG is not chartered to extend any signaling system used to establish the RTP based conferences. It will however, need to consider in its architecture how the solution may integrate with these systems. Will not consider non-real-time usages, multicast based media distribution, or Security descriptions-based keying. Goals and Milestones -------------------- TBD Submit architecture or framework specification to IESG (Standards Track) TBD Submit protocol specification(s) to IESG (Standards Track) Cheers Magnus Westerlund (AVTCORE WG chair) ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------