Re: [cnit] CNIT Charter bashing..

Richard Shockey <richard@shockey.us> Thu, 11 June 2015 03:21 UTC

Return-Path: <richard@shockey.us>
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 58B201A8AD9 for <cnit@ietfa.amsl.com>; Wed, 10 Jun 2015 20:21:01 -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 eGu3oL8b160C for <cnit@ietfa.amsl.com>; Wed, 10 Jun 2015 20:20:57 -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 080CB1A8AD6 for <cnit@ietf.org>; Wed, 10 Jun 2015 20:20:57 -0700 (PDT)
Received: (qmail 22348 invoked by uid 0); 11 Jun 2015 03:20:53 -0000
Received: from unknown (HELO CMOut01) (10.0.90.82) by qproxy4.mail.unifiedlayer.com with SMTP; 11 Jun 2015 03:20:53 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id eqqR1q00S1MNPNq01qqUEz; Wed, 10 Jun 2015 20:50:32 -0600
X-Authority-Analysis: v=2.1 cv=GeGEw2nL 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=-h4zUWlAkX4A:10 a=XAFQembCKUMA:10 a=PeFO9FbFhS32YxYntvkA:9 a=dci_DRCyiIAA:10 a=CiRkrLRW1GAA:10 a=iycWLhIX580A:10 a=OTLVf7z5AAAA:8 a=HLLxP2VMAAAA:8 a=48vgC7mUAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=bfLuiRfvAAAA:8 a=pGLkceISAAAA:8 a=pTp3KH0DkuwnvPPZkXIA:9 a=7WpG-JsKzxAEaojT:21 a=NAd7dgEMnUAWhLWR:21 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 a=a5WBIJHMAqT_G6dV7MUA:9 a=ZEup93SSFD_LuiZP:21 a=aIjKl2gKz_7UQwyC:21 a=-enn1C7fokHk4SPf: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:CC:To:From:Subject:Date; bh=G826bO00Cnav65HfMEXa8NGgt8GSUv1UEQx7yFyRT+4=; b=nZX/pGc1Z1MhyyLNvGdx+1vEMTPl92QlauRvkLT9RCu0P3ZpzMcGQwME3eRyEOXTwxQAzbasXOF7K9ozglf8vf7p33bFPEd87bL2UcysmDiSgYpvWOphMA5IFtHayueT;
Received: from [108.56.131.149] (port=49992 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.84) (envelope-from <richard@shockey.us>) id 1Z2sjW-0007Lo-E2; Wed, 10 Jun 2015 21:00:46 -0600
User-Agent: Microsoft-MacOutlook/14.5.1.150515
Date: Wed, 10 Jun 2015 23:00:42 -0400
From: Richard Shockey <richard@shockey.us>
To: Brian Rosen <br@brianrosen.net>, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Message-ID: <D19E6FBB.26C5B%richard@shockey.us>
Thread-Topic: [cnit] CNIT Charter bashing..
References: <D13EDE15.22E45%richard@shockey.us> <CAHBDyN7KX9dPTHiuWGk-yqqkDt+LYqnDwY_pBWpnLdJFCMvPeg@mail.gmail.com> <CAHBDyN5KZpiA4bU_gvcB+Wk0Bv9AS0+bvU9OsCS3OpMDbUGchA@mail.gmail.com> <D1890314.25B94%richard@shockey.us> <D52BE1C0-20EA-40A0-A0CC-28197574E0BB@standardstrack.com> <D18CCD06.25EF7%richard@shockey.us> <DC70415A-A553-411C-B96F-D5FB59C36AD5@brianrosen.net> <D1935329.26322%richard@shockey.us>
In-Reply-To: <D1935329.26322%richard@shockey.us>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3516822046_2505314"
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.149 authed with richard+shockey.us}
Archived-At: <http://mailarchive.ietf.org/arch/msg/cnit/_QSvbiDqwIoq7xVlwwv4BsyK8PY>
Cc: cnit@ietf.org
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 <cnit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cnit>, <mailto:cnit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cnit/>
List-Post: <mailto:cnit@ietf.org>
List-Help: <mailto:cnit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cnit>, <mailto:cnit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2015 03:21:01 -0000


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 <richard@shockey.us>
Date:  Tuesday, June 2, 2015 at 12:35 PM
To:  Brian Rosen <br@brianrosen.net>
Cc:  <cnit@ietf.org>
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 +1 703-593-2683


From:  Brian Rosen <br@brianrosen.net>
Date:  Tuesday, June 2, 2015 at 12:26 PM
To:  Richard Shockey <richard@shockey.us>
Cc:  Eric Burger <eburger@standardstrack.com>, <cnit@ietf.org>
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 <richard@shockey.us> 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 <eburger@standardstrack.com>
> Date:  Wednesday, May 27, 2015 at 10:11 PM
> 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 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
> cnit@ietf.orghttps://www.ietf.org/mailman/listinfo/cnit
> _______________________________________________
> cnit mailing list
> cnit@ietf.org
> https://www.ietf.org/mailman/listinfo/cnit

_______________________________________________ cnit mailing list
cnit@ietf.org https://www.ietf.org/mailman/listinfo/cnit