Re: [woes] New WOES charter proposal

"Paul C. Bryan" <paul.bryan@forgerock.com> Mon, 25 July 2011 18:48 UTC

Return-Path: <paul.bryan@forgerock.com>
X-Original-To: woes@ietfa.amsl.com
Delivered-To: woes@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC1121F8C0B for <woes@ietfa.amsl.com>; Mon, 25 Jul 2011 11:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bVsKsu98OAe for <woes@ietfa.amsl.com>; Mon, 25 Jul 2011 11:48:28 -0700 (PDT)
Received: from eu1sys200aog119.obsmtp.com (eu1sys200aog119.obsmtp.com [207.126.144.147]) by ietfa.amsl.com (Postfix) with SMTP id 30D4821F8BDF for <woes@ietf.org>; Mon, 25 Jul 2011 11:48:23 -0700 (PDT)
Received: from mail-gy0-f169.google.com ([209.85.160.169]) (using TLSv1) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKTi26bUrqBXYuznsFylB0WwTjC2Pkh+Xb@postini.com; Mon, 25 Jul 2011 18:48:23 UTC
Received: by gyg13 with SMTP id 13so2420977gyg.28 for <woes@ietf.org>; Mon, 25 Jul 2011 11:48:12 -0700 (PDT)
Received: by 10.142.143.17 with SMTP id q17mr2116041wfd.261.1311619692472; Mon, 25 Jul 2011 11:48:12 -0700 (PDT)
Received: from [192.168.1.177] (S0106001346fbe4af.vf.shawcable.net [174.1.44.35]) by mx.google.com with ESMTPS id d14sm284142wfh.13.2011.07.25.11.48.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 11:48:11 -0700 (PDT)
From: "Paul C. Bryan" <paul.bryan@forgerock.com>
To: woes@ietf.org
In-Reply-To: <4E2DB3BF.5050006@dcrocker.net>
References: <B2ABF893-10E6-496A-8F63-FFA2C9C89541@vpnc.org> <0DE0E2DE-A2FC-40DF-978B-594658571658@vpnc.org> <B26C1EF377CB694EAB6BDDC8E624B6E723160841@CH1PRD0302MB115.namprd03.prod.outlook.com> <23656536-E4BA-41BE-AA61-A23654246826@gmx.net> <A42506AF-BE66-4308-AD7B-03B4323D87CE@vpnc.org> <4E1F6AAD24975D4BA5B168042967394348D3F7F1@TK5EX14MBXC201.redmond.corp.microsoft.com> <4E164455.9020309@cs.tcd.ie> <4E171C20.8000305@dcrocker.net> <4E1F557F.8030500@cs.tcd.ie> <4E20DA1E.1020201@bbiw.net> <4E20DD0B.2080106@cs.tcd.ie> <4E1F6AAD24975D4BA5B168042967394348D4C6D2@TK5EX14MBXC201.redmond.corp.microsoft.com> <428F491B-718F-4B5D-BF96-C82CE0777A53@bbn.com> <1311613198.28852.54.camel@dynamo> <4E2DA4D5.90309@mnt.se> <4E2DB3BF.5050006@dcrocker.net>
Content-Type: multipart/alternative; boundary="=-2T7hkwGEbXDhuW7kBgZz"
Date: Mon, 25 Jul 2011 11:48:22 -0700
Message-ID: <1311619702.28852.77.camel@dynamo>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Subject: Re: [woes] New WOES charter proposal
X-BeenThere: woes@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <woes.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/woes>, <mailto:woes-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/woes>
List-Post: <mailto:woes@ietf.org>
List-Help: <mailto:woes-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/woes>, <mailto:woes-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2011 18:48:30 -0000

On Mon, 2011-07-25 at 14:19 -0400, Dave CROCKER wrote:


> 1. There is considerably more than a bikeshedding difference between
> 
>     a) normative dependence on a protocol, where the new exercise is merely a 
> syntactic re-coding"
> 
> vs, for example
> 
>     b) "take the ideas from the existing work and use them as a basis for 
> writing a new protocol."


I have serious doubts that we should accept a) on its face as the
objective of this working group. I suggest that building the charter on
b) will not negate actually implementing a) if it turns out—after
productive discussion—that it makes sense to take such a direction.


> 2. There is a significant constituency in the current topic that are using 
> language that sounds very much like option a) above.
> 
> That is, I believe there is a meaningful split between an established security 
> community view for this topic, versus the views of the json-oriented folk.
> 
> What is perhaps missing is a clear and shared understanding of the exact uses 
> that are intended for the current work.


Chicken, meet egg; requirements, meet charter. As I see it, the
objective is to get a reasonably succinct—yet not too restrictive—
charter adopted such that analysis and discussion can begin in earnest.

> 
> For example "must be able to encode it in a URL" is a rather meaningful and 
> substantial constraint.


Should we be diving into such details, making them critical path items
to getting the charter in place? If so, I project a significant
deviation from the proposed roadmap, time-wise. I would prefer to avoid
creating extra burdens to completing the charter.

Paul