[If my signature is missing at the end of this message, it means the mail got truncated. Please let me know if that is the case] I have reviewed the above document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed:   draft-harkins-salted-eap-pwd-06 Status: Ready with comments. Summary: This document defines a method to add support for salted passwords in their use with EAP-pwd. Salted passwords are passwords that are stored after they have been “salted” with a “salt” to prevent passwords from being guessed. The document is informational but does present ways that require the existing mechanism for password authentication to be changed. Specifically, salting of a password is treated as an additional password pre-processing technique of EAP-pwd. There is discussion around how the payload would need to be modified. It even uses language from RFC 2119 like SHOULD, SHOULD NOT, SHALL, MUST NOT etc. which makes you wonder why the document is informational in nature. In the authors defense, the document it is updating is also informational in nature. Management considerations: The draft talks briefly about the protocol modifications that need to happen to deploy the solution. In particular, it refers to how multiple salt digests can be supported simultaneously; essentially by having multiple password databases. But it the refers to a “routable portion of client identity”, but is not clear on what that client identity could be. If the references are derived from another document, they need to stated where the terms are being derived from. Similarly, the draft talks about client indicating its acceptance of the password pre-processing technique. What it does not talk about is what happens if the client does not accept any of the techniques? What does it send back? If this is part of the base EAP-pwd protocol, can it be stated so? The draft talks about when the client and server can start fixing the password element. Specifically, it says that the client cannot start fixing the password element till it receives a EAP-pwd-Commit/Request. It appears that the client cannot send any data till that message is received. What happens if it never gets that message. Does it disconnect and retry, or can it poke the server to send the message again? Again, if this is described somewhere else, it would be helpful to know where. Fault management: The draft should document how any failures or faults are tracked. For example, if the salt length does not meet the requirements, how is that reported? Similarly, if the client drops a session because it could not come to an agreement with the server on password pre-processing technique, how is that information propagated?  Fault determination: If a client is not able to connect to the server, how is an operator supposed to determine whether the issue is on the client or the server side? Configuration management: How are the new password pre-processing techniques configured on the server? Verifying correct operation: The draft needs to talk about how the new technique can be tested for correct behavior. While the client able to communicate with the server is certainly one indication, it would be helpful to know that it is because of the new technique. Account management: The draft also needs to consider how to collect usage information related to the technique, and what information needs to collected. A lot of times usage information is used to determine capacity, do trend analysis, calculate cost allocation, auditing and billing. Impact: Finally, the draft should talk about the impact of deploying the new techniques. For example, what would be the impact of choosing and computing for this requirement both in terms of any specialized hardware that might be needed and/or if done in software, the impact on CPU for the new technique. A run of idnits revealed one issue that might need to be addressed:   ----------------------------------------------------------------------------   == The 'Updates: ' line in the draft header should list only the _numbers_      of the RFCs which will be updated by this document (if approved); it      should not include the word 'RFC' in the list. Thanks Mahesh Jethanandani mjethanandani at gmail.com