Subject: [Gen-art] Gen-ART review of draft-ietf-lemonade-deployments-04

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 07 Feb 2007 20:28:16 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-lemonade-deployments-04.txt
Reviewer: Vijay K. Gurbani
Review Date: Wed., Feb 07, 2007
IESG Telechat date: 08 Feb 2007

Summary: This draft is basically ready for publication, but has
nits that should be fixed before publication.

Comments: This draft discusses some interesting issues for
deployment of mobile email when using the TCP transport.  More
feedback is below, with substantive comments first followed
by nits.

Substantive comments:

1) In S4, I find it rather odd that the first paragraph takes
  pains to mandate the use of TCP just to have the second para-
  graph negate that by saying that it is okay to use HTTP for
  webmail instead of opening a direct TCP connection.  I am
  unsure what is required: is TCP a MUST, or alternative
  transports like HTTP are okay?

2) In S4.2, would it help to have a MUST strength for
  turning off TCP keepalives?  More so since it is also harmful
  for dormancy (as discussed in S5.)

3) In S6, please consider providing a reference for supporting
  the sentence "There is a body of best practices based on long
  experience in this area."  It may help the reader if he/she
  wants to explore this area in some more detail.

4) In S8, please consider putting a reference for STARTTLS
  extensions (it is described in RFC3207.)

Nits:

1) Just a suggestion: please consider expanding acronyms on
  first use.
2) In S3, may be a good idea to provide a reference for
  IMAP and Message Submission in the first sentence of the
  opening paragraph.
3) S4, second paragraph: s/marjup/markup

Thank you.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Randall Gellens <[email-masked]>
Date: Wed, 7 Feb 2007 23:29:14 -0800

>  http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Thanks for reviewing it.

>  or AD before posting a new version of the draft.

Sorry, I sent in an -05 version earlier this week, based on all 
comments that had been received during IETF last call (just a few 
nits).  However, it will be easy for me to produce an -06 and send 
that in.

>   transports like HTTP are okay?

The intent of S4 is to mandate support for TCP.  The intent of the 
webmail/HTTP text is to explain that, if TCP can't be supported, 
while some form of mail can be offered, it isn't lemonade.  Perhaps 
this can be made more clear by changing the start of that paragraph 
from "For environments" to "Note that, for environments", and 
changing the end from "must also be limited." to "must also be 
limited, and can't be lemonade compliant."

>   for dormancy (as discussed in S5.)

I'm fine with that, but I'd have to ask the AD and chairs if such a 
change requires an explicit blessing by the WG (if so, this could 
likely be done with a quick call for consensus rather than a new WGLC 
and IETF LC).

>   wants to explore this area in some more detail.

A reference would be nice, and I had tried to find a suitable one, 
but wasn't able to find one that I felt was OK for an RFC (e.g., not 
a wikipedia entry).  If you have a suggestion I'd appreciate it.

>   extensions (it is described in RFC3207.)

I can do that.  It would be 3207 for SMTP and 2595 for IMAP.

>  1) Just a suggestion: please consider expanding acronyms on

I tried to follow a practice of expanding acronyms on first use 
except those that are in such wide use within the email area that 
doing so might be distracting (such as TLS, POP, IMAP, SMTP), but if 
it makes the document easier for non-experts to read, I'd be happy to 
expand others.  Are there particular ones that you suggest expanding?

>   IMAP and Message Submission in the first sentence of the

OK.

>  3) S4, second paragraph: s/marjup/markup

Fixed in -05.

>  Thank you.

Thank you for the detailed review -- I appreciate it.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
A successful tool is used to do something undreamed of by its author.
                                                           --Johnson

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 08 Feb 2007 09:30:15 -0600

> Thanks for reviewing it.

Randy: No problem; my pleasure.  As always, I learn more
from reviewing ;-)

More inline.

> webmail/HTTP text is to explain that, if TCP can't be supported, while 
> some form of mail can be offered, it isn't lemonade.  Perhaps this can 
> be made more clear by changing the start of that paragraph from "For 
> environments" to "Note that, for environments", and changing the end 
> from "must also be limited." to "must also be limited, and can't be 
> lemonade compliant."

Yes, that should do it.  The intent will be much more clearer
with the edits you suggest above.

> change requires an explicit blessing by the WG (if so, this could likely 
> be done with a quick call for consensus rather than a new WGLC and IETF 
> LC).

I will leave it up to you.  My experience has been that implementors
pay more attention to the MUSTs than they do to the SHOULDs.  And
since the text referenced by this "SHOULD NOT" potentially injects
more unwanted traffic in the Internet in the form of opening new
connections, I assumed that a MUST-level strength inhibiting this
behavior is better for the Internet at large.

> A reference would be nice, and I had tried to find a suitable one, but 
> wasn't able to find one that I felt was OK for an RFC (e.g., not a 
> wikipedia entry).  If you have a suggestion I'd appreciate it.

A couple of places come to mind:

1) comp.security.firewalls FAQ - Take a look at S5 in there; it
  talks about "How Do I..." to get traffic through a firewall.
  The FAQ is archived at http://www.faqs.org/faqs/firewalls-faq/.
  Having said that, I will note that the FAQ is fairly dated
  (Dec 2000.)  But, its maintainers are Marcus Ranum and Matt
  Curtin.  Of these, I have heard of Marcus' name in the security
  field quite a bit, and I dare say that someone in Gen-ART or
  the IETF security directorate may know him and can maybe ask
  him on current literature on firewall avoidance.  FWIW, Marcus'
  email is provided on the FAQ page.

2) P2P literature.  By its nature, P2P networks have to work
  across firewalls.  Liang et al. [1] discuss some techniques
  (very briefly) in P2P networks.

  [1] J. Liang, R. Kumar, K.W. Ross, "The KaZaA Overlay: A
  Measurment Study," Computer Networks Journal, Elsevier, 2005.
  Archived at http://photon.poly.edu/~rkumar04/KazaaOverlay.pdf.

> I tried to follow a practice of expanding acronyms on first use except 
> those that are in such wide use within the email area that doing so 
> might be distracting (such as TLS, POP, IMAP, SMTP), but if it makes the 
> document easier for non-experts to read, I'd be happy to expand others.  
> Are there particular ones that you suggest expanding?

No, not really.  To anyone conversant in this domain, the acronyms
should be easily understood.  I was more worried about non-experts.
But I am also unsure how much to bend backwards to accomodate them.
I agree with you that the ones you mention above should be well known
by anyone in the field.  I also agree that expanding well-known
acronyms simply distracts.  In the end, I will simply leave it to
your sound editorial discretion.

Thanks,

- vijay