Subject: [Ietf-http-auth] Re: mandatory draft sections (was Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt))
From: Tony Hansen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 12 Sep 2007 17:37:07 -0000
List-Id: ietf-http-auth.osafoundation.org

My viewpoint is somewhat in between. The sections need to be there, but
only in the final draft(s) that are intended for Last Call. Prior to
that, those sections don't need anything more than a "To Be Determined"
notation. Prior to the Last Call, those sections usually don't add
anything to the technical meat of the draft and aren't necessary.
(Unless of course, the draft is dealing with IANA issues throughout.)

During Last Calls, there are many people reviewing the drafts from many
angles, including the protocol point of view and the IANA point of view
and the internationalization point of view and ....

	Tony Hansen
	[email-masked]

Ned Freed wrote:
> 
>> Actually I don't have so much of a problem with having such sections in
>> drafts at review time, but I hate to see them clutter up published
>> RFCs.
> 
> My position is the exact opposite. Full and complete review of drafts it of
> paramount importance and anything thqt interferes with that is unacceptable.
> And as I have pointed out, we have "running code" demonstrating that these
> things are at best distracting and at worst actively interfere with proper
> review.

From: Sam Hartman <[email-masked]>
To: Paul Leach <[email-masked]>
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Date: Tue, 11 Sep 2007 18:59:14 -0400
Cc: "[email-masked]" <[email-masked]>, 

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

    Paul> I've read the I-D and EKR's responses, and while I don't
    Paul> agree with all of them I agree with enough of them that I
    Paul> think that the draft could use a further revision that takes
    Paul> them into consideration.

I certainly agree with this much.

Eric's detailed comments are particularly useful.  A few of his
general comments like making pass to better distinguish protocol bits
from user experience would also improve the document in my opinion.

From: Nicolas Williams <[email-masked]>
To: Ned Freed <[email-masked]>
Cc: [email-masked], [email-masked], 'Iljitsch van Beijnum' <[email-masked]>, Keith Moore <[email-masked]>, [email-masked], [email-masked], [email-masked], Debbie Garside <[email-masked]>, [email-masked]
Subject: [Ietf-http-auth] Required doc sections (Re: [saag] Next step on web	phishing draft(draft-hartman-webauth-phishing-05.txt))
Reply-To: [email-masked]
Date: Tue, 11 Sep 2007 21:11:31 -0000

This thread has morphed into something else entirely.  Please change the
subject and move it to an appropriate list (I've set Reply-To:
[email-masked]; please respect it).

For the record, things like IANA considerations sections should be
required of I-Ds, even if to say that there aren't any.  A single such
section gathering several such sub-sections should do ("Misc
Considerations.  This draft has no IANA considerations.  This draft has
no ...").  And some such sections might be removed by the RFC Editor, or
not (e.g., remove IANA considerations sections that say there are no
IANA considerations).

Nico
-- 

From: Keith Moore <[email-masked]>
To: [email-masked]
OpenPGP: id=E1473978
Cc: [email-masked], [email-masked], [email-masked], 'Iljitsch van Beijnum' <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] Re: Next step on web phishingdraft(draft-hartman-webauth-phishing-05.txt)
Date: Tue, 11 Sep 2007 21:06:20 -0000

Oh, it's very useful to have consistent terminology. And if a document
needs to use new terms, they should definitely be defined before use.  I
just don't want to encourage people to make up new terms (or more
likely, whole new paradigms with their own lexicons) when existing ones
will do.  I'm reminded of recent work in NEA, but they're not the only ones.
> I agree.  Which is why a Terms and Definitions section is darn useful as is
> an overall Term Bank.  However, I will not labour the point as I have long
> ago found that trying to sell Terminology standardization to industry is
> practically impossible - unless you rename it as Knowledge Management.
>   

From: "Debbie Garside" <[email-masked]>
To: <[email-masked]>, "'Keith Moore'" <[email-masked]>
Cc: [email-masked], [email-masked], 'Iljitsch van Beijnum' <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] RE: Next step on web phishingdraft(draft-hartman-webauth-phishing-05.txt)
Reply-To: [email-masked]
Date: Tue, 11 Sep 2007 20:58:25 -0000

 Ned wrote:

> Very good point. Having lots of slightly varying definitions
> of various terms could be hugely harmful.

I agree.  Which is why a Terms and Definitions section is darn useful as is
an overall Term Bank.  However, I will not labour the point as I have long
ago found that trying to sell Terminology standardization to industry is
practically impossible - unless you rename it as Knowledge Management.

Suffice to say, if I you were to write "Humpty Dumpty" and envisage a boiled
egg and I, in interpreting your request, presented you with scrambled egg...
You may be somewhat disappointed at breakfast! ;-)

Best regards

Debbie Garside

> -----Original Message-----
> From: Ned Freed [mailto:[email-masked]]
> Sent: 11 September 2007 21:27
> To: Keith Moore
> Cc: Ned Freed; Debbie Garside; [email-masked];
> [email-masked]; 'Iljitsch van Beijnum';
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: Next step on web
> phishingdraft(draft-hartman-webauth-phishing-05.txt)
>
>
> > >> There has been a discussion recently on LTRU as to
> whether a Terms
> > >> and Definitions section should be introduced within RFCs - much
> > >> like those within ISO Standards.
> > >>
> > >
> > > And my response to this suggestion is the same as it was for the
> > > "IANA considerations" or "Internationalization
> considerations" section suggestions:
> > > By all means have a "terms and definitions" section or
> whatever in
> > > the document if there's a need for one, but don't make having one
> > > mandatory in all documents.
> > >
> > > We already have more than enough useless (from a technical content
> > > perspective) boilerplate in our documents.
> > +1
>
> > Actually I don't have so much of a problem with having such
> sections
> > in drafts at review time, but I hate to see them clutter up
> published
> > RFCs.
>
> My position is the exact opposite. Full and complete review
> of drafts it of paramount importance and anything thqt
> interferes with that is unacceptable.
> And as I have pointed out, we have "running code"
> demonstrating that these things are at best distracting and
> at worst actively interfere with proper review.
>
> What's appropriate to appear in the final RFC is up to the
> RFC Editor. That's what the word "editor" implies. If the RFC
> Editor deems it appropriate to remove null sections that's
> fine, if they feel they should be retained that's fine too.
> Someone reading an RFC to learn how to implement something
> has a definite goal in mind and isn't going to be (or at
> least shouldn't be) distracted by boilerplate in the same way
> a reviewer looking for issues - a far more nebulous
> proposition - can be.
>
> > There are a lot of times when these sections aren't applicable, and
> > having them in the final document just interferes with readability.
>
> It depends on what sort of reading you're doing.
>
> > I also think that a Terms and Definitions section might encourage
> > document authors to make up new terms when they're not necessary,
> > which would also interfere with readability.  (geeks love to create
> > new language.)
>
> Very good point. Having lots of slightly varying definitions
> of various terms could be hugely harmful.
>
> RFC 2119 is a case in point. While I have some small issues
> with how RFC 2119 defines its terms, I've come to realize
> that having consistent meanings for these terms is far more important.
>
> 				Ned
>
>
>

From: Keith Moore <[email-masked]>
To: Ned Freed <[email-masked]>
OpenPGP: id=E1473978
Cc: [email-masked], [email-masked], 'Iljitsch van Beijnum' <[email-masked]>, [email-masked], [email-masked], [email-masked], Debbie Garside <[email-masked]>, [email-masked]
Subject: [Ietf-http-auth] Re: Next step on web phishing	draft(draft-hartman-webauth-phishing-05.txt)
Date: Tue, 11 Sep 2007 20:57:04 -0000

Ned Freed wrote:
>>>> There has been a discussion recently on LTRU as to whether a Terms and
>>>> Definitions section should be introduced within RFCs - much like those
>>>> within ISO Standards.
>>>>
>>>>         
>>> And my response to this suggestion is the same as it was for the "IANA
>>> considerations" or "Internationalization considerations" section suggestions:
>>> By all means have a "terms and definitions" section or whatever in the document
>>> if there's a need for one, but don't make having one mandatory in all
>>> documents.
>>>
>>> We already have more than enough useless (from a technical content
>>> perspective) boilerplate in our documents.
>>>       
>> +1
>>     
>
>   
>> Actually I don't have so much of a problem with having such sections in
>> drafts at review time, but I hate to see them clutter up published
>> RFCs.
>>     
>
> My position is the exact opposite. Full and complete review of drafts it of
> paramount importance and anything thqt interferes with that is unacceptable.
> And as I have pointed out, we have "running code" demonstrating that these
> things are at best distracting and at worst actively interfere with proper
> review.
>
> What's appropriate to appear in the final RFC is up to the RFC Editor. That's
> what the word "editor" implies. If the RFC Editor deems it appropriate to
> remove null sections that's fine, if they feel they should be retained that's
> fine too. Someone reading an RFC to learn how to implement something has a
> definite goal in mind and isn't going to be (or at least shouldn't be)
> distracted by boilerplate in the same way a reviewer looking for issues - a far
> more nebulous proposition - can be.
>   

Well, I guess we do disagree here to some extent.  For me, every
sentence of a document that doesn't contribute to the technical
knowledge that needs to be conferred, interferes with readability, and
ultimately, interoperability.  That applies to the copyright
boilerplate, that applies to checkoff sections that are just there to
get approval, it applies to information that is needed only by IANA. 
And I wasn't aware that our processes allowed the RFC Editor to delete,
say, a meaningless IANA considerations section.  (I've never checked to
see whether has happened.)

However I don't have a problem with IESG wanting additional supporting
information to help it decide whether to approve documents and to decide
what additional processing is needed.  If the best place to put such
information is in the I-D, fine; if the best place to put that
information is in a separate form, that's also fine with me.  (And I'd
far prefer that we not impose unnecessary burdens on authors of early
I-Ds - the fewer hoops they have to jump through, the better.)

In general, I think that I-Ds and RFCs really serve very different
purposes, and trying to make them be (almost) the same causes us to make
less readable end product.  I'd like to see more use of "NOTEs IN DRAFT"
and similar devices to separate supporting material from material that
belongs in the final publication.  I'm concerned about readability
throughout the document cycle, but am especially concerned about
readability of our published documents - as many more people read them
at this stage and those people have less context to aid them in sorting
through the crap.

Keith

From: Ned Freed <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked], [email-masked], 'Iljitsch van Beijnum' <[email-masked]>, [email-masked], [email-masked], [email-masked], Debbie Garside <[email-masked]>, [email-masked]
Subject: [Ietf-http-auth] Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)
Date: Tue, 11 Sep 2007 20:43:04 -0000

> >> There has been a discussion recently on LTRU as to whether a Terms and
> >> Definitions section should be introduced within RFCs - much like those
> >> within ISO Standards.
> >>
> >
> > And my response to this suggestion is the same as it was for the "IANA
> > considerations" or "Internationalization considerations" section suggestions:
> > By all means have a "terms and definitions" section or whatever in the document
> > if there's a need for one, but don't make having one mandatory in all
> > documents.
> >
> > We already have more than enough useless (from a technical content
> > perspective) boilerplate in our documents.
> +1

> Actually I don't have so much of a problem with having such sections in
> drafts at review time, but I hate to see them clutter up published
> RFCs.

My position is the exact opposite. Full and complete review of drafts it of
paramount importance and anything thqt interferes with that is unacceptable.
And as I have pointed out, we have "running code" demonstrating that these
things are at best distracting and at worst actively interfere with proper
review.

What's appropriate to appear in the final RFC is up to the RFC Editor. That's
what the word "editor" implies. If the RFC Editor deems it appropriate to
remove null sections that's fine, if they feel they should be retained that's
fine too. Someone reading an RFC to learn how to implement something has a
definite goal in mind and isn't going to be (or at least shouldn't be)
distracted by boilerplate in the same way a reviewer looking for issues - a far
more nebulous proposition - can be.

> There are a lot of times when these sections aren't applicable,
> and having them in the final document just interferes with readability.

It depends on what sort of reading you're doing.

> I also think that a Terms and Definitions section might encourage
> document authors to make up new terms when they're not necessary, which
> would also interfere with readability.  (geeks love to create new language.)

Very good point. Having lots of slightly varying definitions of various terms
could be hugely harmful.

RFC 2119 is a case in point. While I have some small issues with how RFC 2119
defines its terms, I've come to realize that having consistent meanings for
these terms is far more important.

				Ned

From: Keith Moore <[email-masked]>
To: Ned Freed <[email-masked]>
OpenPGP: id=E1473978
Cc: [email-masked], [email-masked], 'Iljitsch van Beijnum' <[email-masked]>, [email-masked], [email-masked], [email-masked], Debbie Garside <[email-masked]>, [email-masked]
Subject: [Ietf-http-auth] Re: Next step on web phishing	draft(draft-hartman-webauth-phishing-05.txt)
Date: Tue, 11 Sep 2007 20:12:28 -0000

>> There has been a discussion recently on LTRU as to whether a Terms and
>> Definitions section should be introduced within RFCs - much like those
>> within ISO Standards.
>>     
>
> And my response to this suggestion is the same as it was for the "IANA
> considerations" or "Internationalization considerations" section suggestions:
> By all means have a "terms and definitions" section or whatever in the document
> if there's a need for one, but don't make having one mandatory in all
> documents.
>
> We already have more than enough useless (from a technical content
> perspective) boilerplate in our documents. 
+1

Actually I don't have so much of a problem with having such sections in
drafts at review time, but I hate to see them clutter up published
RFCs.    There are a lot of times when these sections aren't applicable,
and having them in the final document just interferes with readability. 

I also think that a Terms and Definitions section might encourage
document authors to make up new terms when they're not necessary, which
would also interfere with readability.  (geeks love to create new language.)

VBR-Info: md=resistor.net; mc=all; mv=elandsys.com
Date: Tue, 11 Sep 2007 12:54:22 -0700
To: Shumon Huque <[email-masked]>
From: SM <[email-masked]>
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked]

At 12:39 11-09-2007, Shumon Huque wrote:
>Would someone send a pointer to Eric Rescorla's critique of the
>draft? I couldn't find it, although I found comments by various
>other folks on the IETF draft tracker.

http://www1.ietf.org/mail-archive/web/ietf/current/msg47207.html

Regards,
-sm 

Date: Tue, 11 Sep 2007 15:39:22 -0400
From: Shumon Huque <[email-masked]>
To: Paul Leach <[email-masked]>
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Organization: University of Pennsylvania
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

On Mon, Sep 10, 2007 at 04:29:24PM -0700, Paul Leach wrote:
> I've read the I-D and EKR's responses, and while I don't agree with all of them I agree with enough of them that I think that the draft could use a further revision that takes them into consideration.
> 

Would someone send a pointer to Eric Rescorla's critique of the
draft? I couldn't find it, although I found comments by various 
other folks on the IETF draft tracker.

--Shumon.

From: Ned Freed <[email-masked]>
To: Debbie Garside <[email-masked]>
Cc: [email-masked], [email-masked], 'Iljitsch van Beijnum' <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] RE: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)
Date: Tue, 11 Sep 2007 19:31:17 -0000

> > `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
> > `it means just what I choose it to mean -- neither more nor less.'

> There has been a discussion recently on LTRU as to whether a Terms and
> Definitions section should be introduced within RFCs - much like those
> within ISO Standards.

And my response to this suggestion is the same as it was for the "IANA
considerations" or "Internationalization considerations" section suggestions:
By all means have a "terms and definitions" section or whatever in the document
if there's a need for one, but don't make having one mandatory in all
documents.

We already have more than enough useless (from a technical content
perspective) boilerplate in our documents. We don't need any more, and
when such sections are always present but usually say "no such and such
are present" they aren't helping.

The last time this came up in the context of IANA considerations it was
asserted that having such sections act as a useful check to make sure there are
no needed definitions or considerations. The problem is people don't work this
way. If the section is mandatory they'll add it when the document is first
created. Sometimes they'll remember to keep it up to date and sometimes they
won't. But when someone reviews the document they'll see that section
and assume its presence means whatever has been checked. So the mandatory
section approach can actually result in more errors and omissions, not less.

It took me only a few minutes the last time we had one of these discussions
to find a documentt (in the RFE Editor's queue, as I recall) where
this had happened: A "there are no IANA considerations" section had been
added early on but when the document acquired IANA considerations it
wasn't updated. And nobody who reviewed the document caught it.

				Ned

P.S. I've read a lot of ISO and CCITT specifications and I have found
their terms and definitions material to be fairly hit or miss in terms of
utility.

From: "Debbie Garside" <[email-masked]>
To: <[email-masked]>, "'Iljitsch van Beijnum'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] RE: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)
Reply-To: [email-masked]
Date: Tue, 11 Sep 2007 11:20:51 -0000

Bill wrote:

> `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
> `it means just what I choose it to mean -- neither more nor less.'

There has been a discussion recently on LTRU as to whether a Terms and
Definitions section should be introduced within RFCs - much like those
within ISO Standards.

Best regards

Debbie Garside

> -----Original Message-----
> From: Bill Manning [mailto:[email-masked]]
> Sent: 10 September 2007 00:49
> To: Iljitsch van Beijnum
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Alexey Melnikov;
> [email-masked]
> Subject: Re: Next step on web phishing
> draft(draft-hartman-webauth-phishing-05.txt)
>
> On Mon, Sep 10, 2007 at 01:21:00AM +0200, Iljitsch van Beijnum wrote:
> > On 10-sep-2007, at 0:51, Marshall Eubanks wrote:
> >
> > >I tend to rely on Dictionaries to sort these things out - from
> > >Dictionary.com
> >
> > Dictionaries are useless, when in doubt they just add definitions.
> > For instance, try figuring out how many bytes there are in
> a megabyte
> > from a few dictionaries.
> >
>
> `When I use a word,' Humpty Dumpty said, in rather a scornful tone,
> `it means just what I choose it to mean -- neither more nor less.'
>
>
> --bill
>
> Opinions expressed may not even be mine by the time you read them, and
> certainly don't reflect those of any other entity (legal or
> otherwise).
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
>
>
>

From: Sam Hartman <[email-masked]>
To: Chris Drake <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Date: Mon, 10 Sep 2007 20:05:10 -0400
Cc: [email-masked], IETF Discussion <[email-masked]>

>>>>> "Chris" == Chris Drake <[email-masked]> writes:

    Chris> Hi Alexey,
    >> And if you would like to suggest a better process for moving
    >> things forward, please share your opinion.

    Chris> Suggest: Properly document comments and reviews somewhere.

    Chris> Question: what's the best way to submit comments and
    Chris> reviews - can we just re-write the entire draft, annotating
    Chris> our changes, and submit that?  

You can.
I'd find it  more useful though if you simply sent in comments  where appropriate.
I.E. send a message to this list describing an issue with the draft and  your comments on how to solve it.
Specific new text is welcome but not required.

However if you find that annotating the draft is the easiest way for
you to get your point across do that.  A new text version would be far
more useful than an annotated pdf to me.

    Chris> Are professionals and
    Chris> experts even invited/allowed to comment?  

I think most of us consider ourselves computer security or web
professionals.  (I consider myself a computer security person more
than a web person).  we like to think that we have sufficient
background to be qualified to make the statements we're making.  So,
yes, I think many of us consider ourselves experts in fields related
to this work.  I'm not sure anyone today can claim to be an expert in
solving phishing as it's not particularly a solved problem.:-) But
yes, comments from people who have subject matter expertise are
greatly welcome.

    Chris> Is there a formal
    Chris> procedure for dealing with suggestions (eg: attributing,
    Chris> documenting, discussing, leading to an ultimate official
    Chris> public inclusion (or exclusion with reasoning).

I don't know if we'll end up needing that level of formality; I'm
hoping that mailing list discussion will be sufficient, but we can
develop formality if we need it.  If you're new to the IETF you may
want to take a look at http://www.ietf.org/rfc/rfc4677.txt

Date: Tue, 11 Sep 2007 09:51:53 +1000
From: Chris Drake <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re[2]: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], IETF Discussion <[email-masked]>

Hi Alexey,

> And if you would like to suggest a better process for moving things
> forward, please share your opinion.

Suggest: Properly document comments and reviews somewhere.  I've found
the current draft, and lots of arguments about change suggestions -
but there's no documented historical records of those suggestions.

Question: what's the best way to submit comments and reviews - can we
just re-write the entire draft, annotating our changes, and submit
that?  Are professionals and experts even invited/allowed to comment?
Is there a formal procedure for dealing with suggestions (eg:
attributing, documenting, discussing, leading to an ultimate official
public inclusion (or exclusion with reasoning).

Kind Regards,
Chris Drake

Tuesday, September 11, 2007, 3:21:36 AM, Alexy wrote:

AM> Eric,

AM> Eric Rescorla wrote:

>>At Mon, 10 Sep 2007 08:59:57 +0200,
>>Eliot Lear wrote:
>>  
>>
>>>Bernard,
>>>    
>>>
>>>>I agree with EKR here.  Failed consensus is failed consensus. RFC 2026
>>>>does not support the process that has been recommended here.   
>>>>      
>>>>
>>>Perhaps Sam and Lisa can explain a bit more as to what process they
>>>intend to use.  It seems that Alexey is providing a forum for discussion
>>>to improve the document, and I see nothing wrong with that.  I would
>>>imagine that both the IESG and the community will still get their say,
>>>so what precisely is the problem?
>>>
>>>This having been said, it seems to me that in order to address EKR's
>>>(and perhaps others') concerns, the document will need substantial 
>>>work.  I welcome efforts to improve that work.  Where should that 
>>>happen?  Must Sam do it alone?
>>>    
>>>
>>Sam can of course consult anyone who he chooses for opinions,
>>reviews, etc. However, Alexey's original message indicated
>>something rather different. Namely:
>>
>>
>>	Subsequent discussions and consensus calls on the document
>>	would happen on <[email-masked]>.
>>
>>	...
>>
>>	Alexey,
>>	in my capacity of shepherd for draft-hartman-webauth-phishing
>>  
>>
AM> On rereading my message, it probably came out stronger than I intended.
AM> But according to my English-Russian dictionary the verb "would" can
AM> convey "polite request", which was my intent.

>>This document isn't a WG document and this mailing list is not a WG
>>list. It's inappropriate to hold any kind of "consensus calls".
>>Moreover, as there's no WG, Alexey isn't the chair and doesn't
>>have any authority to run a consensus or any other process.
>>  
>>
AM> I think you are reading too much into my message.
AM> I didn't say that I will run any consensus calls, shepherding AD has the
AM> authority to do that.
AM> And you are correct of course that I don't have any authority in this
AM> case. I am just working for the shepherding AD, trying to help her in
AM> getting the document through IESG.

>>This document was taken to the IESG and didn't achieve consensus
>>in LC. It now has the same status as any other random individual
>>ID, nothing more nothing less.
>>  
>>
AM> Yes (the last sentence).

AM> It is not yet clear to me if you have any problems with the document
AM> being discussed on http-auth mailing list. If you have, can you explain
AM> why and maybe suggest a better place for discussions?

AM> And if you would like to suggest a better process for moving things
AM> forward, please share your opinion.

AM> Regards,
AM> Alexey

AM> _______________________________________________
AM> Ietf-http-auth mailing list
AM> [email-masked]
AM> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

From: Paul Leach <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Eric Rescorla <[email-masked]>
Subject: RE: [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 10 Sep 2007 23:31:47 -0000

I've read the I-D and EKR's responses, and while I don't agree with all of =
them I agree with enough of them that I think that the draft could use a fu=
rther revision that takes them into consideration.

From: Sam Hartman <[email-masked]>
To: Chris Drake <[email-masked]>
Subject: Re: [Ietf-http-auth] Moving forward on draft-hartman-webauth-phishing
Date: Mon, 10 Sep 2007 18:19:37 -0400
Cc: [email-masked]

Sure.  The draft is
http://tools.ietf.org/internet-drafts/draft-hartman-webauth-phishing.txt

I'll forward the last call comments to this list.

Date: Tue, 11 Sep 2007 08:07:57 +1000
From: Chris Drake <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] Moving forward on draft-hartman-webauth-phishing
Cc: [email-masked]

Hi Sam,

Can you point us to the document, and Erics/Christians/others
comments/reviews please?

Kind Regards,
Chris Drake

From: Ned Freed <[email-masked]>
Subject: RE: [Ietf-http-auth] Re: Next step on web phishing	draft (draft-hartman-webauth-phishing-05.txt)
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked], 'IETF Discussion' <[email-masked]>
Date: Mon, 10 Sep 2007 21:52:46 -0000

> > Not at all. There is a huge difference between "ask participants
> > in a discussion what they think" and a "consensus call".

> I've frequently seen postings that talk about the "consensus"
> of a Bar BoF, and never seen any objection to that terminology.
> Consensus is always qualified by the scope of the participants,
> and we all know how to tell the difference between "consensus
> of the IETF", "consensus of the room", "consensus of the working
> group", and "consensus of the participants in the mailing list X".

> I think the process discussion is a distraction from working
> on the actual issues, and wish it would stop.

+1

				Ned

P.S. For the record, I think this document needs a bit of revising but
if that's done sensibly I fully support its publication.

From: Sam Hartman <[email-masked]>
To: [email-masked]
Date: Mon, 10 Sep 2007 17:30:52 -0400
Subject: [Ietf-http-auth] Moving forward on draft-hartman-webauth-phishing

Hi, folks.  I'm not going to get much involved in the procedural
discussion that Eric has raised.  As far as I'm concerned, I've been
directed by my document shepherd and shepherding AD to hold a
discussion to address comments received in last call on my document
and I'm going to do that.  We all believed that having a list other
than [email-masked] to hold that discussion on would be good and so
we're holding it here.

My goal is to improve the document so that when Alexey and Lisa take
it back to the IESG and the IESG asks the community if the document
addresses issues raised in last call and if there is sufficient
consensus to publish that we'll make forwtard progress.

You can discuss all you want about whether this procedure is the best
one to achieve that goal, but until Lisa or Alexey tells me otherwise
then I'm going to go forward as they direct and focus on the content
of the document.

I'd like to take a crack at addressing comments received in last call
before we get too involved here, although I'll wart that may take a
bit of time.  MIT is launching the Kerberos Consortium September 27
and I'm heavily involved in that.  I don't know if I'll get a new
revision out before then.

I don't view this document as just mine.  If I'm directed to make
changes by one of the shepherds I'll make those changes.  If I think
the document is watered down to a point where it has insufficient
value, I may give up the pin or potentially ask to take the text I've
written outside of the IETF process.  Obviously the IETF could do
whatever it wants with that text as well; that's how our process
works.

I don't want to get into where that role comes from; I don't care
whether I'm an author or an editor and will not focus on such
distinctions.  Ultimately my goal is to produce a useful document that
can pass last call; I'm not at all sure what that makes me and don't
much care.

Here are some of the issues that need to be addressed:

* Eric sent a lot of detailed comments that have not received
  responses.  I'll need to respond to those.  I doubt I'll make Eric
  happy, but I expect I'll be able to get to a point where a lot of
  people other than Eric agree with my responses to his comments.

* We need to clearly state what this document is trying to do and to
  make sure that we ask the community for the appropriate kind of
  consensus in an upcoming last call.

* We need to make sure the apps community and security community have
  sufficient notice and opportunity to review.  I believe Alexey has
  been and continues to work on that.

* I need to respond to Christian's review.

From: Jeffrey Hutzelman <[email-masked]>
To: Eric Rescorla <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft	(draft-hartman-webauth-phishing-05.txt)
Originator-Info: login-token=Mulberry:01jx+E6vmH+V7bavxrwp20WSaRuxUWU/38lLJPxZ8=; token_authority=[email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Jeffrey Hutzelman <[email-masked]>
Date: Mon, 10 Sep 2007 20:53:48 -0000

On Saturday, September 08, 2007 01:53:36 PM -0700 Eric Rescorla 
<[email-masked]> 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 <[email-masked]>.
>>
>> 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

From: Keith Moore <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft	(draft-hartman-webauth-phishing-05.txt)
OpenPGP: id=E1473978
Cc: [email-masked], IETF Discussion <[email-masked]>
Date: Mon, 10 Sep 2007 20:00:17 -0000

>> On rereading my message, it probably came out stronger than I intended.
>> But according to my English-Russian dictionary the verb "would" can 
>> convey "polite request", which was my intent.
>>     
>
> Hmm... I'm still not sure what you're trying to say. My point is
> that there shouldn't be any consensus calls by anyone on the
> ietf-http-auth mailing list. It's not a WG.
>   
I think I'd say it slightly differently.  I don't see why any discussion
group shouldn't try to reach consensus within that group.  But such
consensus doesn't impose any burden on IETF to adopt its output. 

Then again, neither (IMHO) does consensus of an IETF WG impose any
burden on IETF as a whole to adopt its output.  Every working group (and
every individual submitter) should understand that it's its job to earn
community-wide consensus, rather than merely consensus within its group.

From: "Larry Masinter" <[email-masked]>
To: "'Eric Rescorla'" <[email-masked]>
Subject: RE: [Ietf-http-auth] Re: Next step on web phishing draft	(draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], [email-masked], 'IETF Discussion' <[email-masked]>
Date: Mon, 10 Sep 2007 19:57:22 -0000

> Not at all. There is a huge difference between "ask participants
> in a discussion what they think" and a "consensus call".

I've frequently seen postings that talk about the "consensus"
of a Bar BoF, and never seen any objection to that terminology.
Consensus is always qualified by the scope of the participants,
and we all know how to tell the difference between "consensus
of the IETF", "consensus of the room", "consensus of the working
group", and "consensus of the participants in the mailing list X".

I think the process discussion is a distraction from working
on the actual issues, and wish it would stop.

Larry
-- 
http://larry.masinter.net

Date: Mon, 10 Sep 2007 14:42:56 -0500
From: Nicolas Williams <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], IETF Discussion <[email-masked]>

On Mon, Sep 10, 2007 at 11:56:15AM -0700, Eric Rescorla wrote:
> At Mon, 10 Sep 2007 13:52:00 -0500,
> Nicolas Williams wrote:
> > Are you saying that a design team can't have "consensus" or "consensus
> > calls"?  Surely they can, though consensus internal to design teams
> > cannot, and, indeed, must not be binding on any other aspect of IETF
> > processes.
> 
> Indeed. And so when the "document shepherd" implies that he or the
> AD will be issuing consensus calls, I think that implies something
> quite different from some internal design team consensus call.

I don't see the implication.

> > So my question is: is the ietf-http-auth mailing list intended to act as
> > a forum for a design team working on draft-hartman-webauth-phishing?
> 
> Good question. Let's ask the author of the document, who is the only
> person who can speak to the future direction of an individual
> submission. Sam?

Actually, looking at the I-D's state and the IESG evaluation record I
see that it is not clear that the document either passed or failed IETF
LC, and that it might yet be approved.

> > I think that's exactly what's happening.
> 
> That's not what I see, unless Alexey suddenly became the author of
> the document. Rather, I see someone claiming to be the document
> shepherd acting under the direction of the AD talking about the
> way forward. How is that the author revising the document, trying
> to build consensus, etc.?

Why on Earth couldn't Sam let Alexey run a design team to come up with
improvements that Sam could make to the I-D?

Of course, we've not heard from Sam on this (or if we have, I've missed
it -- I don't subscribe to the main ietf list).

Nico
-- 

Date: Mon, 10 Sep 2007 11:56:15 -0700
From: Eric Rescorla <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], IETF Discussion <[email-masked]>

At Mon, 10 Sep 2007 13:52:00 -0500,
Nicolas Williams wrote:
> 
> On Mon, Sep 10, 2007 at 11:29:46AM -0700, Eric Rescorla wrote:
> > At Mon, 10 Sep 2007 18:21:36 +0100,
> > Alexey Melnikov wrote:
> > > On rereading my message, it probably came out stronger than I intended.
> > > But according to my English-Russian dictionary the verb "would" can 
> > > convey "polite request", which was my intent.
> > 
> > Hmm... I'm still not sure what you're trying to say. My point is
> > that there shouldn't be any consensus calls by anyone on the
> > ietf-http-auth mailing list. It's not a WG.
> 
> Are you saying that a design team can't have "consensus" or "consensus
> calls"?  Surely they can, though consensus internal to design teams
> cannot, and, indeed, must not be binding on any other aspect of IETF
> processes.

Indeed. And so when the "document shepherd" implies that he or the
AD will be issuing consensus calls, I think that implies something
quite different from some internal design team consensus call.

> So my question is: is the ietf-http-auth mailing list intended to act as
> a forum for a design team working on draft-hartman-webauth-phishing?

Good question. Let's ask the author of the document, who is the only
person who can speak to the future direction of an individual
submission. Sam?

> > If the author feels differently, he is of course free to revise the
> > document, try to build consensus, and resubmit to the IESG at some
> > point in the future. Since it's an individual submission, no IETF
> > process is needed or appropriate for that.
> 
> I think that's exactly what's happening.

That's not what I see, unless Alexey suddenly became the author of
the document. Rather, I see someone claiming to be the document
shepherd acting under the direction of the AD talking about the
way forward. How is that the author revising the document, trying
to build consensus, etc.?

-Ekr

Date: Mon, 10 Sep 2007 14:25:49 -0500
From: Nicolas Williams <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], IETF Discussion <[email-masked]>

On Mon, Sep 10, 2007 at 01:52:00PM -0500, Nicolas Williams wrote:
> But this draft does have a formal _state_: "IESG Evaluation :: Revised
> ID Needed."

It's state seems to be that it has not exactly failed IETF LC (e.g., one
IESG member commented that "[i]t is my educated guess there is rough
consensus in the IETF to publish this document.  However, additional
work to document that roughconsensus would be helpful given the strength
of the two last call objections."  Which proves nothing, except that the
process is such that the sponsoring AD and the IESG as a whole are
responsible for calling the result of the IETF LC and for insisting on
whatever changes are needed for IETF LC comments to be addressed that
have to be addressed.  Once the IESG makes a decision one can appeal.

Nico
-- 

From: "tom.petch" <[email-masked]>
To: "der Mouse" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: [Ietf-http-auth] Re: [saag] Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)
Reply-To: "tom.petch" <[email-masked]>
Date: Mon, 10 Sep 2007 19:10:23 -0000

----- Original Message -----
From: "der Mouse" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Monday, September 10, 2007 4:14 PM
Subject: Re: [saag] Next step on web phishing
draft(draft-hartman-webauth-phishing-05.txt)

> > I really dislike the use of "fishing" with creative spelling in a
> > document prepared for an international standards organization.
>
> Perhaps unfortunately, that is *the* word for the behaviour in
> question, at least in English.  It was not invented for the draft, and
> "com[ing] up with something [else]" would be *less* descriptive and
> would render the document cryptic to the people who's been working
> against phishing for years.  Perhaps it's a bad word to use in other
> languages, but that should be addressed by the translator(s) in
> question, not by mangling the original.
>

Stick the word in quotes which conveys the message that we know that this is not
a good piece of terminology, but that we are pragmatic enough to recognise that
using it will convey the right meaning to most people.

But on the other strand under this Subject:, I am with those who think that the
IETF has demonstrated an absence of consensus and that the proposed way forward
to try and achieve it by other means in plain wrong.

Tom Petch

Date: Mon, 10 Sep 2007 11:51:07 -0700
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft	(draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], IETF Discussion <[email-masked]>

At Mon, 10 Sep 2007 14:45:26 -0400,
Jeffrey Altman wrote:
> 
> Eric Rescorla wrote:
> 
> > Hmm... I'm still not sure what you're trying to say. My point is
> > that there shouldn't be any consensus calls by anyone on the
> > ietf-http-auth mailing list. It's not a WG.
> 
> Eric:
> 
> It sounds to me as if you are attempting to claim that only official
> IETF activities are permitted to ask the participants in a discussion
> what they think.

Not at all. There is a huge difference between "ask participants
in a discussion what they think" and a "consensus call". 

> Clearly it is not going to be possible for a subsequent revision of
> this document to be re-submitted to the IESG if the contributors to
> the document cannot achieve consensus among themselves.

But this list is not the list of contributors to this document.
It's some other list, one with no formal standing for any sort
of "consensus call." 

> > I have no problem with Sam soliciting opinions in his document on any
> > forum of his choice. What I object to is the notion--again implied in
> > your above comments--that this document has some formal standing.  As
> > I said initially, this is an individual submission that failed to
> > obtain consensus. As such it doesn't need shepherding or shepherding
> > ADs, any more than any other individual ID.
> 
> This is a document for which an Area Director (separate from the one
> who happened to be the author of the document) wishes to forward
> progress.  While this does not imply a formal basis for consideration,
> it does provide incentive to put additional effort into revising it.
> 
> Alexey was asked by an AD to take responsibility for this document.

Yes, and my point is that I don't believe that's an appropriate
procedure. Individual submissions are just that. Given that this one
has already failed to achieve consensus in a previous IETF LC, if the
AD wants to actively progress this document--as opposed to just
passively waiting for some forthcoming revision--then the appropriate
next step is a BOF followed by a WG.

> > As should be clear from my initial review, I don't think this document
> > should move forward.
> 
> That is your opinion and you are welcome to hold it.
> 
> However, it is clear to me that this problem area cannot be addressed by
> organizations such as W3C without the support and collaboration
> of the IETF.

It may be clear to you, but it certainly hasn't been established
in any way I find convincing.

In any case, this isn't "the IETF". It's an individual
submission. "The IETF" would be a WG, IESG statement, etc.

-Ekr

Date: Mon, 10 Sep 2007 13:52:00 -0500
From: Nicolas Williams <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], IETF Discussion <[email-masked]>

On Mon, Sep 10, 2007 at 11:29:46AM -0700, Eric Rescorla wrote:
> At Mon, 10 Sep 2007 18:21:36 +0100,
> Alexey Melnikov wrote:
> > On rereading my message, it probably came out stronger than I intended.
> > But according to my English-Russian dictionary the verb "would" can 
> > convey "polite request", which was my intent.
> 
> Hmm... I'm still not sure what you're trying to say. My point is
> that there shouldn't be any consensus calls by anyone on the
> ietf-http-auth mailing list. It's not a WG.

Are you saying that a design team can't have "consensus" or "consensus
calls"?  Surely they can, though consensus internal to design teams
cannot, and, indeed, must not be binding on any other aspect of IETF
processes.

So my question is: is the ietf-http-auth mailing list intended to act as
a forum for a design team working on draft-hartman-webauth-phishing?

If so then I don't understand your objection.  Let the design team do
what they will, and if and when they have something to show then we can
have another IETF LC (or BoF).  Or are you saying that the IETF LC that
has already taken place failed in a permanent way, as opposed to finding
issues that need work but which do not prevent the document from being
brought forward again?  I.e., did the IETF LC on this I-D really fail
with prejudice?  And if so, who determined that?

> > And if you would like to suggest a better process for moving things 
> > forward, please share your opinion.
> 
> I have no problem with Sam soliciting opinions in his document on any
> forum of his choice. What I object to is the notion--again implied in
> your above comments--that this document has some formal standing.  As
> I said initially, this is an individual submission that failed to
> obtain consensus. As such it doesn't need shepherding or shepherding
> ADs, any more than any other individual ID.

Speaking of consensus on a non-WG/IETF list != formal standing; I doubt
anyone here would argue that it does.

But this draft does have a formal _state_: "IESG Evaluation :: Revised
ID Needed."

What you say implies that design teams can't have consensus.  Surely you
don't actually believe that.

> > And if you would like to suggest a better process for moving things 
> > forward, please share your opinion.
> 
> As should be clear from my initial review, I don't think this document
> should move forward.

In its current form?  Or in its approach to the problem?  Is there a
process by which the IESG or IETF can actually reject an idea or
document _with prejudice_?

> If the author feels differently, he is of course free to revise the
> document, try to build consensus, and resubmit to the IESG at some
> point in the future. Since it's an individual submission, no IETF
> process is needed or appropriate for that.

I think that's exactly what's happening.

Nico
-- 

Date: Mon, 10 Sep 2007 14:45:26 -0400
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft	(draft-hartman-webauth-phishing-05.txt)
OpenPGP: url=http://pgp.mit.edu
Cc: [email-masked], IETF Discussion <[email-masked]>
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms080006060009060803070000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Eric Rescorla wrote:

> Hmm... I'm still not sure what you're trying to say. My point is
> that there shouldn't be any consensus calls by anyone on the
> ietf-http-auth mailing list. It's not a WG.

Eric:

It sounds to me as if you are attempting to claim that only official
IETF activities are permitted to ask the participants in a discussion
what they think.

Clearly it is not going to be possible for a subsequent revision of
this document to be re-submitted to the IESG if the contributors to
the document cannot achieve consensus among themselves.

> I have no problem with Sam soliciting opinions in his document on any
> forum of his choice. What I object to is the notion--again implied in
> your above comments--that this document has some formal standing.  As
> I said initially, this is an individual submission that failed to
> obtain consensus. As such it doesn't need shepherding or shepherding
> ADs, any more than any other individual ID.

This is a document for which an Area Director (separate from the one
who happened to be the author of the document) wishes to forward
progress.  While this does not imply a formal basis for consideration,
it does provide incentive to put additional effort into revising it.

Alexey was asked by an AD to take responsibility for this document.
He is trying to fulfill that request.  There is no reason to put
hurdles in his path.

> As should be clear from my initial review, I don't think this document
> should move forward.

That is your opinion and you are welcome to hold it.

However, it is clear to me that this problem area cannot be addressed by
organizations such as W3C without the support and collaboration
of the IETF.

Jeffrey Altman

--------------ms080006060009060803070000
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms080006060009060803070000--

Date: Mon, 10 Sep 2007 11:29:46 -0700
From: Eric Rescorla <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], IETF Discussion <[email-masked]>

At Mon, 10 Sep 2007 18:21:36 +0100,
Alexey Melnikov wrote:
> >	Subsequent discussions and consensus calls on the document
> >	would happen on <[email-masked]>.
> >
> >	...
> >
> >	Alexey,
> >	in my capacity of shepherd for draft-hartman-webauth-phishing
> >  
> >
> On rereading my message, it probably came out stronger than I intended.
> But according to my English-Russian dictionary the verb "would" can 
> convey "polite request", which was my intent.

Hmm... I'm still not sure what you're trying to say. My point is
that there shouldn't be any consensus calls by anyone on the
ietf-http-auth mailing list. It's not a WG.

> >This document isn't a WG document and this mailing list is not a WG
> >list. It's inappropriate to hold any kind of "consensus calls".
> >Moreover, as there's no WG, Alexey isn't the chair and doesn't
> >have any authority to run a consensus or any other process.
> >  
> >
> I think you are reading too much into my message.
> I didn't say that I will run any consensus calls, shepherding AD has the 
> authority to do that.
> And you are correct of course that I don't have any authority in this 
> case. I am just working for the shepherding AD, trying to help her in 
> getting the document through IESG.
> 
> >This document was taken to the IESG and didn't achieve consensus
> >in LC. It now has the same status as any other random individual
> >ID, nothing more nothing less.
> >  
> >
> Yes (the last sentence).
> 
> It is not yet clear to me if you have any problems with the document 
> being discussed on http-auth mailing list. If you have, can you explain 
> why and maybe suggest a better place for discussions?
>
> And if you would like to suggest a better process for moving things 
> forward, please share your opinion.

I have no problem with Sam soliciting opinions in his document on any
forum of his choice. What I object to is the notion--again implied in
your above comments--that this document has some formal standing.  As
I said initially, this is an individual submission that failed to
obtain consensus. As such it doesn't need shepherding or shepherding
ADs, any more than any other individual ID.

> And if you would like to suggest a better process for moving things 
> forward, please share your opinion.

As should be clear from my initial review, I don't think this document
should move forward.

If the author feels differently, he is of course free to revise the
document, try to build consensus, and resubmit to the IESG at some
point in the future. Since it's an individual submission, no IETF
process is needed or appropriate for that.

-Ekr

Date: Mon, 10 Sep 2007 18:21:36 +0100
From: Alexey Melnikov <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft  (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], IETF Discussion <[email-masked]>

Eric,

Eric Rescorla wrote:

>At Mon, 10 Sep 2007 08:59:57 +0200,
>Eliot Lear wrote:
>  
>
>>Bernard,
>>    
>>
>>>I agree with EKR here.  Failed consensus is failed consensus.  RFC 2026 
>>>does not support the process that has been recommended here.   
>>>      
>>>
>>Perhaps Sam and Lisa can explain a bit more as to what process they 
>>intend to use.  It seems that Alexey is providing a forum for discussion 
>>to improve the document, and I see nothing wrong with that.  I would 
>>imagine that both the IESG and the community will still get their say, 
>>so what precisely is the problem?
>>
>>This having been said, it seems to me that in order to address EKR's 
>>(and perhaps others') concerns, the document will need substantial 
>>work.  I welcome efforts to improve that work.  Where should that 
>>happen?  Must Sam do it alone?
>>    
>>
>Sam can of course consult anyone who he chooses for opinions,
>reviews, etc. However, Alexey's original message indicated
>something rather different. Namely:
>
>
>	Subsequent discussions and consensus calls on the document
>	would happen on <[email-masked]>.
>
>	...
>
>	Alexey,
>	in my capacity of shepherd for draft-hartman-webauth-phishing
>  
>
On rereading my message, it probably came out stronger than I intended.
But according to my English-Russian dictionary the verb "would" can 
convey "polite request", which was my intent.

>This document isn't a WG document and this mailing list is not a WG
>list. It's inappropriate to hold any kind of "consensus calls".
>Moreover, as there's no WG, Alexey isn't the chair and doesn't
>have any authority to run a consensus or any other process.
>  
>
I think you are reading too much into my message.
I didn't say that I will run any consensus calls, shepherding AD has the 
authority to do that.
And you are correct of course that I don't have any authority in this 
case. I am just working for the shepherding AD, trying to help her in 
getting the document through IESG.

>This document was taken to the IESG and didn't achieve consensus
>in LC. It now has the same status as any other random individual
>ID, nothing more nothing less.
>  
>
Yes (the last sentence).

It is not yet clear to me if you have any problems with the document 
being discussed on http-auth mailing list. If you have, can you explain 
why and maybe suggest a better place for discussions?

And if you would like to suggest a better process for moving things 
forward, please share your opinion.

Regards,
Alexey

From: der Mouse <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] Re: [saag] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Date: Mon, 10 Sep 2007 14:28:03 -0000

> I really dislike the use of "fishing" with creative spelling in a
> document prepared for an international standards organization.

Perhaps unfortunately, that is *the* word for the behaviour in
question, at least in English.  It was not invented for the draft, and
"com[ing] up with something [else]" would be *less* descriptive and
would render the document cryptic to the people who's been working
against phishing for years.  Perhaps it's a bad word to use in other
languages, but that should be addressed by the translator(s) in
question, not by mangling the original.

> [...], because it sends a number of very bad messages:

> - it's ok for browser vendors to play fast and loose with security
>   related UI elements such as the lock icon and the URL bar (i.e.,
>   have them controlled by the remote server)

> - it's ok for domain vendors to sell domains that use IDN trickery

> - it's ok for certificate vendors to sell certificates that seem to
>   be tied to some known entity but are in reality tied to a different
>   entity

It appears they *are* OK, pragmatically; at least, the first and third
- and quite possibly the second, for all I know - are continuing with
no apparent backlash.

> All of these are unacceptable and we as users of these services,
> community members, engineers and IETF members should do what we can
> to make sure that they don't happen.

Ideally, yes.  Let me know when you manage to get users to drop every
major Web browser and every major cert vendor because they're insecure
against these attacks - never mind when you find users competent to
even understand the issue, much less evaluate Web browsers and cert
vendors in these regards.

In the meantime, I see nothing wrong (and much right) with a draft that
addresses this problem - or at least tries to - in the world as it is,
rather than the world as you, me, and a tiny minority of other people
would like it to be.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: "Dan Schutzer" <[email-masked]>
To: "'Hallam-Baker, Phillip'" <[email-masked]>, "'Eliot Lear'" <[email-masked]>, "'IETF Discussion'" <[email-masked]>, <[email-masked]>
Subject: RE: [Ietf-http-auth] Re: Next step on web phishingdraft(draft-hartman-webauth-phishing-05.txt)
Date: Mon, 10 Sep 2007 14:25:58 -0000

I agree with Phillips comments and the FSTC stands ready to help

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 9:21 AM
To: Eliot Lear; IETF Discussion; [email-masked]
Subject: RE: [Ietf-http-auth] Re: Next step on web
phishingdraft(draft-hartman-webauth-phishing-05.txt)

> [mailto:[email-masked]] On Behalf 
> Of Eliot Lear

> Perhaps Sam and Lisa can explain a bit more as to what 
> process they intend to use.  It seems that Alexey is 
> providing a forum for discussion to improve the document, and 
> I see nothing wrong with that.  I would imagine that both the 
> IESG and the community will still get their say, so what 
> precisely is the problem?
> 
> This having been said, it seems to me that in order to 
> address EKR's (and perhaps others') concerns, the document 
> will need substantial work.  I welcome efforts to improve 
> that work.  Where should that happen?  Must Sam do it alone?

Its an architecture issue. It is the type of issue that I would like to see
the IAB take up in combination with the other principal stakeholders here -
the banks, the ISPs.

We do have some resources to draw on here, the Anti-Phishing Working Group
and FSTC.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

Date: Mon, 10 Sep 2007 07:04:57 -0700
From: Eric Rescorla <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft	(draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], IETF Discussion <[email-masked]>

At Mon, 10 Sep 2007 08:59:57 +0200,
Eliot Lear wrote:
> 
> 
> Bernard,
> 
> > I agree with EKR here.  Failed consensus is failed consensus.  RFC 2026 
> > does not support the process that has been recommended here. 
> >
> >   
> 
> Perhaps Sam and Lisa can explain a bit more as to what process they 
> intend to use.  It seems that Alexey is providing a forum for discussion 
> to improve the document, and I see nothing wrong with that.  I would 
> imagine that both the IESG and the community will still get their say, 
> so what precisely is the problem?
>
> This having been said, it seems to me that in order to address EKR's 
> (and perhaps others') concerns, the document will need substantial 
> work.  I welcome efforts to improve that work.  Where should that 
> happen?  Must Sam do it alone?

Sam can of course consult anyone who he chooses for opinions,
reviews, etc. However, Alexey's original message indicated
something rather different. Namely:

	Subsequent discussions and consensus calls on the document
	would happen on <[email-masked]>.

	...

	Alexey,
	in my capacity of shepherd for draft-hartman-webauth-phishing

This document isn't a WG document and this mailing list is not a WG
list. It's inappropriate to hold any kind of "consensus calls".
Moreover, as there's no WG, Alexey isn't the chair and doesn't
have any authority to run a consensus or any other process. 

This document was taken to the IESG and didn't achieve consensus
in LC. It now has the same status as any other random individual
ID, nothing more nothing less.

-Ekr

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)
Date: Mon, 10 Sep 2007 06:20:46 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Eliot Lear" <[email-masked]>, "IETF Discussion" <[email-masked]>, <[email-masked]>

> [mailto:[email-masked]] On Behalf=20
> Of Eliot Lear

> Perhaps Sam and Lisa can explain a bit more as to what=20
> process they intend to use.  It seems that Alexey is=20
> providing a forum for discussion to improve the document, and=20
> I see nothing wrong with that.  I would imagine that both the=20
> IESG and the community will still get their say, so what=20
> precisely is the problem?
>=20
> This having been said, it seems to me that in order to=20
> address EKR's (and perhaps others') concerns, the document=20
> will need substantial work.  I welcome efforts to improve=20
> that work.  Where should that happen?  Must Sam do it alone?

Its an architecture issue. It is the type of issue that I would like to =
see the IAB take up in combination with the other principal stakeholders =
here - the banks, the ISPs.

We do have some resources to draw on here, the Anti-Phishing Working =
Group and FSTC.

Date: Mon, 10 Sep 2007 11:17:08 +0100
From: Alexey Melnikov <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Next step on web phishing draft  (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], IETF Discussion <[email-masked]>

Eliot Lear wrote:

> Bernard,
>
>> I agree with EKR here.  Failed consensus is failed consensus.  RFC 
>> 2026 does not support the process that has been recommended here.   
>
> Perhaps Sam and Lisa can explain a bit more as to what process they 
> intend to use.  It seems that Alexey is providing a forum for 
> discussion to improve the document, and I see nothing wrong with that.

Indeed, that is exactly what I was trying to say.

Lisa and Sam suggested to use [email-masked] and I 
thought it made sense.

> I would imagine that both the IESG and the community will still get 
> their say, so what precisely is the problem?

Exactly. It is not like [email-masked] is a closed 
moderated mailing list.

> This having been said, it seems to me that in order to address EKR's 
> (and perhaps others') concerns, the document will need substantial 
> work.  I welcome efforts to improve that work.  Where should that 
> happen?  Must Sam do it alone?

If people can suggest a better place for work on this document, please 
speak up now.

Date: Mon, 10 Sep 2007 08:59:57 +0200
From: Eliot Lear <[email-masked]>
To: IETF Discussion <[email-masked]>, [email-masked]
Subject: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)

Bernard,

> I agree with EKR here.  Failed consensus is failed consensus.  RFC 2026 
> does not support the process that has been recommended here. 
>
>   

Perhaps Sam and Lisa can explain a bit more as to what process they 
intend to use.  It seems that Alexey is providing a forum for discussion 
to improve the document, and I see nothing wrong with that.  I would 
imagine that both the IESG and the community will still get their say, 
so what precisely is the problem?

This having been said, it seems to me that in order to address EKR's 
(and perhaps others') concerns, the document will need substantial 
work.  I welcome efforts to improve that work.  Where should that 
happen?  Must Sam do it alone?

Eliot

Content-class: urn:content-classes:message
Date: Sun, 9 Sep 2007 18:47:58 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "Alexey Melnikov" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] RE: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)

> From: Iljitsch van Beijnum [mailto:[email-masked]]=20

> During the reading of this document, it occurred to me that=20
> HTTP digest authentication (RFC 2617) rather than the widely=20
> used practice of having security credentials be typed into an=20
> HTTP form would achieve 90% of the requirements all by=20
> itself.=20

Well maybe if people had listened to me then :-)

But at this point fifteen years later Digest is not the way to go. First =
Digest was designed under the express constraint of avoiding patent =
encumberances. RSA and D-H were both off the table at the time.

If I was to redo Digest today or expand its scope I would do it =
differently. The main reason I would not is that SAML and WS-* both =
provide an excellent solution. I very much like and support the =
Cardspace idea of building into the O/S platform. I very much like the =
OpenID concept of making the barrier to entry very low. I would like to =
arrive at a happy combination of the existing proposals not see more =
proposals put on the table at this point.

From: Bill Manning <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: [email-masked], [email-masked], Marshall Eubanks <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Date: Sun, 09 Sep 2007 23:51:07 -0000

On Mon, Sep 10, 2007 at 01:21:00AM +0200, Iljitsch van Beijnum wrote:
> On 10-sep-2007, at 0:51, Marshall Eubanks wrote:
> 
> >I tend to rely on Dictionaries to sort these things out - from  
> >Dictionary.com
> 
> Dictionaries are useless, when in doubt they just add definitions.  
> For instance, try figuring out how many bytes there are in a megabyte  
> from a few dictionaries.
> 

`When I use a word,' Humpty Dumpty said, in rather a scornful tone, 
`it means just what I choose it to mean -- neither more nor less.'

--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

From: Iljitsch van Beijnum <[email-masked]>
To: Marshall Eubanks <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Date: Sun, 09 Sep 2007 23:23:36 -0000

On 10-sep-2007, at 0:51, Marshall Eubanks wrote:

> I tend to rely on Dictionaries to sort these things out - from  
> Dictionary.com

Dictionaries are useless, when in doubt they just add definitions.  
For instance, try figuring out how many bytes there are in a megabyte  
from a few dictionaries.

From: Iljitsch van Beijnum <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Date: Sun, 09 Sep 2007 21:41:31 -0000

On 8-sep-2007, at 20:09, Alexey Melnikov 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.

Here's an outsider review.

What's an Ekr, btw?

I really dislike the use of "fishing" with creative spelling in a  
document prepared for an international standards organization. The  
world certainly doesn't need more words that sound the same and  
differ in meaning only by the way they're written, and I'm not sure  
how prevalent this terminology is outside the US and/or the English  
speaking world. Please come up with something more descriptive.

During the reading of this document, it occurred to me that HTTP  
digest authentication (RFC 2617) rather than the widely used practice  
of having security credentials be typed into an HTTP form would  
achieve 90% of the requirements all by itself. (More or less the same  
thing for S/MIME in mail.) The main part that's missing there is  
protection against a man in the middle. Obviously TLS goes through  
great pains to avoid men in the middle, but the document has no  
trouble throwing that out of the window:

    The attacker can also spoof trust markers
    such as the security lock, URL bar and other parts of the browser  
UI.

And:

    Users do not typically understand
    certificates and cannot make informed decisions about whether the
    subject name in a certificate corresponds to the entity they are
    attempting to communicate with.  As a consequence of this  
assumption,
    users will likely be fooled by strings either in website names or
    certificates that look visually similar but that are composed of
    different code points.

Although I agree that a system that can work even under these  
assumptions would be great, I think it's harmful to adopt them in  
this way, because it sends a number of very bad messages:

- it's ok for browser vendors to play fast and loose with security  
related UI elements such as the lock icon and the URL bar (i.e., have  
them controlled by the remote server)

- it's ok for domain vendors to sell domains that use IDN trickery

- it's ok for certificate vendors to sell certificates that seem to  
be tied to some known entity but are in reality tied to a different  
entity

All of these are unacceptable and we as users of these services,  
community members, engineers and IETF members should do what we can  
to make sure that they don't happen.

Last but not least, I'm guessing that "ben Laurie" is actually "Ben  
Laurie".

Date: Sun, 09 Sep 2007 19:30:01 +0100
From: Alexey Melnikov <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] Next step on web phishing draft  (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Eric Rescorla 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 <[email-masked]>.
>>
>>Alexey,
>>in my capacity of shepherd for draft-hartman-webauth-phishing
>>    
>>
>I object to this procedure.
>
>This document has already had an IETF Last Call, where it failed to
>achieve consensus.
>
Ekr, I have to disagree with you.
One objection about the document and one objection about the intended 
status doesn't constitute "failed consensus", considering there are at 
least 8 other people who are in favor of publishing the document. I can 
publish the list of reviewers, if you insist.

>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.
>
I was probably not clear enough in my previous message:
1). The document needs more work.
2). The document needs more reviews. Discussions of future revisions 
should happen on [email-masked]
3). The document was effectively reset to pre-IETF LC state.

>Not liking the result of the previous Last Call is not a sufficient basis for
>issuing another one.
>  
>
This statement taken in isolation is certainly correct. However if the 
original LC didn't ask the right question, don't you think this makes 
answers meaningless?

>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 have support of the shepherding AD.
Do you think this is insufficient?

From: Bernard Aboba <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sat, 08 Sep 2007 23:53:11 -0000

> I object to this procedure.
> 
> 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 agree with EKR here.  Failed consensus is failed consensus.  RFC 2026 
does not support the process that has been recommended here. 

Date: Sat, 08 Sep 2007 13:53:36 -0700
From: Eric Rescorla <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

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 <[email-masked]>.
> 
> Alexey,
> in my capacity of shepherd for draft-hartman-webauth-phishing

I object to this procedure.

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.

-Ekr

Date: Sat, 08 Sep 2007 19:09:14 +0100
From: Alexey Melnikov <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Ietf-http-auth] Next step on web phishing draft  (draft-hartman-webauth-phishing-05.txt)

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 <[email-masked]>.

Alexey,
in my capacity of shepherd for draft-hartman-webauth-phishing