From nobody Mon May 25 14:51:23 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 438E31A9029 for ; Mon, 25 May 2015 14:51:22 -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 PGJMalXoqufs for ; Mon, 25 May 2015 14:51:17 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id DFBC91A9009 for ; Mon, 25 May 2015 14:51:16 -0700 (PDT) Received: (qmail 4968 invoked by uid 0); 25 May 2015 21:51:12 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy4.mail.unifiedlayer.com with SMTP; 25 May 2015 21:51:12 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id YTPw1q0031MNPNq01TPzmM; Mon, 25 May 2015 21:24:01 -0600 X-Authority-Analysis: v=2.1 cv=D8zUdJhj c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=yfQaRmzNqocA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=h1PgugrvaO0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=pGLkceISAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=5b3Chl7SFygC0E7W7ScA:9 a=pOC0elmASihGrJeA:21 a=O3nCA2uf2CyiiQU8:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=OtSP2khXrCftyCH1UqcA:9 a=Lp4GW45GXksn2Ej1:21 a=iVek6wMaWXj_g7d7:21 a=VvqDqTHEcdcI2ZSi: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:To:From:Subject:Date; bh=wzKmgnayvhaAD/qvo/T81YDAy7tku+L+GEfFqGOEP5s=; b=dJif6OUTGEoz9rD28fLkjy7nvuNtFhWoPYgxi3K6R4XEFRXRUl1CuNAEFgYM3WtevYqCDYbsmf6f8nY4Knez2IJ8jRNsNlAAUo1PRtRDOLRb4K5Xgq1eFFTIxhYDk6Ll; Received: from [108.56.131.201] (port=50135 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Ywzxi-0005lk-Kq for cnit@ietf.org; Mon, 25 May 2015 15:31:07 -0600 User-Agent: Microsoft-MacOutlook/14.5.0.150423 Date: Mon, 25 May 2015 17:31:02 -0400 From: Richard Shockey To: Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3515419866_229140" 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] 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, 25 May 2015 21:51:22 -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_3515419866_229140 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable From: Mary Barnes Date: Friday, May 22, 2015 at 12:58 PM To: Richard Shockey Subject: Re: [cnit] CNIT Charter bashing.. Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the data object and headers without having defined the trust model. RS> Mary I=B9m not sure about that statement. I can certainly anticipate several deployment models where the trust mechanism (aka signing) does not need to be formally integrated in the solution especially those where the exchange of data is more bi-lateral and the trust mechanism is at lower layers of the stack than the signaling. My initial concern is what is the header and what is the data object(s) carried in the header. How the CNIT data is created should not be our concern. I totally agree that the more narrow the scope aka MARTINI the greater the chance of success and early deployments. I=B9ll have more comments about the charter shortly. However, I think it's important that we're clear that we anticipate gettin= g the proposed mechanism defined early and then hammer out the trust model. We could just do two milestones which is what Martini did: 1) Problem Statement and Requirements and 2) Solution. The charter provides the detailed deliverables in the body earlier and I'm not sure that we would want things in separate documents UNLESS we think those mechanisms could be used for other things. But, I don't think so - I think the trust model has to be ingrained with those. Let me know your thoughts. Regards, Mary. On Fri, May 22, 2015 at 11:11 AM, Mary Barnes wrote: > Just FYI, I'm working on updates to this charter and will ship to you sho= rtly > for review. We can then repost on CNIT/DISPATCH and see if we can get th= is > wrapped up. I will separately ping Ben and let him know that this ought = to be > ready for him to send to the IESG soon and stress the importance of doing= this > work in the IETF and the careful selection of chairs. >=20 > Regards, > Mary. >=20 > On Mon, Mar 30, 2015 at 10:03 AM, Richard Shockey wr= ote: >>=20 >> 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, >>=20 >> A. Refine and or further define the problem we are trying to solve. >>=20 >> B. Include into the requirements the Trust Validation concept. I presum= e >> Brian is willing to help edit text on that. >>=20 >> I do have a issue for the AD=B9s. I really want to know up front if we hav= e to >> define a new header here. >>=20 >> I would like to know in advance the level of torture we are going to hav= e to >> deal with. >>=20 >>=20 >> ************ >> 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.16= 4 >> 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 netw= ork >> 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 altere= d in >> transit creating a variety of malicious abuses similar to the ones ident= ified >> 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 th= e >> called party make a more reasoned and informed judgment on whether to ac= cept >> the INVITE or not. >> =20 >> The working group will not invalidate any existing SIP mechanism for >> anonymous calling. >> =20 >> The working group will not define registration, provisioning or data que= ry >> 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 an= d >> National Regulatory Authorities as needed. >> =20 >> The working group will deliver the flowing. >> =20 >> =B7 A problem statement and requirements detailing the current deploym= ent >> environment and situations that motivate work on Calling Name Identity T= rust. >>=20 >> =B7 Define either a new SIP header or document a repurpose of an SIP >> existing header for Calling Name Identify Trust data >>=20 >> =B7 Define a data model for the Calling Name Identity Trust object (s) >> which may include various forms of multimedia data. >>=20 >> =B7 Define a Trust Mechanism for CNIT data. (Brian text?) >>=20 >> =B7 Deliver an analysis of privacy implications of the proposed Callin= g >> Name Identity Trust mechanism. >>=20 >> =20 >> =20 >> Milestones: >> =20 >> January 2016 : Problem Statement and Requirements for Calling Name Ident= ity >> Trust >> =20 >> April 2016 : Data Objects and SIP headers for Calling Name Identity Trus= t >> =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 >>=20 >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >>=20 >=20 --B_3515419866_229140 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable


From: Mary = Barnes <mary.ietf.barnes@gmai= l.com>
Date: Friday, May 22= , 2015 at 12:58 PM
To: Richard Sho= ckey <richard@shockey.us>
<= span style=3D"font-weight:bold">Subject: Re: [cnit] CNIT Charter bashi= ng..

Attached is what I have at this = point. Really, the only thing I'm struggling with is the milestones as I don= 't think we can request publication of the data object and headers without h= aving defined the trust model. 


RS> Mary I’m not sure about that statement. I can certainly= anticipate several deployment models where the trust mechanism (aka signing= ) does not need to be formally integrated in the solution especially those w= here the exchange of data is more bi-lateral and the trust mechanism is at l= ower layers of the stack than the signaling. My initial concern  is wha= t is the header and what is the data object(s) carried in the header. How th= e CNIT data is created should not be our concern.

I= totally agree that the more narrow the scope aka MARTINI the greater the ch= ance of success and early deployments.

I’ll h= ave more comments about the charter shortly.  


However, I think = it's important that we're clear that we anticipate getting the proposed mech= anism defined early and then hammer out the trust model.  We could just= do two milestones which is what Martini did: 1) Problem Statement and Requi= rements and 2) Solution.  The charter provides the detailed deliverable= s in the body earlier and I'm not sure that we would want things in separate= documents UNLESS we think those mechanisms could be used for other things. = But, I don't think so - I think the trust model has to be ingrained with tho= se.   

Let me know your thoughts.

<= /div>
Regards,
Mary.

On Fri, May 22, 2015 at 11:11 AM, Mary Barnes = <mary.ietf.barnes@gmail.com> wrote:
Just FYI, I'm working on updates to this charter and wi= ll ship to you shortly for review.  We can then repost on CNIT/DISPATCH= and see if we can get this wrapped up.  I will separately ping Ben and= let him know that this ought to be ready for him to send to the IESG soon a= nd stress the importance of doing this work in the IETF and the careful sele= ction of chairs.

Regards,
Mary.

On Mo= n, Mar 30, 2015 at 10:03 AM, Richard Shockey <richard@shockey.us> w= rote:

My running assumption after DISPATCH last w= eek is we have a conditional go ahead to proceed to a WG if we can answer th= e questions posed which, if memory serves me,

A. Re= fine and or further define the problem we are trying to solve.
B. Include into the requirements the Trust Validation concept.&n= bsp; I presume Brian is willing to help edit text on that.

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 li= ke to know in advance the level of torture we are going to have to deal with= .


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

CNIT Charter [Calling Name Identity Trust]

 

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 Recommendatio= n 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 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.<= u>

 

= 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 C= NIT 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 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 w= ill not invalidate any existing SIP mechanism for anonymous calling. 

 

The working group will not d= efine registration, provisioning or data query response mechanisms for the creation and storage of the CNIT = data object(s) .

 

<= p class=3D"MsoNormal">The working group will, to the best of its ability, reus= e existing IETF protocols.

 <= /p>

Full Internationalization of the Calling Name Identi= ty Trust data object(s) is a requirement.

<= /u> 

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 wo= rking group will coordinate with National Numbering Authorities and National Regulatory Authorities as needed.

 

The worki= ng 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.<= u>

 

=  

Milestones:

 

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

 

April  2016 : Data Objects and SIP headers for Calling Name Identity Trust<= u>

 

= November 2016 :  Trust Mechanism for Calling Name Identity Trust

 

 

 <= /u>

 

— 
=
Richard Shockey
Shockey Cons= ulting LLC
Chairman of the Board SIP Forum
richard= <at>shockey.us
Skype-Linkedin-Facebook rshockey101


_____________________= __________________________
cnit mailing list
cnit@ie= tf.org
https://www.ietf.org/mailman/listinfo/cnit



 --B_3515419866_229140-- From nobody Wed May 27 14:32:09 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 CDC951AC419 for ; Wed, 27 May 2015 14:32:07 -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=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 4HzGrJYi6Wi2 for ; Wed, 27 May 2015 14:32:02 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 841871AC40C for ; Wed, 27 May 2015 14:32:02 -0700 (PDT) Received: (qmail 12734 invoked by uid 0); 27 May 2015 21:31:57 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy4.mail.unifiedlayer.com with SMTP; 27 May 2015 21:31:57 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw2 with id Z94J1q00z1MNPNq0194MFG; Wed, 27 May 2015 15:04:22 -0600 X-Authority-Analysis: v=2.1 cv=efyuId0H c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=h1PgugrvaO0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=doUQZJtgAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=5b3Chl7SFygC0E7W7ScA:9 a=76bxv8w_EVnjo5YY:21 a=NH4lH-OsDN-jwm8s:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=OtSP2khXrCftyCH1UqcA:9 a=ylOOC2o1ixwJrnnt:21 a=jDV6mGxcPVLnZbbq:21 a=qXZODu3-bno3ut3S: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:To:From:Subject:Date; bh=Pw54Ht9mVdTlLu9l+4chnM96CdkozxIzEtf3Jms9eKM=; b=l64UdLLBE8kiHx1bHkBCHtVMftq7xitAhiYLzd4fVvjWep/O/s4EsQ6UBJVXu12hCmRyiqfsX67sRFU3TibLnH5DDXbroTOW5ufGS2SScs/rZWJNZ3CnCbZTlAHwwxGh; Received: from [108.56.131.201] (port=53240 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1YxicD-0007t1-N1; Wed, 27 May 2015 15:11:54 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Wed, 27 May 2015 17:11:46 -0400 From: Richard Shockey To: Mary Barnes , , , Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3515591513_968782" 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] 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: Wed, 27 May 2015 21:32:08 -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_3515591513_968782 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable FYI The usual suspects are on the warpath. They have friends in Ottawa an= d London. https://www.fcc.gov/blog/another-win-consumers =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 From: Mary Barnes Date: Friday, May 22, 2015 at 12:58 PM To: Richard Shockey Subject: Re: [cnit] CNIT Charter bashing.. Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the data object and headers without having defined the trust model. However, I think it's important that we're clear that we anticipate getting the proposed mechanism defined early and then hammer out the trust model. We could just do two milestones which is what Martini did: 1) Problem Statemen= t and Requirements and 2) Solution. The charter provides the detailed deliverables in the body earlier and I'm not sure that we would want things in separate documents UNLESS we think those mechanisms could be used for other things. But, I don't think so - I think the trust model has to be ingrained with those. Let me know your thoughts. Regards, Mary. On Fri, May 22, 2015 at 11:11 AM, Mary Barnes wrote: > Just FYI, I'm working on updates to this charter and will ship to you sho= rtly > for review. We can then repost on CNIT/DISPATCH and see if we can get th= is > wrapped up. I will separately ping Ben and let him know that this ought = to be > ready for him to send to the IESG soon and stress the importance of doing= this > work in the IETF and the careful selection of chairs. >=20 > Regards, > Mary. >=20 > On Mon, Mar 30, 2015 at 10:03 AM, Richard Shockey wr= ote: >>=20 >> 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, >>=20 >> A. Refine and or further define the problem we are trying to solve. >>=20 >> B. Include into the requirements the Trust Validation concept. I presum= e >> Brian is willing to help edit text on that. >>=20 >> I do have a issue for the AD=B9s. I really want to know up front if we hav= e to >> define a new header here. >>=20 >> I would like to know in advance the level of torture we are going to hav= e to >> deal with. >>=20 >>=20 >> ************ >> 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.16= 4 >> 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 netw= ork >> 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 altere= d in >> transit creating a variety of malicious abuses similar to the ones ident= ified >> 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 th= e >> called party make a more reasoned and informed judgment on whether to ac= cept >> the INVITE or not. >> =20 >> The working group will not invalidate any existing SIP mechanism for >> anonymous calling. >> =20 >> The working group will not define registration, provisioning or data que= ry >> 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 an= d >> National Regulatory Authorities as needed. >> =20 >> The working group will deliver the flowing. >> =20 >> =B7 A problem statement and requirements detailing the current deploym= ent >> environment and situations that motivate work on Calling Name Identity T= rust. >>=20 >> =B7 Define either a new SIP header or document a repurpose of an SIP >> existing header for Calling Name Identify Trust data >>=20 >> =B7 Define a data model for the Calling Name Identity Trust object (s) >> which may include various forms of multimedia data. >>=20 >> =B7 Define a Trust Mechanism for CNIT data. (Brian text?) >>=20 >> =B7 Deliver an analysis of privacy implications of the proposed Callin= g >> Name Identity Trust mechanism. >>=20 >> =20 >> =20 >> Milestones: >> =20 >> January 2016 : Problem Statement and Requirements for Calling Name Ident= ity >> Trust >> =20 >> April 2016 : Data Objects and SIP headers for Calling Name Identity Trus= t >> =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 >>=20 >>=20 >> _______________________________________________ >> cnit mailing list >> cnit@ietf.org >> https://www.ietf.org/mailman/listinfo/cnit >>=20 >=20 --B_3515591513_968782 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

FYI =  The usual suspects are on the warpath.  They have friends in Otta= wa and London.

https://www.fcc.gov/blog/another-win-consumers



— 
<= div>Richard Shockey
Shockey Consulting LLC
Chairman of t= he Board SIP Forum
www.shockey.us
www.sipforum.org
=
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey1= 01
PSTN +1 703-593-2683


From: Mary Barnes <mary.ietf.barnes@gmail.com>
<= span style=3D"font-weight:bold">Date: Friday, May 22, 2015 at 12:58 PM=
To: Richard Shockey <richard@shockey.us>
Subject: Re: [cnit] CNIT Charter bashing..

Attached is what I have at this point. Really, the= only thing I'm struggling with is the milestones as I don't think we can re= quest publication of the data object and headers without having defined the = trust model.  However, I think it's important that we're clear that we = anticipate getting the proposed mechanism defined early and then hammer out = the trust model.  We could just do two milestones which is what Martini= did: 1) Problem Statement and Requirements and 2) Solution.  The chart= er provides the detailed deliverables in the body earlier and I'm not sure t= hat we would want things in separate documents UNLESS we think those mechani= sms could be used for other things. But, I don't think so - I think the trus= t model has to be ingrained with those.   

Let = me know your thoughts.

Regards,
Mary.
=

On Fri, Ma= y 22, 2015 at 11:11 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Just FYI, I'm worki= ng on updates to this charter and will ship to you shortly for review. = We can then repost on CNIT/DISPATCH and see if we can get this wrapped up.&= nbsp; I will separately ping Ben and let him know that this ought to be read= y for him to send to the IESG soon and stress the importance of doing this w= ork in the IETF and the careful selection of chairs.

Rega= rds,
Mary.

On Mon, Mar 30, 2015 at 10:03 AM, Richard Sho= ckey <richard@shockey.us> wrote:

My runn= ing 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 serve= s me,

A. Refine and or further define the problem w= e are trying to solve.

B. Include into the requirem= ents the Trust Validation concept.  I presume Brian is willing to help = edit text on that.

I do have a issue for the ADR= 17;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 tortu= re we are going to have to deal with.


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

CNIT Charter [Calling Name Identity= Trust]

 

WG Chairs TBD:

&= nbsp;

Calling Name Delivery [CNAM] is current= ly 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 Recommendatio= n 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 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.<= u>

 

= 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 C= NIT 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 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 w= ill not invalidate any existing SIP mechanism for anonymous calling. 

 

The working group will not d= efine registration, provisioning or data query response mechanisms for the creation and storage of the CNIT = data object(s) .

 

<= p class=3D"MsoNormal">The working group will, to the best of its ability, reus= e existing IETF protocols.

 <= /p>

Full Internationalization of the Calling Name Identi= ty Trust data object(s) is a requirement.

<= /u> 

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 wo= rking group will coordinate with National Numbering Authorities and National Regulatory Authorities as needed.

 

The worki= ng 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.<= u>

 

=  

Milestones:

 

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

 

April  2016 : Data Objects and SIP headers for Calling Name Identity Trust<= u>

 

= November 2016 :  Trust Mechanism for Calling Name Identity Trust

 

 

 <= /u>

 

— 
=
Richard Shockey
Shockey Cons= ulting LLC
Chairman of the Board SIP Forum
richard= <at>shockey.us
Skype-Linkedin-Facebook rshockey101


_____________________= __________________________
cnit mailing list
cnit@ie= tf.org
https://www.ietf.org/mailman/listinfo/cnit



--B_3515591513_968782-- From nobody Wed May 27 19:12:06 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 516C01A892E for ; Wed, 27 May 2015 19:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.689 X-Spam-Level: * X-Spam-Status: No, score=1.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, 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 HLimFX-eMWz3 for ; Wed, 27 May 2015 19:12:04 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085D41A891E for ; Wed, 27 May 2015 19:12:04 -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=5wI0kq0q9ynw170ADQw7a/ot5MYJbp6SEuccdJq5t6I=; b=cD2gj6u6bSk//2X6hz7Z2xmX8G/Av74+ymxNu53q5m1aBZJ/ChCfDASZesB8VYNGG/m9742tc6VZhhpbFuHH7SiAxqzyJ2wRFRlsA5b9FxzxgRzAWnpRhLDSGbhKrdI3gnNDe1RVjNfgcPAeJaTAqLI+yhkB4f0ZSczNcEiDnVY=; Received: from [70.166.72.189] (port=59508 helo=[10.48.4.81]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.82) (envelope-from ) id 1YxnIe-0007v7-HN for cnit@ietf.org; Wed, 27 May 2015 19:12:03 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_7CC75EC6-3A96-44C3-87C3-6AFEC4F26DD7"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5b6 From: Eric Burger In-Reply-To: Date: Wed, 27 May 2015 22:11:58 -0400 Message-Id: References: To: cnit@ietf.org X-Mailer: Apple Mail (2.2098) 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] 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: Thu, 28 May 2015 02:12:05 -0000 --Apple-Mail=_7CC75EC6-3A96-44C3-87C3-6AFEC4F26DD7 Content-Type: multipart/alternative; boundary="Apple-Mail=_09B10E18-8660-4E85-93FC-B4D259C1E697" --Apple-Mail=_09B10E18-8660-4E85-93FC-B4D259C1E697 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 25, 2015, at 5:31 PM, Richard Shockey wrote: >=20 > From: Mary Barnes > > Date: Friday, May 22, 2015 at 12:58 PM > Attached is what I have at this point. Really, the only thing I'm = struggling with is the milestones as I don't think we can request = publication of the data object and headers without having defined the = trust model. >=20 >=20 > RS> Mary I=92m not sure about that statement. I can certainly = anticipate several deployment models where the trust mechanism (aka = signing) does not need to be formally integrated in the solution = especially those where the exchange of data is more bi-lateral and the = trust mechanism is at lower layers of the stack than the signaling. My = initial concern is what is the header and what is the data object(s) = carried in the header. How the CNIT data is created should not be our = concern. I do not buy it. If there are private agreements between service = providers, they have private agreements. They can do whatever they want. Last I looked, this is the Internet Engineering Task Force. Assume = untrusted transport across the wide open Internet, and trust no endpoint = that cannot cryptographically prove who they are. If it happens two = service providers exchange CNIT data over a single, yellow cable, then = it is a benefit that no state-sponsored security service can listen in = on the cable. I do not want to take three years to build a protocol and two more years = after that for products to be available just to have a system that only = works in walled gardens. I do not want to be the person that has to = explain to the media why Calling Name Delivery is just as broken as it = always was and it will be another five years before the world sees a = real solution. Let us get this right the first time. [snip] --Apple-Mail=_09B10E18-8660-4E85-93FC-B4D259C1E697 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On May 25, 2015, at 5:31 PM, Richard Shockey <richard@shockey.us> = wrote:

From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Friday, May 22, 2015 = at 12:58 PM
Attached is = what I have at this point. Really, the only thing I'm struggling with is = the milestones as I don't think we can request publication of the data = object and headers without having defined the trust = model. 


RS> Mary I=92m not = sure about that statement. I can certainly anticipate several deployment = models where the trust mechanism (aka signing) does not need to be = formally integrated in the solution especially those where the exchange = of data is more bi-lateral and the trust mechanism is at lower layers of = the stack than the signaling. My initial concern  is what is the = header and what is the data object(s) carried in the header. How the = CNIT data is created should not be our = concern.

I do = not buy it. If there are private agreements between service providers, = they have private agreements. They can do whatever they want.

Last I looked, this is = the Internet Engineering Task Force. Assume = untrusted transport across the wide open Internet, and trust no endpoint = that cannot cryptographically prove who they are. If it happens two = service providers exchange CNIT data over a single, yellow cable, then = it is a benefit that no state-sponsored security service can listen in = on the cable.

I = do not want to take three years to build a protocol and two more years = after that for products to be available just to have a system that only = works in walled gardens. I do not want to be the person that has to = explain to the media why Calling Name Delivery is just as broken as it = always was and it will be another five years before the world sees a = real solution.

Let us get this right the first time.
[snip]
= --Apple-Mail=_09B10E18-8660-4E85-93FC-B4D259C1E697-- --Apple-Mail=_7CC75EC6-3A96-44C3-87C3-6AFEC4F26DD7 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 iQIcBAEBCAAGBQJVZnluAAoJEDY/T2tCIPW3aZgP/0e7gjIpq9aB6KFK/a7Ed8mH JvgICxvdoEVaLlWFELb/l1Db555N9wUAWhqp/c2sGbFFPMmrPsj3ROAFBhzw+x82 0Wzr67cuXpQZNyiSNNsmaIs7IHuIlro5Nnxjwzgwq3XnRv67fQ0dqWrXOLpNVP0A 3Jzl0Zp06+zIU9lPOpjdK1oDCyA+MtS3C9oVZDtD4XRIAc1CmbTni8VCuobpO17K UFLfINNvmnyu+MfiJ1ubc91StV6/Ff68P+pC5jhZWXGKeaPS+TT1sLNp7HUNrIk/ gyBmTjNSgd26Mme7fB74Yzqg3gYzjWiGEgjKbf0e3ltdjqu4CIx66ELydTkMx9HO dR4v1DtqxszSmJRAoqlYFBNcYEubzC7w3koe9QbId7+ayvQzOqY9BfZLp1mQHomG RHfdSj6q9SI6kQcDZdAcCJ7OkgHWCit5CRwZwaAeDI0+iSObp3yMevL8MTWKTPv9 5zyxPd+oEOcAfvTq6ZxqXy6g+FiDqpl4wt041JO0rFIyCMMtU4IWumWfpRzywfN2 2p9Uqx5UkfGMj26W5/ccb3HqEaU3SJ9c7KrSpKoLCLONZ161zP5dDLripXNs8cnJ 9JCwuN8VwYV/hvqEJcU0mu7dSUi2N+1H664BjAMOoElHb9jbUUNGlG5Y7SBKEUC1 4vcgK0ipJfYdGit4iv+K =U3Lu -----END PGP SIGNATURE----- --Apple-Mail=_7CC75EC6-3A96-44C3-87C3-6AFEC4F26DD7-- From nobody Thu May 28 11:15:54 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 EFBA81A8928 for ; Thu, 28 May 2015 11:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.805 X-Spam-Level: * X-Spam-Status: No, score=1.805 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, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 8G_uNHyGf7Hw for ; Thu, 28 May 2015 11:15:50 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 4CD6B1A86F2 for ; Thu, 28 May 2015 11:15:50 -0700 (PDT) Received: (qmail 7578 invoked by uid 0); 28 May 2015 18:15:45 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy2.mail.unifiedlayer.com with SMTP; 28 May 2015 18:15:45 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id ZVlH1q00J1MNPNq01VlLF3; Thu, 28 May 2015 11:45:24 -0600 X-Authority-Analysis: v=2.1 cv=Zox+dbLG c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=j1VUBDpLDLYA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=h1PgugrvaO0A:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=bfLuiRfvAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=eT9KCcUOu21CDIZASjUA:9 a=g7X-79KplOj5KHfx:21 a=Pi8Fb3-QMzlXoJ1Z:21 a=wPNLvfGTeEIA:10 a=imQsMY7uihzKSOHQ9r4A:9 a=f1gIlhYE0eapzYi4:21 a=LS_9148_J_8FuNrv:21 a=7s1D24Eg_kb6g8zM: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:To:From:Subject:Date; bh=SE7xuBjmja0mQXecmZmZXDSYWD4auWTitWBySXOJwxM=; b=NlONz2rFJeov1gp/M38n0oEOu7hHlY7fpVA1TuFfbiOoddXk9TUfqju2MRX6NEioka21FN5HxbBfErYjRDU1J6TSXGJ15A5LuWJu7KOmUwd2kWpbAcLIAJ2WHCwSqhT/; Received: from [108.56.131.201] (port=52156 helo=[192.168.1.12]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Yy21q-0002lx-4M; Thu, 28 May 2015 11:55:38 -0600 User-Agent: Microsoft-MacOutlook/14.5.1.150515 Date: Thu, 28 May 2015 13:55:33 -0400 From: Richard Shockey To: Eric Burger , Message-ID: Thread-Topic: [cnit] CNIT Charter bashing.. References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3515666138_156310" 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] 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: Thu, 28 May 2015 18:15:53 -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_3515666138_156310 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable A fair argument but I don=B9t want to spend 5 years waiting for a series of normative dependencies on the trust model before actually understanding wha= t headers can/should be used here. Its much too difficult to get things done in the IETF as it is. I=B9d much prefer building from success starting with the definition of the data objec= t then ..then folding that into a trust model and frankly given what we have seen in STIR I=B9m not sure your argument holds up. Again the MARTINI model. Didn=B9t you recently say something about =B3perfection is the enemy of the good=B2 :-)=20 From: Eric Burger Date: Wednesday, May 27, 2015 at 10:11 PM To: Subject: Re: [cnit] CNIT Charter bashing.. On May 25, 2015, at 5:31 PM, Richard Shockey wrote: >=20 > From: Mary Barnes > Date: Friday, May 22, 2015 at 12:58 PM > Attached is what I have at this point. Really, the only thing I'm struggl= ing > with is the milestones as I don't think we can request publication of the= data > object and headers without having defined the trust model. >=20 >=20 > RS> Mary I=B9m not sure about that statement. I can certainly anticipate se= veral > deployment models where the trust mechanism (aka signing) does not need t= o be > formally integrated in the solution especially those where the exchange o= f > data is more bi-lateral and the trust mechanism is at lower layers of the > stack than the signaling. My initial concern is what is the header and w= hat > is the data object(s) carried in the header. How the CNIT data is created > should not be our concern. I do not buy it. If there are private agreements between service providers, they have private agreements. They can do whatever they want. Last I looked, this is the Internet Engineering Task Force. Assume untruste= d transport across the wide open Internet, and trust no endpoint that cannot cryptographically prove who they are. If it happens two service providers exchange CNIT data over a single, yellow cable, then it is a benefit that n= o state-sponsored security service can listen in on the cable. I do not want to take three years to build a protocol and two more years after that for products to be available just to have a system that only works in walled gardens. I do not want to be the person that has to explain to the media why Calling Name Delivery is just as broken as it always was and it will be another five years before the world sees a real solution. Let us get this right the first time. [snip] _______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit --B_3515666138_156310 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

A fa= ir argument but I don’t want to spend 5 years waiting for a series of = normative dependencies on the trust model before actually understanding what= headers can/should be used here. 


<= div>Its much too difficult to get things done in the IETF as it is.   I= ’d much prefer building from success starting with the definition of t= he data object then ..then folding that into a trust model and frankly given= what we have seen in STIR I’m not sure your argument holds up. Again = the MARTINI model.

Didn’t you recently  = say something about “perfection is the enemy of the good”  = :-) 



From: Eric Burger <eburger@standardstrack.com>
Date: Wednesday, May 27, 2015 at 10:11 PM<= br>To: <cnit@ietf.org>
Subject: Re: [cnit] CNIT Charter bashing..

On May 25, 2015, at 5:31 PM, Richard Shockey <richard@shockey.us> wrote:

From: Mary Barnes <= mary.ietf.barnes@gmail.= com>
Date: Friday, May 22, 2015 at 12:58 PM
Attached is what I have at this point. Really, the only thing I'm strugglin= g with is the milestones as I don't think we can request publication of the = data object and headers without having defined the trust model. 
<= /span>


RS> Mary I’m not sure about that statement. I can certain= ly anticipate several deployment models where the trust mechanism (aka signi= ng) does not need to be formally integrated in the solution especially those= where the exchange of data is more bi-lateral and the trust mechanism is at= lower layers of the stack than the signaling. My initial concern  is w= hat is the header and what is the data object(s) carried in the header. How = the CNIT data is created should not be our concern.

I do not buy it. If there are private agreemen= ts between service providers, they have private agreements. They can do what= ever they want.

Last I looked,= this is the Internet Engineering Task Force. Assu= me untrusted transport across the wide open Internet, and trust no endpoint = that cannot cryptographically prove who they are. If it happens two service = providers exchange CNIT data over a single, yellow cable, then it is a benef= it that no state-sponsored security service can listen in on the cable.

I do not want to take three = years to build a protocol and two more years after that for products to be a= vailable just to have a system that only works in walled gardens. I do not w= ant to be the person that has to explain to the media why Calling Name Deliv= ery is just as broken as it always was and it will be another five years bef= ore the world sees a real solution.

Let us get this right the first time.
[snip]<= /div>
_______________________________________________ cnit mailing list cnit@ietf.org https://www.ietf.org/m= ailman/listinfo/cnit --B_3515666138_156310--