Hannes -- for the record EAP Keying Framework is destined
to become a Proposed Standard. It was also developed by a
consensus process in the WG, and extensively discussed
(perhaps even for too long). Not sure its a good example to
use in this discussion. I do agree with your point otherwise,
Hannes Tschofenig kirjoitti:
many of these document are turned into a religious thing and then every time
you suggest something your solution is compared against some of these
documents. As document author you are often not excited about this approach.
* RFC 3693 (Geopriv Requirements)
* EAP Keying Framework
* RFC 4962 containing the Housley criteria
-------- Original-Nachricht --------
Datum: Wed, 22 Aug 2007 09:10:20 -0400
Von: Henning Schulzrinne <hgs(_at_)cs(_dot_)columbia(_dot_)edu>
An: IETF discussion list <ietf(_at_)ietf(_dot_)org>
CC: IESG <iesg(_at_)ietf(_dot_)org>
Betreff: Re: Review of draft-hartman-webauth-phishing-05
Part of the problem may be historical: Requirement documents are a
relatively recent phenomena and likely postdate 2026. I suspect the
original intent of informational documents was to document non-IETF
protocols for the benefit of implementors, as well as record various
other non-standards items such as April 1 poetry or workshop results,
where it is pretty clear that this is the opinion of the author or
some definable group, such as the IAB.
On the other hand, I have yet to see working group-issued
requirements documents being used for anything except shadow boxing
(and, occasionally, recording some early WG thinking), so maybe we
shouldn't take them too seriously.
Rather than an IESG note or in addition to, I think the author should
clearly state, in the abstract, that this is a personal opinion only.
On Aug 22, 2007, at 7:47 AM, Sam Hartman wrote:
Ah. I must admit that I find the whole concept of informational
documents a heck of a lot less useful, but your reading of 2026 is of
course correct. I'll probably still end up treating informational
documents as close to ietf consensus statements (but not
recommendations) in my head because honestly I cannot find any other
way to think about it that makes any sense to me. I certainly view an
informational docmuent that has gone through an ietf last call as a
statement from the IETF. We'll add this to one of the many areas
where I completely fail to get RFC 2026.
I definitely don't want to block other work with this document. I
think that to be particularly useful I'd like to get to a point where
we can say that having authentication schemes that meet these
requirements would be useful and that for some value of we
significantly greater than me, we think that would be a useful step
along the road to combatting phishing. I thought I was trying to have
that discussion here; you at least seem to think that is not the case.
At some future point we might charter work with the goal of doing
something similar to those requirements; in such a case, we might
decide to hold that work to these requirements. We're not discussing
doing that today.
If I believe there is a reasonable chance of success I'm willing to
put in significant effort towards achieving my goal. Absent that
belief I'm more interested in getting something out and working on
So, Here is a proposed IESG note that I think is consistent with my
intent and RFC 2026:
This document proposes requirements for HTTP authentication that are
intended to help combat the problem of phishing. These requirements
attempt to reduce the consequences of a user being tricked into using
a server provided by an attacker instead of the server they intended
to trust. These requirements have no normative force; publication of
these requirements does not bind future work to follow them.
Ietf mailing list
Ietf mailing list
Ietf mailing list