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, though. Jari Hannes Tschofenig kirjoitti: > Hi Henning, > > 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. > > Examples: > * RFC 3693 (Geopriv Requirements) > * EAP Keying Framework > * RFC 4962 containing the Housley criteria > > Ciao > Hannes > > -------- Original-Nachricht -------- > >> Datum: Wed, 22 Aug 2007 09:10:20 -0400 >> Von: Henning Schulzrinne <hgs@xxxxxxxxxxxxxxx> >> An: IETF discussion list <ietf@xxxxxxxx> >> CC: IESG <iesg@xxxxxxxx> >> 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. >> >> Henning >> >> 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 >>> running code. >>> >>> >>> 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@xxxxxxxx >>> https://www1.ietf.org/mailman/listinfo/ietf >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www1.ietf.org/mailman/listinfo/ietf >> > > > > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf