Re: [cnit] CNIT Charter bashing..

[Richard Shockey <[e-mail]>]

Thank you that is very helpful. I¹m assuming its network delivered based on
information derived from the calling party billing data.

My other running assumption has been that some form Advanced Calling Name
Delivery is a precondition for advanced realtime communications service
delivery.. Aka ubiquitous video calling.   Would that be a reasonable
presumption?

From:  <[e-mail]>
Date:  Thursday, June 11, 2015 at 9:02 AM
To:  "[e-mail]" <[e-mail]>
Subject:  Re: [cnit] CNIT Charter bashing..

Richard,

For a number of years, there has been an optional caller name dispay feature
attached to some of the telephone services in France, but indeed nothing
like the standalone CNAM service concept that underpins the discussions on
this list.

Regards,

Philippe Fouquart
Orange Labs Networks
[phone]


-------- Message d'origine --------
De : Richard Shockey
Date :11/06/2015 05:21 (GMT+01:00)
À : Brian Rosen , Henning Schulzrinne
Cc : [e-mail] 
Objet : Re: [cnit] CNIT Charter bashing..



Here is what I want to know now.

Before we start to process this concept I want to know how relevant the
existing CNAM service is deployed outside North America.

I¹m told by reliable sources that the CNAM service is not deployed anywhere
among the major telecom markets in Europe or Asia. Not Japan China or South
Korea UK Italy France and in fact it might actually be illegal under the
strict privacy regulations in Germany.

I don¹t know. 

That said our friends at Apple seem to understand there is a problem here. I
have tried to engage the most senior management at Google about who would be
responsible for defining how the VoLTE CUA could actually display an
advanced call display data and frankly no one knows.

http://www.businessinsider.com/apple-update-in-ios9-suggests-caller-id-2015-
6

There is a realistic question if this is simply a North American specific
problem why is this  a IETF issue. You might ask the same question of MODERN
but I frankly don¹t want to go there.




From: Richard Shockey <[e-mail]>
Date: Tuesday, June 2, 2015 at 12:35 PM
To: Brian Rosen <[e-mail]>
Cc: <[e-mail]>
Subject: Re: [cnit] CNIT Charter bashing..


Hopefully but I still haven¹t seen any response to my concern about
normative dependencies on STIR.

If we can define the object/headers first then I don¹t have a issue.

‹ 
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: Brian Rosen <[e-mail]>
Date: Tuesday, June 2, 2015 at 12:26 PM
To: Richard Shockey <[e-mail]>
Cc: Eric Burger <[e-mail]>, <[e-mail]>
Subject: Re: [cnit] CNIT Charter bashing..

Are we planning to submit a charter in the next couple of days, and then see
if we can get a slot at the next IETF?

Brian
> On May 28, 2015, at 1:55 PM, Richard Shockey <[e-mail]> wrote:
> 
> 
> A fair 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.
> 
> 
> 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 the 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 <[e-mail]>
> Date: Wednesday, May 27, 2015 at 10:11 PM
> To: <[e-mail]>
> Subject: Re: [cnit] CNIT Charter bashing..
> 
> On May 25, 2015, at 5:31 PM, Richard Shockey <[e-mail]> wrote:
>> 
>> From: Mary Barnes <[e-mail]>
>> 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¹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 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]
> _______________________________________________ cnit mailing list
> [e-mail]://www.ietf.org/mailman/listinfo/cnit
> _______________________________________________
> cnit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cnit

_______________________________________________ cnit mailing list
[e-mail] https://www.ietf.org/mailman/listinfo/cnit
____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________ cnit mailing list
[e-mail] https://www.ietf.org/mailman/listinfo/cnit