The Internet Email to Support Diverse Service Environments (Lemonade) Profile
draft-ietf-lemonade-profile-bis-12
Yes
(Chris Newman)
(Lisa Dusseault)
No Objection
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 12 and is now closed.
Chris Newman Former IESG member
Yes
Yes
()
Unknown
Lisa Dusseault Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2009-03-12)
Unknown
Good work. Its nice to see an explanation how to use existing protocol components to deal with the limits of a particular environment. I would have voted Yes on this if it weren't for the fact that I'm not sufficiently familiar with all parts of the protocol set to say for sure that you didn't miss anything.
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
(2009-03-11)
Unknown
INTRODUCTION, paragraph 2: > The Lemonade Profile Title doesn't describe the content. Title of RFC4550 was much clearer. Suggest to use it.
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
(2009-03-11)
Unknown
Hannes Tschofenig's SecDir review identified a couple of places that would benefit from some clarification of the text, and provided editorial comments that should be taken into acccount.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2009-03-11)
Unknown
The 2nd paragraph of Section 7 says: > > Note that the explicit usage of [SUBMIT] means that when opening a > connection to the submission server, clients MUST do so using port > 587 unless explicitly configured to use an alternate port [RFC5068]. > If the TCP connection to the submission server fails to open using > port 587, the client MAY then immediately retry using a different > port, such as 25. See [SUBMIT] information on why using port 25 is > likely to fail depending on the current location of the client, and > may result in a failure code during the SMTP transaction. > It is unclear to me if this is a new MUST requirement or if it is intended to be clarification od one that is already in [SUBMIT]. Please add text to clear this up.
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2009-03-12)
Unknown
Shouldn't this document update 4469 and 4467 since it adds a new capability (URL-PARTIAL) to the CATENATE and URLAUTH extensions? I also think the definition of the new URL-PARTIAL capability should be added to the replacement for section 12 (summary of changes wrt 4550).