Re: [cnit] CNIT Charter bashing..

[Richard Shockey <[e-mail]>]

In line

On 6/12/15, 9:13 AM, "Henning Schulzrinne" <[e-mail]>
wrote:

>>From what I can tell, North American businesses see a fair amount of
>>value in this feature, as many people (due to robocalls) won't pick up
>>anonymous calls or calls from numbers they do not recognize. In
>>addition, this address book has to be created somehow. It's a whole lot
>>easier to auto-populate the name from the caller name information than
>>asking users to type in the name for the person that just called them.
>>After all, that's how typical email-derived address books work - people
>>don't type in that information.
>
>I suspect we'll see, as in the Apple announcement, various third-party
>kludges that go beyond the personal address book, where Google and Apple
>(and, with a year or two delay, Microsoft) try to use their own data, web
>page data and maybe crowd-sourced data to create a pseudo-CNAM, with a
>proprietary architecture and opaque data sources. This will work ok to
>the point where a business finds that their name is horribly mangled and
>then tries to determine how they can get it fixed by somebody they can't
>talk to.

RS> Amen ..


>
>That said, we're talking about a SIP feature (display name) that already
>exists and is, I assume, widely used for enterprise VoIP systems. Thus,
>my goal is modest: allow signed and extended versions of the display name.


RS> Well intra enterprise certainly.  There it tends to get pulled from
Active Directory but until we can get the NNI interface deployed its not
working at all for inter enterprise.  We are certainly looking at that for
Phase 2 of the NNI TF.

My goal is some what more modest for a first phase.  Certainly you want
signed extended versions of the display name but one should not create
artificial barriers to non signed data exchanges between service providers
where the security comes from the big yellow wire at Layer 1.  Plus I
still want a straight answer if this proposal is going to have a
requirement for a new SIP header and all the IETF ART pain and suffering
that goes with that. I want the AD¹s to make that demand ( if it is to be
imposed) explicit now.

> 
>
>I find it peculiar that carriers always say that they want to be more
>than bit pipes, but then find all kinds of reasons not to add value to
>their services. This obviously only applies to people and organizations
>not on this list :-)


 

>
>Henning
>
>
>________________________________________
>From: cnit [[e-mail]] on behalf of
>[e-mail] [[e-mail]]
>Sent: Friday, June 12, 2015 6:11 AM
>To: [e-mail]
>Subject: Re: [cnit] CNIT Charter bashing..
>
>As far as what the feature does, I think you are right. And after all,
>displaying a name is..., well just that really, displaying a name and the
>variations are mostly around whether the source is authoritative or to
>what extent.
>
>As to the misunderstanding relative to whether this is or isn't
>implemented, I know that this hasn't been massively successful as a
>feature and the need to replicate that beyond TDM isn't clear. It would
>seem that most people would consider at this stage that
>"matching-CLI-with-names-in-Contacts-and-displaying-the-CLI-or-anonymous-w
>hen-not-present" is just good enough. Displaying names was a challenge in
>environments and days when contact books weren't available and although
>from an engineering perspective, not having a single format to display
>may not be satisfactory or ideal for both CgP and CdP, it may actually be
>a de facto happy medium for their conflicting needs for
>privacy/information respectively.  Probably slightly off topic for this
>list.
>
>Philippe Fouquart
>Orange Labs Networks
>[phone]
>
>-----Message d'origine-----
>De : Henning Schulzrinne [mailto:[e-mail]]
>Envoyé : jeudi 11 juin 2015 20:05
>À : FOUQUART Philippe IMT/OLN; [e-mail]
>Objet : RE: [cnit] CNIT Charter bashing..
>
>>From my reading, the function seems similar to caller name delivery,
>>even if the mechanism is not a CNAM database.
>
>According to Google Translate:
>
>Presented coordinates are those listed in the directories. These are
>necessarily the coordinates of the line holder that are displayed. The
>name of the calling line holder is displayed only if the call is
>presented on a compatible device.
>
>________________________________
>From: cnit [[e-mail]] on behalf of
>[e-mail] [[e-mail]]
>Sent: Thursday, June 11, 2015 2:00 PM
>To: DOLLY, MARTIN C; Richard Shockey; [e-mail]
>Subject: Re: [cnit] CNIT Charter bashing..
>
>The feature I was referring to
>http://assistance.orange.fr/presentation-du-nom-de-la-ligne-fixe-utilisati
>on-4010.php
>(In French, with my apologies)
>As I said, it isn't a CNAM service.
>
>Regards,
>
>Philippe Fouquart
>Orange Labs Networks
>[phone]
>
>
>-------- Message d'origine --------
>De : "DOLLY, MARTIN C"
>Date :11/06/2015 18:18 (GMT+01:00)
>À : Richard Shockey , FOUQUART Philippe IMT/OLN , [e-mail] Objet :
>RE: [cnit] CNIT Charter bashing..
>
>I got a different answer from the Orange/FT folks at the CT WG
>meetings...so please check and clarify..
>
>From: cnit [mailto:[e-mail]] On Behalf Of Richard Shockey
>Sent: Thursday, June 11, 2015 11:46 AM
>To: [e-mail]; [e-mail]
>Subject: Re: [cnit] CNIT Charter bashing..
>
>
>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]<mailto:[e-mail]>>
>Date: Thursday, June 11, 2015 at 9:02 AM
>To: "[e-mail]<mailto:[e-mail]>"
><[e-mail]<mailto:[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]<mailto:[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-201
>5-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]<mailto:[e-mail]>>
>Date: Tuesday, June 2, 2015 at 12:35 PM
>To: Brian Rosen <[e-mail]<mailto:[e-mail]>>
>Cc: <[e-mail]<mailto:[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<http://www.shockey.us>
>www.sipforum.org<http://www.sipforum.org>
>richard<at>shockey.us
>Skype-Linkedin-Facebook rshockey101
>PSTN [phone]
>
>
>From: Brian Rosen <[e-mail]<mailto:[e-mail]>>
>Date: Tuesday, June 2, 2015 at 12:26 PM
>To: Richard Shockey <[e-mail]<mailto:[e-mail]>>
>Cc: Eric Burger 
><[e-mail]<mailto:[e-mail]>>,
><[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
>Date: Wednesday, May 27, 2015 at 10:11 PM
>To: <[e-mail]<mailto:[e-mail]>>
>Subject: Re: [cnit] CNIT Charter bashing..
>
>On May 25, 2015, at 5:31 PM, Richard Shockey
><[e-mail]<mailto:[e-mail]>> wrote:
>
>From: Mary Barnes 
><[e-mail]<mailto:[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]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/c
>nit
>_______________________________________________
>cnit mailing list
>[e-mail]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/cnit
>
>_______________________________________________ cnit mailing list
>[e-mail]<mailto:[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]<mailto:[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.
>
>
>__________________________________________________________________________
>_______________________________________________
>
>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
>
>
>_______________________________________________
>cnit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/cnit