Document: draft-ietf-lemonade-profile-bis-12
Reviewer: Robert Sparks
Review Date: 6 March 2009
IESG Telechat date: 12 March 2009

Summary: Ready for publication as Proposed Standard

All the comments below have been responded to.

The editor disagrees that any change is needed to address comments 2 and 5 below.

I do not object to publishing this document without these changes, but still feel it would be an improvement. Please consider point 5 in particular.

Note: comments below extracted from IETF-LC review at:
http://www.softarmor.com/rai/temp-gen-art/draft-ietf-lemonade-profile-bis-11-sparks.txt


> 2) It's not clear whether the Forward without Download section is  
> intended to be "Here's a couple of ways you can realize this feature  
> if you have all the tools this profile requires available to you" or  
> "If you are going to realize this feature, please do it this way" or  
> "You MUST choose one of these ways if you are going to realize this  
> feature". It would help to make the abstract, introduction, and the  
> first part of section 8 more explicit. Similarly, the draft is  
> registering a keyword to use in a CAPABILITY response - it would  
> help if the abstract and section 5.7.1 made this very explicit.
>


>
> 5) Section 7 paragraph 2: Is this document attempting to restate  
> RFC4409 requirements or make new ones that are different? If its  
> just pointing out consequences of following 4409, I strongly  
> encourage you to rewrite this paragraph without using 2119 words.  
> For instance, "When following the requirements stated in [SUBMIT] a  
> client will either connect to an explicitly configured port at the  
> submission server, or will default first to 587. [SUBMIT] allows  
> subsequent attempts at other ports, including  25, if the initial  
> attempt fails. See [SUBMIT] for information on why using port 25 is  
> likely to fail ..."
>