Re: [cnit] CNIT Charter bashing..

["Peterson, Jon" <[e-mail]>]

It's not clear to me that we need any STIR-like mechanisms to be in place
before embarking on CNIT. What I've basically written in to STIR is an
extension field that CNIT could use to hook into the signature. All it
would require is that CNIT create a specification (as currently written, a
Standards Track RFC) that designates what the field(s) that will be
signed, and then the necessary procedures and so on.

Fundamentally I agree that hooking CNIT into STIR will only provide part
of a solution. There are going to be cases when the entity that originates
(or signs) SIP signaling is not going to be the right party to attest to
the proper display name for a user.

Architecturally, what I'd probably prefer is to think about this work as
designing a small, but somewhat extensible block of information which
someone could sign. Small enough that it could fit in a SIP message, and
be signed there by hooking into the STIR extension field. But also
something that could be carried by an external protocol for those cases
when the STIR signer might not be the authority on the display name. Maybe
the STIR signer would fetch it via that external protocol, and then pass
along the signature of the authority from whom they acquired it, in
addition to signing it themselves. Or maybe the recipient would use the
external protocol if there is no STIR hook. If we build a system with
roughly those qualities, and focus more on the info block than on how it
gets transported necessarily, I think we'll do some valuable work.

Jon Peterson
Neustar, Inc.

On 6/15/15, 3:32 PM, "Richard Shockey" <[e-mail]> wrote:

>
>Tim Henning .. This is uniquely timely and important because the SIP Forum
>is at this moment attempting to revise its SIPConnect Recommendation for
>PBX / hosted to SSP interface where the data may be originated by the
>enterprise and it needs to be treated in some way by the NNI. (hopefully
>maybe not stripped if its seen in the FROM or P-AI)
>
>Its a complication but not insurmountable. It clearly shows we need to
>rethink the charter and look at some baby steps vs demanding that all the
>STIR like mechanisms be in place before there is progress.
>
>
>
>‹ 
>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]
>
>
>
>
>
>On 6/15/15, 6:11 PM, "Henning Schulzrinne" <[e-mail]>
>wrote:
>
>>Agreed that the terminating carrier can provide added value, e.g., by
>>linking to other information. You could imagine mapping numbers to BBB
>>information, or databases or registered charities, or Yelp... I am
>>somewhat surprised that this isn't happening already more broadly.
>>
>>________________________________________
>>From: Dwight, Timothy M (Tim) [[e-mail]]
>>Sent: Sunday, June 14, 2015 1:58 PM
>>To: Henning Schulzrinne
>>Cc: [e-mail]
>>Subject: RE: [cnit] CNIT Charter bashing..
>>
>>Henning,
>>
>>I'm not sure 'carrier B' would in the "in-band case" have no incentive to
>>use a 3rd party service.  It might be that the 3rd party service provides
>>additional information and/or is considered more trustworthy than whoever
>>provided the in-band information.  We can (and I hope will) change the
>>incentives.  I think it would be a reasonable objective to carry whatever
>>content is deemed "necessary" to serve the public, in-band.  If people
>>want to operate databases full of calling party's cat pictures, and
>>Carrier B wants to provide this to their customer (or allow their
>>customer to obtain it themselves, e.g., provide them a link to it) that's
>>all OK with me.
>>
>>I agree with you about the importance of being able to know
>>unambiguously, who inserted the information.
>>
>>Tim
>>
>>_______________________________________________
>>cnit mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/cnit
>
>
>_______________________________________________
>cnit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/cnit