From nobody Mon Mar 9 11:06:08 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: X-Mailman-Approved-At: Mon, 09 Mar 2015 11:06:07 -0700 Subject: [cnit] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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:19:00 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1ACF1AC3B8 for ; Mon, 9 Mar 2015 12:18:59 -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 zKqs_fh0ajr9 for ; Mon, 9 Mar 2015 12:18:57 -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 D13271ABD35 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: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:18:59 -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:26:27 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: Subject: Re: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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 Tue Mar 10 11:37:59 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEB11A87F2 for ; Tue, 10 Mar 2015 11:37:56 -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 J0u9Lky0iiDo for ; Tue, 10 Mar 2015 11:37:54 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (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 6FA121A87E3 for ; Tue, 10 Mar 2015 11:37:50 -0700 (PDT) Received: by qcyl6 with SMTP id l6so4208976qcy.13 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=QAM1ULA/wTJaQ0WMBJ6cObVGl/WLuNjTL9Azl5TF8POU9hXLLJSKSOkd3Dj2vp7s+b wkoWYLn74WpT1e/LksDIPULDC5+OJwRUdXNfw9izHK8wG+2Cro5DFzq/i4sRV2tOIH6U yauFLvn3l/hcbqkpJTuQlSeyt6uGI5X1hdZWQLJO64DUoMkOHouKgh7taTB4t+al7e8y AiQaCDdUxkUQXK32/WHHBcvbSloWsEpz+1Jhr0+oO3CkBHlgDgpvOvgaYktU77yeWq80 PufxkCQwkuAk3SsoBU30QzYjdBQEoEeoYWF5KjC0SBJI0JmDg+CB2RWNdeRhO/EYOB2m rfAA== X-Gm-Message-State: ALoCoQnzodwwTLoYOBSd+jx5yK4hFu5KMJi9ufWd9BS9w38oCwYcDspyEKis9ujFCn2RWC5Z0eK6 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: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:37:57 -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:59 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6AF1A8866 for ; Tue, 10 Mar 2015 11:53:46 -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 eVqlfs0MxhIL for ; Tue, 10 Mar 2015 11:53:43 -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 455421A8841 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: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:53:46 -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:10 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB86A1A00B6 for ; Tue, 10 Mar 2015 11:58:07 -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 kVTXoqt0gBah for ; Tue, 10 Mar 2015 11:58:05 -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 44D0D1A066B 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: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 18:58:08 -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:17 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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:30 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6AB1A8866 for ; Tue, 10 Mar 2015 12:37:19 -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 i_fykgZfZ-7g for ; Tue, 10 Mar 2015 12:37:16 -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 A22591A8729 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: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 19:37:19 -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:04 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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:22 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBF21A892E for ; Tue, 10 Mar 2015 13:01:08 -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 GpOSTfWPwkXH for ; Tue, 10 Mar 2015 13:01:05 -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 68A661A892C 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: [cnit] [Modern] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 20:01:08 -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 Wed Mar 11 09:19:45 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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:41 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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:47 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [Modern] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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:32:58 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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:38 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4694E1A0318 for ; Wed, 11 Mar 2015 09:43:35 -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 5ymckNgVvt8A for ; Wed, 11 Mar 2015 09:43:34 -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 D1FCA1A0404 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: [cnit] [Modern] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 16:43:35 -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:35 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C10F1A7020 for ; Wed, 11 Mar 2015 11:32:34 -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=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 DMLOOIzist9d for ; Wed, 11 Mar 2015 11:32:33 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (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 3DD341A701E for ; Wed, 11 Mar 2015 11:32:33 -0700 (PDT) Received: by qcxm20 with SMTP id m20so12514323qcx.3 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=gb4ll+db1pAohOaHFv7gHWdfFC70ydjGFMnPIPJNRvOZqKojQcl2KQ4StDgNqiRw9y EoLnqHH+n+AtzbS+4L4tOjTVQkOSsdruVNSgwuOnDEemP1LI/Ulc94YAge6ksA2ku9i7 1Yr3d2KwN2QeP7qWblQIOND65ww0b+OHAEsTYJesurlIJOeKtitnGw2B0GfGYKTgQG6c GbJHjSrS75f8K67vxqBKsNgbIiQk7At2tjC7MhVCc/f6dl0x5Fuspj+lKUyrzP1ALATt 5FAebyfGM1LTcpKuDyH3wTa0KJ0Wp4lH6ROdJGrCuRKa8GAtBXVDdp60SncIJ7F62DfU X8bA== X-Gm-Message-State: ALoCoQmaZ0RH9POioEB+ivpCNDZaljNcVU+MyXmD0tHRkGgt+2Uu314l1JOPq3Q627OyTaghRGzV 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" , Richard Shockey Subject: Re: [cnit] [Modern] [dispatch] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:32:34 -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:59 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [Modern] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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 Mon Mar 16 04:12:57 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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
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 an agreed list of enterprise types? We could go t= he ITU route and define the protocol machinery and leave the enterprise defi= nitions a local matter. However, that does not foster global interoperabilit= y. Moreover, your state-sponsored source of foreign currency might look to m= e 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 <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:38:37 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@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: [cnit] [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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:28 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AC31A8723 for ; Mon, 16 Mar 2015 05:44:26 -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 SXIoFw4UA6OS for ; Mon, 16 Mar 2015 05:44:23 -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 C233C1A8714 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: [cnit] [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 12:44:26 -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 11:05:20 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3A81A1F73 for ; Sun, 15 Mar 2015 18:52:42 -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=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 PeV7-u7CjjIi for ; Sun, 15 Mar 2015 18:52:41 -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 DDC6E1A2119 for ; Sun, 15 Mar 2015 18:52:37 -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 t2G1noZY013107 for ; Sun, 15 Mar 2015 21:52:36 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 8D6E56D for ; Sun, 15 Mar 2015 21:52:36 -0400 (EDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by hazelnut (Postfix) with ESMTP id 775F96D for ; Sun, 15 Mar 2015 21:52:36 -0400 (EDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2G1qaQU003662 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 15 Mar 2015 21:52:36 -0400 (EDT) Received: by qcyi15 with SMTP id i15so32426382qcy.0 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=Cm0FTtpTrPnvSoCGBB6GY5dS06fW3hhBy+Xz6xqRuSATODpu/qGkT1Haas4vhsvWke yGT1mWlFBgYM6Dy6NyfCDHkPhL75Evkgug4D0psNwkPZddLX8BHPCT/WYBtRPnyWOSZn +S1+lF/Q7UrRCGUqxdCt6L7FGZ8Em3hCr0xoTWf9moHvMkRvMOC/0SCOROWtFgNtYMh1 lkHDFJkvq1za8SDnQifSEbcOSRnPA0Sc/fOtFoDrj+3kSXPd6xMzDr18gZagRaDOsxJ2 w92hmMBozfRSS7SGmTQoOhlisRJoo2coFvheCNbeJulLkPYTp2oVHveZouOpjj5t9y4v dO2Q== X-Gm-Message-State: ALoCoQnI8raG3IjnectIMh0Nhk90mPlxyGNceEeu0DxLM0U3+ZYO5TLgMfnOW8QeC+BnFbUjuvCzeIUdN3PnuTHD6mJEUs3I4Fnn/PkcudcAVdqTJ9NJcvKz82x7hhwwlCRqU4tZT6Xk X-Received: by 10.55.31.101 with SMTP id f98mr75197085qkf.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.7 Archived-At: X-Mailman-Approved-At: Mon, 16 Mar 2015 11:05:19 -0700 Cc: cnit@ietf.org, "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [cnit] [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 01:52:42 -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 11:05:21 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1871A8706 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=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 kb1nePS41Km7 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 2F66B1A86FA for ; Mon, 16 Mar 2015 05:10:35 -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 t2GCAZqh021644 for ; Mon, 16 Mar 2015 08:10:35 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 334ED6D for ; Mon, 16 Mar 2015 08:10:35 -0400 (EDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by hazelnut (Postfix) with ESMTP id 1CD1E6D for ; Mon, 16 Mar 2015 08:10:35 -0400 (EDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t2GCAYCT008231 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 16 Mar 2015 08:10:34 -0400 (EDT) Received: by qcaz10 with SMTP id z10so41057679qca.1 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=GiUEZpz2KjG+1UYl8KvSTN1hM6t/pVat3Obz/LYnWCva/kkftONxz5+X0tQs45zl9Z 1zxBYNG8pZLUzsRaufsbsu3S+4l0x5tIN9MfEiI6u94O1otlxvCItJj+7BNPVsOY+q61 lyAYEsIJh1d55qGODfDTFD2F+Ol9MBjNxEc20TirEwgtZe7Um1PIUvjHQMe6IxJxjBOu tjcMe+Zz4O8R9PNquVdOZJy2bDnQhttALoNWEOY1BM8nZ7sIqwY3V0F+zmbzmsKui+Nd 7ge+x4I84Z4/mky0RkzLjl6JiDO2CaDgleAsR6vISOPRFCeZkW4NK3vj6D356Jg+axos tWxg== X-Gm-Message-State: ALoCoQkpP4aPWfmelQCZDoDNULPxEvRgUHvX4IGgFWeNoQRd/bckwgwn6Qkxbf/nvXMd/Fq6RzySH3/xWTDLTpFFVS/WrEffTJVfwTTl5xQDfMJEVyYGcRn75lj6S9md241mOr4A8k2a X-Received: by 10.55.55.81 with SMTP id e78mr120060534qka.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.7 Archived-At: X-Mailman-Approved-At: Mon, 16 Mar 2015 11:05:19 -0700 Cc: "cnit@ietf.org" , "dispatch@ietf.org" , "modern@ietf.org" Subject: Re: [cnit] [dispatch] [Modern] CNIT and Modern Charter X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion 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 30 08:24:17 2015 Return-Path: X-Original-To: cnit@ietfa.amsl.com Delivered-To: cnit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E3A1AD04E for ; Mon, 30 Mar 2015 08:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 VcqjAOZwpRfh for ; Mon, 30 Mar 2015 08:24:07 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id B45E01AC408 for ; Mon, 30 Mar 2015 08:24:07 -0700 (PDT) Received: (qmail 4787 invoked by uid 0); 30 Mar 2015 15:24:05 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy1.mail.unifiedlayer.com with SMTP; 30 Mar 2015 15:24:05 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id 9r3u1q01c1MNPNq01r3xk4; Mon, 30 Mar 2015 09:04:02 -0600 X-Authority-Analysis: v=2.1 cv=DIYcvU9b 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=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=emO1SXQWCLwA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=0GGBgIRINb6iDwWYrKoA:9 a=W4uUKRL0LGgmwpqi:21 a=y8-3hfGJfb_WDmTj:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=xDZgwH7Mb0iIBksiyhQA:9 a=1KtLjQhuG3FlbuWz:21 a=0CQd_kVIEq8b95Da:21 a=-XkWZPOy6TvLQ-Pk:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=6UIaq3Bcl8oA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:Message-ID:CC:To:From:Subject:Date; bh=tI5uK9IqxqFpjQKU/nLXdUYrCmHiaDn8VLwRyLc4jCA=; b=LN5lNmRxmZrBdrb+K8JSJl/hYs19bKWUKyvL6Gxh49vAZb6VoYARqlWqwU2GtGyzNMA8JTpPROUYeTw21qOKNKKuSpGLgSGTdR0VRvr65fBAdFBamkbP2yeiQuG0FhMG; Received: from [108.56.131.201] (port=59912 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YcbEK-0000Ez-BD; Mon, 30 Mar 2015 09:03:56 -0600 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Mon, 30 Mar 2015 11:03:49 -0400 From: Richard Shockey To: Message-ID: Thread-Topic: CNIT Charter bashing.. Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3510558236_1009830" 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: Ben Campbell , alissa@cooperw.in Subject: [cnit] CNIT Charter bashing.. X-BeenThere: cnit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Calling Name Identity Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 15:24:13 -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_3510558236_1009830 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable My running assumption after DISPATCH last week is we have a conditional go ahead to proceed to a WG if we can answer the questions posed which, if memory serves me, A. Refine and or further define the problem we are trying to solve. B. Include into the requirements the Trust Validation concept. I presume Brian is willing to help edit text on that. I do have a issue for the AD=B9s. I really want to know up front if we have t= o define a new header here. I would like to know in advance the level of torture we are going to have t= o deal with. ************ CNIT Charter [Calling Name Identity Trust] =20 WG Chairs TBD: =20 Calling Name Delivery [CNAM] is currently a string of 15 ASCII and/or potentially 50 characters of information associated with a specific E.164 calling party number in the Public Switched Telephone Network [PSTN] as defined in ITU-T Recommendation I.251.9. This PSTN 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 imbedded in the Provider Asserted Identity [PAI] header. =20 As with the originating source telephone number, this data can be altered i= n 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(s) of trusted multi media 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 accep= t the INVITE or not. =20 The working group will not invalidate any existing SIP mechanism for anonymous calling.=20 =20 The working group will not define registration, provisioning or data query response mechanisms for the creation and storage of the CNIT data object(s) . =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 and other appropriate SDO=B9s 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 =B7 A problem statement and requirements detailing the current deployment environment and situations that motivate work on Calling Name Identity Trust. =B7 Define either a new SIP header or document a repurpose of an SIP existing header for Calling Name Identify Trust data =B7 Define a data model for the Calling Name Identity Trust object (s) which may include various forms of multimedia data. =B7 Define a Trust Mechanism for CNIT data. (Brian text?) =B7 Deliver an analysis of privacy implications of the proposed Calling Name Identity Trust mechanism. =20 =20 Milestones: =20 January 2016 : Problem Statement and Requirements for Calling Name Identity Trust =20 April 2016 : Data Objects and SIP headers for Calling Name Identity Trust =20 November 2016 : Trust Mechanism for Calling Name Identity Trust =20 =20 =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 --B_3510558236_1009830 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

My running assumption afte= r DISPATCH last week is we have a conditional go ahead to proceed to a WG if= we can answer the questions posed which, if memory serves me,
A. Refine and or further define the problem we are trying to sol= ve.

B. Include into the requirements the Trust Vali= dation concept.  I presume Brian is willing to help edit text on that.<= /div>

I do have a issue for the AD’s. I really want= to know up front if we have to define a new header here.

I would like to know in advance the level of torture we are going to = have to deal with.


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

CNIT Charter [Calling Name Identity Trust]<= /p>

 

WG Chairs TBD:

 

Calling Name Delivery [CNAM] is currently a string of = 15 ASCII and/or potentially 50 characters of information associated with a specific E.164 calling party number in the Public Switched Telephone Networ= k [PSTN] as defined in ITU-T Recommendation I.251.9. This PSTN data is sent by th= e originating network only at the specific request of the terminating network= via a SS7 Transaction Application Part [TCAP] response message.  In the Se= ssion Initiation Protocol [SIP] this information can be inserted into the FROM: part of the originating INVITE message or imbedded in the Provider Asserted Identity [PAI] header.

 

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 defin= e a data structure, a new SIP header or repurpose an existing SIP header to carry an= advanced form(s) of trusted multi media 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 th= e calling party in order that the called party make a more reasoned and infor= med 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 not define registration, provis= ioning or data query response mechanisms for the creation and storage of the CNIT = data object(s) .

 

The working group will, to the best of its ability, re= use 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 S= A-1 and other appropriate SDO’s in order to coordinate efforts.

 

The working group will coordinate with National Number= ing Authorities and National Regulatory Authorities as needed.

 

The working group will deliver the flowing.=

 

=B7      A problem statement and requirements detailing the current deployment environment and situations that motivate work on Cal= ling Name Identity Trust.

=B7      Define either a new SIP header or document a repurpose of an SIP existing header for Calling Name Identify Tr= ust data

=B7      Define a data model for the Calling Name Identity Trust object (s) which may include various forms of multimedi= a data.

=B7      Define a Trust Mechanism for CNIT data. (Brian text?)

=B7      Deliver an analysis of privacy implications of the proposed Calling Name Identity Trust mechanism.

 

 

Milestones:

 

January 2016 : Problem Statement and Requirements for Calling Name Identity Trust

 

April  2016 : Data Objects and SIP headers for Calling Name Identity Trust

 

November 2016 :  Trust Mechanism for Calling Name= Identity Trust

 

 

 

 

— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shock= ey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-59= 3-2683

--B_3510558236_1009830--