Re: [sasl] SASL and KITTEN-WG Merger

Nicolas Williams <Nicolas.Williams@oracle.com> Mon, 10 May 2010 14:57 UTC

Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B783A6995; Mon, 10 May 2010 07:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.245
X-Spam-Level:
X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 vpzvmNEeVCtU; Mon, 10 May 2010 07:57:21 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 253863A6951; Mon, 10 May 2010 07:57:21 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AEv4mS012486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 14:57:05 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AEuxAC028383; Mon, 10 May 2010 14:57:02 GMT
Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 227879541273503417; Mon, 10 May 2010 07:56:57 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 07:56:56 -0700
Date: Mon, 10 May 2010 09:56:49 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Simon Josefsson <simon@josefsson.org>
Subject: Re: [sasl] SASL and KITTEN-WG Merger
Message-ID: <20100510145648.GO9429@oracle.com>
References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> <87ljbtumzm.fsf@mocca.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87ljbtumzm.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet13.oracle.com [148.87.113.125]
X-CT-RefId: str=0001.0A090208.4BE81EC2.0165:SCFMA4539811,ss=1,fgs=0
Cc: kitten@ietf.org, sasl@ietf.org, Eliot Lear <lear@cisco.com>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2010 14:57:22 -0000

On Sun, May 09, 2010 at 05:13:33PM +0200, Simon Josefsson wrote:
> Eliot Lear <lear@cisco.com> writes:
> > I find it hard to have this discussion without understanding what the
> > new charter would be.  Is there a pointer somewhere?  We had
> > discussions relating to our SAML/OpenID SASL drafts being handled by
> > the new group, but I don't know what would be in scope.
> 
> To me, the SAML/OpenID mechanisms are perhaps the most important work
> item for a new working group, so I would be disappointed if it is not
> mentioned in the charter.

I don't care if the work Eliot mentions goes in this WG or a separate
WG as long as the work gets done :)

To start, the proposal to merge these two WGs is fairly straightforward
since merging the two charters presents only one minor conflict and
since both the GSS-API and SASL have been converging to a large degree.
The one minor conflict is that KITTEN was not chartered to work on
mechanisms, but SASL did do work on mechanisms (SCRAM, MD5-DIGEST, ...).
I think that is easy to resolve: let the new WG work on mechanisms in
general, or else list the kinds of mechanisms that the new WG may work
on, or, if we think we don't need any new mechanisms, then don't allow
the new WG to work on any.

Nico
--