Re: [abfab] charter take 3

Dave CROCKER <dhc@dcrocker.net> Fri, 13 August 2010 18:56 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: abfab@core3.amsl.com
Delivered-To: abfab@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2A33A6914 for <abfab@core3.amsl.com>; Fri, 13 Aug 2010 11:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.663
X-Spam-Level:
X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHA5iXD7CoQH for <abfab@core3.amsl.com>; Fri, 13 Aug 2010 11:56:23 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id E92103A68D5 for <abfab@ietf.org>; Fri, 13 Aug 2010 11:56:23 -0700 (PDT)
Received: from [192.168.1.147] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7DIutHl001818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 11:57:01 -0700
Message-ID: <4C65956F.3040601@dcrocker.net>
Date: Fri, 13 Aug 2010 11:56:47 -0700
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Leif Johansson <leifj@sunet.se>
References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se>
In-Reply-To: <4C65927B.8000204@sunet.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 13 Aug 2010 11:57:01 -0700 (PDT)
Cc: abfab@ietf.org
Subject: Re: [abfab] charter take 3
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Aug 2010 18:56:24 -0000

On 8/13/2010 11:44 AM, Leif Johansson wrote:
>> In this case, however, I think it defines a high barrier for replacing
>> the technical components and it hits the reader in the face with how
>> much effort it will take to climb the barrier.  So, I like it.
>
> I think you and Sam will have to slug it out on this topic. He wants to
> cut it. I'm iffy. You want to keep it but also cut it. Maybe somebody
> else has yet another approach :-)

The charter really needs to state fairly clearly what the boundaries of change 
are, within the charter.  It needs to state it forcefully enough to be useful 
when someone starts distracting the working group with calls for changes that 
really go beyond what the working group intends.  This is a question of clarity 
about what the working group intends and strong enough language in the charter 
to be used as an enforcement club.  I'd say that there is already plenty of 
demonstrated need for such a paragraph.

As for Sam vs. me, no.  Neither of us should matter that much.  That's what 
rough consensus is all about.


> <snip>
>
>>> The working group may not change EAP (beyond the development of EAP
>>> mechanisms), RADIUS or Diameter without establishing consensus with
>>> the appropriate community within the IETF.
>>>
>>> The working group will use the following documents as a starting
>>> point for its work:
>>>
>>> - - draft-howlett-eap-gss-00,
>>> - - draft-howlett-radius-saml-attr-00
>>> - - draft-hartman-gss-eap-naming-00
>>
>> I'm pretty sure these are more than "starting points". That's a pretty
>> vague term and I think you folks intend something more specific and that
>> it means significant constraints on the changes to these specification
>> that are considered permissible.
>
> They are (imho) starting-points within the constraints of the
> technology choices which have been outlined in the charter so I
> think it is appropriate to say "starting point" in this case and
> given that one has read the charter and the drafts I believe the
> meaning is clear:  that given the roles of SAML, EAP and AAA
> these three documents are starting points for each part of the
> solution.

starting points for discussion?  starting points for specification?  starting 
points for refinement?  but the actual choices can be anything?  whole new 
specifications will be acceptable?


>> These are the base specifications.  What are the criteria for making
>> changes to them?
>
> Normal IETF WG consensus, but we really can't keep repeating that.

What are the criteria that permits a working group chair to declare a topic out 
of scope?

Most wg chairs are nice folk who tend to let things go more astray than one 
would later have wished.  Clear and firm criteria in a charter make the wg 
chair's job much clearer about scope and therefore easier to enforce.  The 
alternative is constantly having to pool the wg for rough consensus about scope 
issue, after scope issue.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net