Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
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 value found for 'p.get_dochistory.rev' **)
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 value found for 'p.get_dochistory.rev' **)
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.