Re: [TLS] Setting Policy for Extensions
Nico Williams <nico@cryptonector.com> Thu, 28 July 2011 02:18 UTC
Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B326F11E8129 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 19:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.808
X-Spam-Level:
X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 qcEB9AKegOl3 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 19:18:31 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 37E1611E8118 for <tls@ietf.org>; Wed, 27 Jul 2011 19:18:31 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id B803421DE59 for <tls@ietf.org>; Wed, 27 Jul 2011 19:18:22 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nUiWZtjpDORG00uLVYa3P OspbMOY0y/kJWi2U03iO5ioxqa6Tzz9JsbBFTnbY8wpoZOdthPaj1lO0mUXWC+QL exBoKlHqsrFqSaQcyeTWwosWhtXx+gqGWKIHIiPfzkiVg20SqYJgR7YFjy6ECvXS ozazv4MGAN3T9JnK3wCtfQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=O7rOR/t1Z3sToUah1yQ3 h8aMtd4=; b=SoFtRX1hTr4ns/ogpSdfrdKSTsau9OnUjFJ/hDtpFooRyDSBttm1 9dOGzkM7wtqgN9aXFU1h52Oen6KhDrR3sRdLeBn2M8mZGEAub8vFaP94Y/f0QGBk /yll+UC944pX3cBTBN5JrjMOTr2EEoaGzyTo/CATmPc4kzqUbBXoo74=
Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 9B69E21DE58 for <tls@ietf.org>; Wed, 27 Jul 2011 19:18:22 -0700 (PDT)
Received: by pzk6 with SMTP id 6so3457923pzk.26 for <tls@ietf.org>; Wed, 27 Jul 2011 19:18:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.26.68 with SMTP id j4mr739447pbg.307.1311819502139; Wed, 27 Jul 2011 19:18:22 -0700 (PDT)
Received: by 10.68.48.74 with HTTP; Wed, 27 Jul 2011 19:18:22 -0700 (PDT)
Received: by 10.68.48.74 with HTTP; Wed, 27 Jul 2011 19:18:22 -0700 (PDT)
In-Reply-To: <CABcZeBPRXJ27LVRc3w5pyvi3wVqw=EHeKJt-SBoYHYLOeXwX6w@mail.gmail.com>
References: <CABcZeBPRXJ27LVRc3w5pyvi3wVqw=EHeKJt-SBoYHYLOeXwX6w@mail.gmail.com>
Date: Wed, 27 Jul 2011 21:18:22 -0500
Message-ID: <CAK3OfOjQetHhZsSrGMGnvRkxBV6HEeYrjoy3jdpuwL_HcdpeVA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="bcaec52155716f3ac004a917c775"
Cc: tls@ietf.org
Subject: Re: [TLS] Setting Policy for Extensions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 02:18:31 -0000
The TLS WG need not be around forever, so this WG-consensus-on-non-objectionability concept has at least that problem. Beyond that, do we have precedent for requiring that there be WG consensus that a proposal is not objectionable? (As opposed to WG consensus that the proposal should progress.) I would rather say that the IESG can require review in a then-appropriate WG (i.e., WG LC) in addition to IETF LC. Nico --
- [TLS] Setting Policy for Extensions Eric Rescorla
- Re: [TLS] Setting Policy for Extensions Nikos Mavrogiannopoulos
- Re: [TLS] Setting Policy for Extensions Paul Wouters
- Re: [TLS] Setting Policy for Extensions Paul Hoffman
- Re: [TLS] Setting Policy for Extensions Nico Williams
- Re: [TLS] Setting Policy for Extensions Martin Rex
- Re: [TLS] Setting Policy for Extensions Paul Hoffman
- Re: [TLS] Setting Policy for Extensions Eric Rescorla
- Re: [TLS] Setting Policy for Extensions Eric Rescorla
- Re: [TLS] Setting Policy for Extensions Martin Rex
- Re: [TLS] Setting Policy for Extensions Nico Williams
- Re: [TLS] Setting Policy for Extensions t.petch