Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Richard Shockey <richard@shockey.us> Tue, 09 August 2016 20:07 UTC

Return-Path: <richard@shockey.us>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E460712D7FB for <stir@ietfa.amsl.com>; Tue, 9 Aug 2016 13:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us
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 yngt_ZqLq6UV for <stir@ietfa.amsl.com>; Tue, 9 Aug 2016 13:07:25 -0700 (PDT)
Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 9E89012D7EE for <stir@ietf.org>; Tue, 9 Aug 2016 13:07:25 -0700 (PDT)
Received: (qmail 25321 invoked by uid 0); 9 Aug 2016 20:07:25 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 9 Aug 2016 20:07:25 -0000
Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id V82N1t00b1MNPNq0182RHa; Tue, 09 Aug 2016 14:02:25 -0600
X-Authority-Analysis: v=2.1 cv=LOD1Hvm9 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=8WrITzYgnNwA:10 a=etTHQkYnwnYA:10 a=7z1cN_iqozsA:10 a=48vgC7mUAAAA:8 a=b8OvNEjoAAAA:8 a=k7Ga1wGzAAAA:8 a=Q0f3NKQWUI96QroxOPcA:9 a=bEMFIiwXZkFhgkXT:21 a=uDCuZ7v6CasGO0pa:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=xfJ8-ueq0pyqlCF7aVox:22 a=ijMaxGghyylP-n2pFjDB:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date; bh=eMHREqPpWv6l1jXI0ARtDnhGFTS6gHXJHF3aPplX4Kg=; b=XtoxK3I6PBD2HOVGUxahdvCg25 pETyQyx20uPxildT2QsI+bl1sqfKiwy9U/Ufo5T4/kH9xTmj9JwjU7qg84tJnaDQhVD0OuJj4kUk2 Nbn9D6fWiJDapV2OcEPylrovX;
Received: from pool-100-36-40-228.washdc.fios.verizon.net ([100.36.40.228]:53865 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from <richard@shockey.us>) id 1bXDEE-0004Fd-PH; Tue, 09 Aug 2016 14:02:22 -0600
User-Agent: Microsoft-MacOutlook/f.18.0.160709
Date: Tue, 09 Aug 2016 16:02:20 -0400
From: Richard Shockey <richard@shockey.us>
To: dcrocker@bbiw.net, "stir@ietf.org" <stir@ietf.org>
Message-ID: <CE4A6DFE-54A3-482C-A4D9-8CBDD6BC6E25@shockey.us>
Thread-Topic: [stir] Review of: draft-ietf-stir-rfc4474bis-10
References: <c3a85ffc-8340-ac54-4d8e-21a16fefd032@dcrocker.net> <4B1956260CD29F4A9622F00322FE053101285D016E32@BOBO1A.bobotek.net> <D3CF2934.1A6EE6%jon.peterson@neustar.biz> <1dbc154e-1ffc-689a-6f4f-45321e1149f6@dcrocker.net>
In-Reply-To: <1dbc154e-1ffc-689a-6f4f-45321e1149f6@dcrocker.net>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 100.36.40.228 authed with richard+shockey.us}
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box462.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - shockey.us
X-Source-IP: 100.36.40.228
X-Exim-ID: 1bXDEE-0004Fd-PH
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-36-40-228.washdc.fios.verizon.net ([192.168.1.152]) [100.36.40.228]:53865
X-Source-Auth: richard+shockey.us
X-Email-Count: 0
X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/eco4TaHXdx89D8_OK-_MqfnznS0>
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Aug 2016 20:07:28 -0000

Well let me take this opportunity to totally reject Dave’s comments and the implication that we have not followed proper IETF process and procedures.

To make myself clear.

One, I support the continuing last call on these documents. I believe that these documents and the underlying protocols described are “fit for purpose” and in fact provide a valuable solution the problems described in the charter.  In addition, it is manifestly self-evident that the underlying JWT based passport structure is a valuable tool to describe and validate other “claims” that may be relevant in the future.  Purportedly we develop tools around here and not single purpose constructs.  The 4474bis concept is a much more extensible and economically viable protocol than the other alternatives such as issuing a 509 for every TN on the planet. Not going to happen. The initial problem in SIP are claims surrounding E 164 caller ID.  That the authors envision validating claims using other real time communications naming constructs, like WEBRTC is all well and good and we certainly expect to see more documentation on that in the future.

Second. My issue with the documents, is overall text clarity and lack of implementable examples to enable the supplier community to establish commercially viable roadmaps based on the eventual requirements flowing out of the service provider community.  Where do you put the claims in the INVITE guys????  There are endless political policy issues that have to be resolved but they will not, nor will they ever be solved in the IETF.   If you hate Telephony SP’s fine, its really easy to demonize them.  Done all the time.  But to get this thing off the ground we have to start somewhere and that means the circle of trust has to begin with the circle of authority and the delegation model here in every know nation state is virtually the same. The authority over the numbering plan and the integrity of the numbering plan is a nation state issue.  

If these are your real concerns you are welcome to join some of us in DC, London, Ottawa and other pleasant HQ’s for NRA’s.  Write your congresscritter, MP whatever.  If you want to go see the FCC btw send me a private note. The staff on 12th street here in DC are very very nice people and are quite happy to take technically informed meetings.  I can even tell you how to file an ex parte record of the meeting etc. 

Third, Dave’s objections here are fundamental. He is rejecting the entire JWT construct in 4474bis that has been put forward.  It is almost inconceivable to me that at this late stage he is essentially asking us to issue a ‘full stop” and start over in favor of DKIM based construct or whatever.  That is unacceptable.  NO. NO WAY.  We have no ID or anything before us to compare the merits of a DKIM approach to the one the consensus of the WG has chosen to adopt.  Spitballs from the peanut gallery do not count.  Write a draft Dave.  

Now I’ll let you return to your regularly scheduled programming. 



On 8/9/16, 10:12 AM, "stir on behalf of Dave Crocker" <stir-bounces@ietf.org on behalf of dhc@dcrocker.net> wrote:

    On 8/9/2016 6:52 AM, Peterson, Jon wrote:
    > and I promise that Chris and I will go through and implement
    > them where appropriate.
    
    
    This is the nugget of the process problem I was anticipating and seeking 
    to resolve:
    
        This is a working group, not a cheerleading section for some 
    authors.  In the IETF work is supposed to reflect the understanding and 
    agreement of the working group.  The nature and extent of the problems 
    I'm seeing with these documents suggests a significant lack of that 
    shared effort.
    
        In some cases, a document really comes from and remains primarily 
    the souls of the authors and the wg simply provides a surrounding sanity 
    check.  That's fine, when the sanity check is meaningful.  But these 
    documents don't have that kind of history or nature.
    
        A process in which the authors take extensive comments and go into a 
    back room and decide on their own what to do with them is a deviation 
    from the pure IETF model.  It is supported as an IETF process efficiency 
    hack only when there is rock solid working group synchronicity with the 
    authors.  Based on the nature and extent of the problems I'm seeing with 
    these documents, that synchronicity is lacking.
    
    
    
    In sum:  The reviews I am doing are noting many and serious problems. 
    They need working group discussion, not back-room author filtering, with 
    selective public comments by the authors.
    
    
    
    d/
    
    -- 
    
       Dave Crocker
       Brandenburg InternetWorking
       bbiw.net
    
    _______________________________________________
    stir mailing list
    stir@ietf.org
    https://www.ietf.org/mailman/listinfo/stir