Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)

Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 11 September 2007 03:45 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUwhI-0001pJ-3G; Mon, 10 Sep 2007 23:45:56 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUqFL-0006qQ-A1 for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 16:52:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUqFL-0006qF-0G for discuss@apps.ietf.org; Mon, 10 Sep 2007 16:52:39 -0400
Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUqFJ-0004Hf-O9 for discuss@apps.ietf.org; Mon, 10 Sep 2007 16:52:38 -0400
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l8AKqZmM006409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 16:52:36 -0400 (EDT)
Date: Mon, 10 Sep 2007 16:52:35 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Eric Rescorla <ekr@networkresonance.com>, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Message-ID: <2FF98D1CD1230EA56262CB32@sirius.fac.cs.cmu.edu>
In-Reply-To: <20070908205337.82EC933C39@delta.rtfm.com>
References: <46E2E54A.2050406@isode.com> <20070908205337.82EC933C39@delta.rtfm.com>
Originator-Info: login-token=Mulberry:01jx+E6vmH+V7bavxrwp20WSaRuxUWU/38lLJPxZ8=; token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
X-Mailman-Approved-At: Mon, 10 Sep 2007 23:45:54 -0400
Cc: ietf@ietf.org, saag@mit.edu, discuss@apps.ietf.org, ietf-http-wg@w3.org, ietf-http-auth@osafoundation.org, Jeffrey Hutzelman <jhutz@cmu.edu>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org


On Saturday, September 08, 2007 01:53:36 PM -0700 Eric Rescorla 
<ekr@networkresonance.com> wrote:

> Alexey wrote:
>> This message is trying to summarize recent discussions on
>> draft-hartman-webauth-phishing-05.txt.
>>
>> Several people voiced their support for the document (on IETF mailing
>> list and in various other off-list discussions). Ekr doesn't think that
>> the document should be published in the current form and he has some
>> good technical points that need to be addressed. At least one more
>> revision is needed to addressed recent comments from Ekr and SecDir
>> review.
>>
>> It is quite clear that some people got confused about intended status of
>> this document and whether it represents IETF consensus. Sam has
>> clarified what was his intention, but another consensus call is needed
>> to make sure people agree with Sam.
>>
>> Subsequent discussions and consensus calls on the document would happen
>> on <ietf-http-auth@osafoundation.org>.
>>
>> Alexey,
>> in my capacity of shepherd for draft-hartman-webauth-phishing
>
>
> I object to this procedure.
shep>
> This document has already had an IETF Last Call, where it failed to
> achieve consensus. At this point, it doesn't need additional last
> calls to "make sure that people agree with Sam", but rather to go back
> to the authors to try to build support in the community. Not liking
> the result of the previous Last Call is not a sufficient basis for
> issuing another one.
>
> At some point in the future, it may be appropriate to issue another
> consensus call, but since this is not a WG mailing list--indeed, the
> IESG has twice declined to charter a WG in this area--nor are you the
> chair, it doesn't seem to me that you have standing to do that. When
> that time comes, I would expect the IESG to designate an appropriate
> time and place.


I think you're overreacting, possibly due to a misinterpretation of what 
Alexey said and/or of the current state of the document.

My reading of the IESG evaluation record suggests that there are indeed 
some issues that the community feels need to be addressed before the 
document can move forward.  Its current state is "IESG Evaluation::Revised 
ID Needed", which, along with the evaluation record, suggests that the 
responsible AD has asked the author and shepherd to get these issues 
resolved and submit a new document.  I don't know what will happen once 
this is done, but unless the IESG feels we already have _rough_ consensus 
to publish the document _and_ there are no major changes, I would expect to 
see a new last call on the revised document.  Of course, that last call may 
see renewed objections from the same individuals, or from others; that does 
not necessarily mean the last call "failed" -- remember, we operate on 
_rough_ consensus.

Now, given that the responsible AD has asked for a new document, it seems 
to me that Alexey, as the shepherd of an individual submission, has quite a 
bit of latitude in how to get there and what it will take before he is 
willing to take the document back to the IESG.  Given that this document is 
a group effort, it's entirely reasonable for Alexey to want to know that 
people contributing to the work agree with any changes Sam makes, and to 
issue consensus cals in an appropriate forum to do this.  No one is 
laboring under the impression that such a call would serve to "override" 
the "failed" IETF LC.  Instead, when Alexey in his role as shepherd 
believes the document is ready to go back to the IESG, he will inform Lisa 
of that fact, and the IESG will decide what to do next.


-- Jeff
-- Jeff