Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
RFC 5421

Note: This ballot was opened for revision 05 and is now closed.

(Jari Arkko) (was Discuss) Yes

(Tim Polk) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) No Objection

Comment (2008-08-11 for -)
No email
send info
The document writeup says "This is not the product of any working group.  This is part of the
ongoing effort to document existing deployed EAP methods.  The purpose of this document is to publish existing behavior." That doesn't come out in the document at all. I wonder if this should be explicitly called out in the abstract and/or introduction?

(Pasi Eronen) (was Discuss) No Objection

(Cullen Jennings) No Objection

(Chris Newman) (was Discuss) No Objection

Comment (2008-08-14 for -)
No email
send info
I support Pasi's discuss.  For the point about "appropriate language and
charset", I recommend referencing RFC 5198.  The same issue applies to
the CHALLENGE=.

I'm a bit concerned about having a fixed list of error codes.  This was
a mistake for SMTP, and sites reject passwords for so many reasons, 
there's always a new one.  However, there are four general classes
of client behavior in response to an authentication failure here:

1. re-prompt for username/password.
2. give up, typically inviting user to make a support call
3. change password
4. notify user of temporary service outage, suggest they try again later

The distinction between these three can have profound impact on the
cost to operate a service.  While I can identify (1) - 691, several
cases of (2), and (3) - 648, I don't see an error code that means (4).
While 646 is a specific sub-case of (4), you need the general case.

(Dan Romascanu) No Objection