Re: [cnit] CNIT Charter bashing..

[Richard Shockey <[e-mail]>]

FYI  The usual suspects are on the warpath.  They have friends in Ottawa and
London.

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



‹ 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN [phone]


From:  Mary Barnes <[e-mail]>
Date:  Friday, May 22, 2015 at 12:58 PM
To:  Richard Shockey <[e-mail]>
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 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 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 <[e-mail]>
wrote:
> Just FYI, I'm working 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.  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.
> 
> Regards,
> Mary.
> 
> On Mon, Mar 30, 2015 at 10:03 AM, Richard Shockey <[e-mail]> wrote:
>> 
>> 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¹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]
>>  
>> 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 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.
>>  
>> 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(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 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, provisioning 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, 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 and other
>> appropriate SDO¹s 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.
>>  
>> ·     A problem statement and requirements detailing the current deployment
>> environment and situations that motivate work on Calling Name Identity Trust.
>> 
>> ·     Define either a new SIP header or document a repurpose of an SIP
>> existing header for Calling Name Identify Trust data
>> 
>> ·     Define a data model for the Calling Name Identity Trust object (s)
>> which may include various forms of multimedia data.
>> 
>> ·     Define a Trust Mechanism for CNIT data. (Brian text?)
>> 
>> ·     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 <http://www.shockey.us>
>> www.sipforum.org <http://www.sipforum.org>
>> richard<at>shockey.us <http://shockey.us>
>> Skype-Linkedin-Facebook rshockey101
>> PSTN [phone] <tel:%2B1%20703-593-2683>
>> 
>> 
>> _______________________________________________
>> cnit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cnit
>> 
>