Re: [websec] handling STS header field extendability
Tobias Gondrom <tobias.gondrom@gondrom.org> Sun, 19 August 2012 08:23 UTC
Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84DE21F848F for <websec@ietfa.amsl.com>; Sun, 19 Aug 2012 01:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.667
X-Spam-Level:
X-Spam-Status: No, score=-96.667 tagged_above=-999 required=5 tests=[AWL=-1.305, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
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 tTACsBW-hUwN for <websec@ietfa.amsl.com>; Sun, 19 Aug 2012 01:23:11 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id A414D21F848A for <websec@ietf.org>; Sun, 19 Aug 2012 01:23:10 -0700 (PDT)
Received: (qmail 17429 invoked from network); 19 Aug 2012 10:23:06 +0200
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.65?) (94.194.102.93) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2012 10:23:05 +0200
Message-ID: <5030A269.7070901@gondrom.org>
Date: Sun, 19 Aug 2012 09:23:05 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: barryleiba@computer.org
References: <502ECBD3.6050902@KingsMountain.com> <B80C8460-9C37-4BFC-B4F0-D757E9FB3290@checkpoint.com> <502F7214.6010102@gondrom.org> <CAC4RtVCypaYFQmV-_Mp7f3bqPqo=4mv2LY5Cs0UiNGmmkPHH=g@mail.gmail.com>
In-Reply-To: <CAC4RtVCypaYFQmV-_Mp7f3bqPqo=4mv2LY5Cs0UiNGmmkPHH=g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: websec@ietf.org
Subject: Re: [websec] handling STS header field extendability
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Aug 2012 08:23:12 -0000
On 19/08/12 01:56, Barry Leiba wrote: >>>> I'd also noted that we need to decide on a IANA policy to declare. >>> Do we need to do this? Assuming the proposed resolution achieves >>> consensus (and there have been no nays yet), we're not setting up a >>> registry. I don't think we get to set a policy for a registry we're not >>> setting up. >> <hat="WG chair"> >> AFAIK from an administrative perspective, Yoav is right. >> In general we set the IANA policy for registry updates at creation of the >> registry. So no need to do it here without the registry (assuming we don't >> create an IANA registry). > The point in this case is that this is a response to Ben's GenART > review, which suggested that we at least nail down the registration > policy at this point, lest someone come along later with an extension > and create the registry with, say, an FCFS policy (probably too > light), or perhaps with a Standards Action policy (arguably too > heavy). > > The WG can validly disagree with Ben's review, and unless Russ (or > another AD) strongly agrees and uses it as a DISCUSS point, we're > done. Even in that case, the WG can still argue against it and try to > convince the AD that it's OK not to do this... and, as Tobias point > out, we usually don't. Thanks for the clarification. > > So maybe we should modify what Jeff said, thus: > >>>> I'd also noted that we need to decide on a IANA policy to declare. > "We need to decide on an IANA policy *or* explicitly decide that we > don't want to choose that now, and leave it to whoever creates the > registry later." > > Apparently, we have at least two votes for the latter, from Yoav and Tobias. > > Barry (with AD hat off, but handily tucked at the ready under his arm) <hat="individual"> Yes, I would vote not to specify an IANA policy for a registry we don't define here. I would be in favor of leaving that to when or if we create such a registry later. Though I don't have a strong opinion on this. Tobias
- Re: [websec] handling STS header field extendabil… =JeffH
- Re: [websec] handling STS header field extendabil… Alexey Melnikov
- [websec] handling STS header field extendability =JeffH
- Re: [websec] handling STS header field extendabil… Chris Palmer
- Re: [websec] handling STS header field extendabil… Tom Ritter
- Re: [websec] handling STS header field extendabil… Hill, Brad
- Re: [websec] handling STS header field extendabil… Collin Jackson
- Re: [websec] handling STS header field extendabil… Paul Hoffman
- Re: [websec] handling STS header field extendabil… Collin Jackson
- Re: [websec] handling STS header field extendabil… Paul Hoffman
- Re: [websec] handling STS header field extendabil… Hill, Brad
- Re: [websec] handling STS header field extendabil… Chris Palmer
- Re: [websec] handling STS header field extendabil… Paul Hoffman
- Re: [websec] handling STS header field extendabil… Hill, Brad
- Re: [websec] handling STS header field extendabil… Hill, Brad
- Re: [websec] handling STS header field extendabil… Paul Hoffman
- Re: [websec] handling STS header field extendabil… Tobias Gondrom
- Re: [websec] handling STS header field extendabil… Collin Jackson
- Re: [websec] handling STS header field extendabil… Barry Leiba
- Re: [websec] handling STS header field extendabil… Yoav Nir
- Re: [websec] handling STS header field extendabil… Tobias Gondrom
- Re: [websec] handling STS header field extendabil… =JeffH
- Re: [websec] handling STS header field extendabil… Yoav Nir
- Re: [websec] handling STS header field extendabil… Tobias Gondrom
- Re: [websec] handling STS header field extendabil… Barry Leiba
- Re: [websec] handling STS header field extendabil… =JeffH
- Re: [websec] handling STS header field extendabil… Tobias Gondrom
- Re: [websec] handling STS header field extendabil… Yoav Nir
- Re: [websec] handling STS header field extendabil… Paul Hoffman
- Re: [websec] handling STS header field extendabil… =JeffH