Document: draft-ietf-sieve-managesieve-05.txt Reviewer: Miguel Garcia Review Date: 29 December 2008 IESG Telechat date: 18 December 2008 IETF LC End Date: 30 December 2008 Summary: The document is ready for publication as a proposed standard RFC. Major issues: none Minor issues: - Section 1.2 could be slightly improved to guide the reader over the rest of the document by describing, at the very beginning, that "this is a command-response protocol based on a client/server architecture. The client emits a command; the server processes the command and replies with a response" (or something like that). I am also missing a sentence indicating that "the protocol runs over any connection-oriented transport protocol, although at the moment, TCP (and TCP over TLS) are the only defined transport protocols". - Section 2.1 (towards the end) has a discussion about the STARTTLS command and the mechanism to protect against a MITM bid-down attack. The text says: Once a SASL security layer is established, the server MUST re-issue the capability results, followed by an OK response. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to SASL negotiation. The capability results MUST include all SASL mechanisms the server was capable of negotiating with that client. This is done in order to allow the client to detect active down-negotiation attack. What I am missing here is some normative text that instructs clients to do an action (which one would that be?) if such MITM bid-down attack is detected by the client. Nothing is written so far, and I suspect that client will not implement any action if it isn't clearly indicated. Nits/editorial comments: - idnits reveals that references [DIGEST-MD5] and [IANA-GUIDELINES] are declared in Section 9.2, but never used. There should be an anchor in the text or the reference should be deleted. - idnits reveals that references to RFC 4366 and RFC 3280 are obsolete. The updated references are RFC 5246 and RFC 5280, respectively. - there are a couple of "anchors" in the text. Just make sure these are deleted before publication, in particular anchor8, which describes Chris Newman's thoughts.