Re: [cnit] CNIT Charter bashing..

Brian Rosen <br@brianrosen.net> Tue, 02 June 2015 16:26 UTC

Return-Path: <br@brianrosen.net>
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 686B81AD379 for <cnit@ietfa.amsl.com>; Tue, 2 Jun 2015 09:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.079
X-Spam-Level:
X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 BsRC8VXeLXAP for <cnit@ietfa.amsl.com>; Tue, 2 Jun 2015 09:26:21 -0700 (PDT)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FF31A002D for <cnit@ietf.org>; Tue, 2 Jun 2015 09:26:20 -0700 (PDT)
Received: by qcej9 with SMTP id j9so18786477qce.1 for <cnit@ietf.org>; Tue, 02 Jun 2015 09:26:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=JiG6ngPhE/DadJJq0ZNhQ8e/doOYvqzTsmPdiWbvGI0=; b=R2hZgMCjdzqstA9PJEr3wSIJP3oGKFBS4/YqfE3iKeOjma+KxH5/LOHK4LmljBKxud XmK0IANMUoBl0DFJ7jZ0AfuKtvlPxi607OytocrqdNsH51S0Toq4KwCCW+1TqoyrOtC0 SwyLeZEP22Ww24rBpDOtTnW31xeriamXB75jILZpGQBf2N9zAvxPQEtJsTV53RpiJQD9 DnM34l+DWC6ztRnG/W6SBsFFIhfQfmdTsiSMi6ZAr9Y2yaqmUWVZRBo+hAsYyCa9ijFR tCS9ccdUuC4VwzY0j05bdLHBDYgkss1nth7xOOiqHYFpssA4K+2LPnJVPW/GvfssfIBD dSVQ==
X-Gm-Message-State: ALoCoQnq8ue8iGfCO9onGGSl76atYqx7ICPU2h2DeeKYYLVBcW3WH/w+NESPO1v3BWqR0rtBcIdJ
X-Received: by 10.140.16.173 with SMTP id 42mr30350501qgb.31.1433262379904; Tue, 02 Jun 2015 09:26:19 -0700 (PDT)
Received: from [10.33.192.46] (neustargw.va.neustar.com. [209.173.53.233]) by mx.google.com with ESMTPSA id j66sm7584159qgj.8.2015.06.02.09.26.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jun 2015 09:26:18 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B295D6BD-5133-4201-B548-7C7A7CC73DF6"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <D18CCD06.25EF7%richard@shockey.us>
Date: Tue, 02 Jun 2015 12:26:15 -0400
Message-Id: <DC70415A-A553-411C-B96F-D5FB59C36AD5@brianrosen.net>
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>
To: Richard Shockey <richard@shockey.us>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cnit/dien52YoAzzInVsaQEgYvzdV6bE>
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: Tue, 02 Jun 2015 16:26:23 -0000

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 <mailto:eburger@standardstrack.com>>
> Date: Wednesday, May 27, 2015 at 10:11 PM
> To: <cnit@ietf.org <mailto:cnit@ietf.org>>
> Subject: Re: [cnit] CNIT Charter bashing..
> 
> On May 25, 2015, at 5:31 PM, Richard Shockey <richard@shockey.us <mailto:richard@shockey.us>> wrote:
>> 
>> From: Mary Barnes <mary.ietf.barnes@gmail.com <mailto: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.org <mailto:cnit@ietf.org> https://www.ietf.org/mailman/listinfo/cnit <https://www.ietf.org/mailman/listinfo/cnit>_______________________________________________
> cnit mailing list
> cnit@ietf.org
> https://www.ietf.org/mailman/listinfo/cnit