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