Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt

From: [email-masked]
Date: Fri, 12 May 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF.

	Title		: Deployment Considerations for lemonade-compliant Mobile Email
	Author(s)	: R. Gellens
	Filename	: draft-ietf-lemonade-deployments-02.txt
	Pages		: 11
	Date		: 2006-5-12
	
This document discusses deployment issues and describes requirements
for successful deployment of mobile email which are implicit in the
IETF lemonade documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-lemonade-deployments-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-lemonade-deployments-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: <[email-masked]>
Date: Mon, 15 May 2006 12:34:48 +0300

Hi all,
A few comments/questions:

Section 4.2 "due to handoffs"-> is it referring to handovers?

Section 6. "Firewalls exist to block traffic," can we rephrase this to "Firewalls exist to block undesired traffic," (unidentified, unsafe, restricted) or something like that?

Section 6. "There is a body of best practices based on long experience in this area." Should there be a reference here? (Section 8 does not mention any.)

Section 6. "One or more firewalls might exist..." Should this paragraph mention something about outband notifications (that those should be allowed too, otherwise it's useless)?

Section 6. "Application proxies, which are a not uncommon mechanism, are discussed in [PROXIES]." double negative, "are a not uncommon mechanism"-> "are a common mechanism"?

Section 7. " NAT boxes which are deployed between client and server systems SHOULD be configured to have extremely long connection lifetimes. Unlimited lifetimes are RECOMMENDED." I am no NAT expert, so I do not know how NAT sessions are reserved or anything. Is it possible to set the connection lifetime per session or only globally? I mean, if there is email traffic, You want it high, otherwise You might want to keep it low(er). If it can be set only globally and there are many email sessions there will be several NAT sessions, each NAT session taking up memory - and probably not all routers are equipped with a big memory so I guess after a while they will run out. When they do, something will happen - and this can be abuse as a DoS attack. So do we really want to recommend long/permanent NAT sessions? (Or, should we mention the DoS attack in Section 8?)

Section 10. I want to be listed here ;-)

Section 11. [PROFILE] Will draft-ietf-lemonade-deployments-xx.txt be part of bis, or will it reference it? I mean - this reference is in the normative section - if it's going to be part of the bis, then there is no need to have the normative reference here, right? [SUBMISSION] is in the informative section as well.

Section 12. [FIREWALLS] Excuse my ignorance, but what is the concept for "normative" and "informative" reference in IETF? Isn't is so that the "normative" references contain all "MUST" documents? Section 6 mentiones this reference as a MUST.

Section 12. [HOST-REQUIREMENTS] Section 4 mentioned this as a "SHOULD" - should it be in the normative section (same as the comment above).

Generic questions:
Will a new port number be standardized for email traffic/outband notification? (Where the server can contact the client with notification, or where the client can contact the server [to aid section 6.1 of the draft]?)

This draft is a very good read (both content and readability-wise).
Thank You.

Best regards: Zoltán Ördögh
E-mail: [email-masked]
Phone: +358 50 386 0566

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: 12 May, 2006 22:50
To: [email-masked]
Cc: [email-masked]
Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt 

	
This document discusses deployment issues and describes requirements for successful deployment of mobile email which are implicit in the IETF lemonade documents.

To remove yourself from the I-D Announcement list, send a message to [email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then
	"get draft-ietf-lemonade-deployments-02.txt".

A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Send a message to:
	[email-masked].
In the body type:

---

From: Dave Cridland <[email-masked]>
Date: Mon, 15 May 2006 13:05:02 +0100

Some meta-comments, and comments of my own you've reminded me to 
bring up on the list:

On Mon May 15 10:34:48 2006, [email-masked] wrote:
> Section 6. "Firewalls exist to block traffic," can we rephrase this 
> to "Firewalls exist to block undesired traffic," (unidentified, 
> unsafe, restricted) or something like that?
> 
> 
I think the way it's phrased is fine - firewalls do exist to block 
traffic, they're deployed to block undesired traffic, but they quite 
often block desired traffic in practise, which is largely what this 
section is concerned with.

> Section 6. "There is a body of best practices based on long 
> experience in this area." Should there be a reference here? 
> (Section 8 does not mention any.)
> 
> 
Section 8 carries no references, but does discuss best practises. I 
can't immediately think of any RFCs that could be referenced here.

> Section 6. "One or more firewalls might exist..." Should this 
> paragraph mention something about outband notifications (that those 
> should be allowed too, otherwise it's useless)?
> 
> 
Well, this is problematic, because we have no outbound notification 
methods right now within Lemonade.

> Section 6. "Application proxies, which are a not uncommon 
> mechanism, are discussed in [PROXIES]." double negative, "are a not 
> uncommon mechanism"-> "are a common mechanism"?
> 
> 
It's a native speaker thing, I'm afraid - to my (en_GB) ears, "not 
uncommon" suggests less deployment than "common" (which could suggest 
almost ubiquitous deployment), as well as suggesting there's no 
desire on the part of the author for it to become common. (Also seen 
in phrases such as "I wouldn't disagree", which indicates a 
reluctance to actually agree.) The readable nature of the document 
does tend to increase the number of idiomatic phrases, perhaps you 
might want to go through and highlight any more you find?

> Section 7. " NAT boxes which are deployed between client and server 
> systems SHOULD be configured to have extremely long connection 
> lifetimes. Unlimited lifetimes are RECOMMENDED." I am no NAT 
> expert, so I do not know how NAT sessions are reserved or anything. 
> Is it possible to set the connection lifetime per session or only 
> globally? I mean, if there is email traffic, You want it high, 
> otherwise You might want to keep it low(er). If it can be set only 
> globally and there are many email sessions there will be several 
> NAT sessions, each NAT session taking up memory - and probably not 
> all routers are equipped with a big memory so I guess after a while 
> they will run out. When they do, something will happen - and this 
> can be abuse as a DoS attack. So do we really want to recommend 
> long/permanent NAT sessions? (Or, should we mention the DoS attack 
> in Section 8?)
> 
> 
Memory is not a serious issue for the kinds of NAT deployment we're 
looking at here. For mobile networks, a Linux box with a few G of RAM 
will have perfectly good performance, and quite enough memory. 
(Apparently each connection is 350 bytes of non-swappable kernel 
memory, so with 0.5G of RAM you can support over a million 
connections, so with a 64-bit memory address and a reasonable load of 
RAM, that should keep everyone happy).

> Section 11. [PROFILE] Will draft-ietf-lemonade-deployments-xx.txt 
> be part of bis, or will it reference it? I mean - this reference is 
> in the normative section - if it's going to be part of the bis, 
> then there is no need to have the normative reference here, right? 
> [SUBMISSION] is in the informative section as well.
> 
> 
I mentioned to Randy that I wasn't clear it should be referencing 
bis. Nothing in this document refers to anything beyond the original 
profile.

Normally, I'd be keen to see the latest version of a document be 
referenced, but in this case, I personally see the different profile 
versions as different "levels of support", and I suspect that we'll 
see deployments of Lemonade services earlier than Lemonade Bis, and 
those early deployments will need this advice most - I'd be wary of 
making it appear that this advice applies to Lemonade Bis, not 
Lemonade.

In addition, referencing Profile means the document should be 
available as an RFC much sooner.

Profile Bis can quite easily reference this, of course, that's 
another matter entirely.

> Generic questions:
> Will a new port number be standardized for email traffic/outband 
> notification? (Where the server can contact the client with 
> notification, or where the client can contact the server [to aid 
> section 6.1 of the draft]?)
> 
> 
If it needs a port number, it would be standardized, as a general 
rule. (Not everything does need a port number, for instance it could 
use SRV records, but that's probably not a good idea in this case).

> This draft is a very good read (both content and readability-wise).

I agree, it's enjoyable enough to read that it will get read.

> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-deployments-02.txt

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: <[email-masked]>
Date: Tue, 16 May 2006 11:00:29 +0300

Hi Dave, thank You.
I addded a few comments below some of yours. (Marked with "[ZÖr]").

-----Original Message-----
From: ext Dave Cridland [mailto:[email-masked]] 
Sent: 15 May, 2006 15:05
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere)
Cc: Enhancements to Internet email to support diverse service enivronments
Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt 

Some meta-comments, and comments of my own you've reminded me to bring up on the list:

On Mon May 15 10:34:48 2006, [email-masked] wrote:
> Section 6. "Firewalls exist to block traffic," can we rephrase this to 
> "Firewalls exist to block undesired traffic," (unidentified, unsafe, 
> restricted) or something like that?
> 
> 
I think the way it's phrased is fine - firewalls do exist to block traffic, they're deployed to block undesired traffic, but they quite often block desired traffic in practise, which is largely what this section is concerned with.

> Section 6. "There is a body of best practices based on long experience 
> in this area." Should there be a reference here?
Section 8 carries no references, but does discuss best practises. I can't immediately think of any RFCs that could be referenced here.

Well, this is problematic, because we have no outbound notification 
methods right now within Lemonade.
[ZÖr] You surely have UDP. It's not the content LEMONADE needs to worry about - it's the possibility to deliver it whatever it is. If firewalls block them, it renders mobile email pretty much useless (remember that there might be software firewalls on the clients, too which are not necessarily in the control of the user).

[ZÖr] I read through it, but did not find any others. I am not a native English, so if it sounds just fine for Your ears then let's forget it.

[ZÖr] :-) Oh, that's nice to hear.

If it needs a port number, it would be standardized, as a general 
rule. (Not everything does need a port number, for instance it could 
use SRV records, but that's probably not a good idea in this case).
[ZÖr] If there was no standardized port number for email traffic (especially outband notifications), then all these communications would be blocked - another dead technology invented: not going to work outside of the provider's domain (there goes roaming and mobile email).

Dave.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 May 2006 15:59:20 -0700

>  Section 4.2 "due to handoffs"-> is it referring to handovers?

The term "handover" is a new one to me.  I am used to hearing 
"handoff" but since I am not familiar with "handover" I can't say if 
the terms are the same or not.

> unsafe, restricted) or something like that?

Firewalls do exist to block traffic.  The desired versus undesired 
distinction gets into the main points of the document.

> (Section 8 does not mention any.)

I am not aware of a single, or even small set, of references that 
would do justice to the topic.  The intent of the phrasing is to let 
readers know that a lot of work has gone on in this area over a long 
period of time, and that readers should not make simplistic 
assumptions.

> should be allowed too, otherwise it's useless)?

I'd be very happy to mention server to client notifications outside 
of IMAP and submission, but my understanding is that this has not 
been agreed to yet as an IP-based mechanism.  I suppose I could 
mention RFC 4146, but that seems silly.

> uncommon mechanism"-> "are a common mechanism"?

The "not uncommon" expression is used to indicate a prevalence that 
is between "uncommon" and "common".  I could perhaps say 
"unfortunately becoming more common" if that is more clear.

> long/permanent NAT sessions? (Or, should we mention the DoS attack 

If the number of idle sessions becomes large enough to deplete 
memory, the NAT box will remove the least recently used ones, as the 
text says.  I apologize, but I don't see the problem with the current 
wording, or the DoS attack (or at least any that the current wording 
makes more likely).  Can you explain the problem as you see it?

>  Section 12. [FIREWALLS] Excuse my ignorance, but what is the 
> concept for "normative" and "informative" reference in IETF? Isn't 
> is so that the "normative" references contain all "MUST" documents? 
> Section 6 mentiones this reference as a MUST.
>
>  Section 12. [HOST-REQUIREMENTS] Section 4 mentioned this as a 
> "SHOULD" - should it be in the normative section (same as the 
> comment above).

I can move the references around if need be; thanks for pointing this out.

The issue of referencing Profile versus Profile-bis is one that Dave 
mentioned to me; my response at the time was that I personally don't 
care at all either way, so if people feel strongly or have specific 
reasons to go with one or the other, please speak up.

> section 6.1 of the draft]?)

If we come up with an IP-based notification service, then a 
standardized port would make sense.

>  This draft is a very good read (both content and readability-wise).

Thank you.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
A fail-safe circuit will destroy others.  A transistor protected by a
fast-acting fuse will protect the fuse by blowing first.  After the
last of 16 mounting screws has been removed from an access cover, it
will be discovered that the wrong access cover has been removed.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 May 2006 16:05:55 -0700

At 11:00 AM +0300 5/16/06, <[email-masked]> wrote:

>  [ZÖr] You surely have UDP. It's not the content 
> LEMONADE needs to worry about - it's the 
> possibility to deliver it whatever it is. If 
> firewalls block them, it renders mobile email 
> pretty much useless (remember that there might 
> be software firewalls on the clients, too which 
> are not necessarily in the control of the user).

UDP is a transport (like TCP).  Lemonade does not 
currently have a specific notification protocol. 
It could specify the content and format of 
notifications, a protocol for them, and allowable 
transports (such as UDP).  When it does specify a 
protocol, a port should be allocated, and this 
port should be listed in the deployments draft 
(or an update of it).

>  [ZÖr] If there was no standardized port number 
> for email traffic (especially outband 
> notifications), then all these communications 
> would be blocked - another dead technology 
> invented: not going to work outside of the 
> provider's domain (there goes roaming and 
> mobile email).

Then let's specify a protocol (and of course 
port) for server to client notifications outside 
of IMAP, for example, to be invoked by Sieve 
scripts.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Some days you feel like Schrodinger's cat.   --M. S. Hutchenreuther

---

From: <[email-masked]>
Date: Thu, 18 May 2006 11:30:14 +0300

Thank You for Your response Randall,
I added a few questions/comments to Yours - these are tagged with [ZÖr].

-----Original Message-----
From: ext Randall Gellens [mailto:[email-masked]] 
Sent: 18 May, 2006 01:59
To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); [email-masked]
Subject: RE: [lemonade] I-D ACTION:draft-ietf-lemonade-deployments-02.txt

>  Section 4.2 "due to handoffs"-> is it referring to handovers?

The term "handover" is a new one to me.  I am used to hearing "handoff" but since I am not familiar with "handover" I can't say if the terms are the same or not.
[ZÖr] :-) Good GSM terminology :-) Handover is the procedure that takes place when a mobile terminal moves from one BTS to another. I would guess "handoff" could refer to a failed handover. Not sure though - this is why I asked.

> unsafe, restricted) or something like that?

Firewalls do exist to block traffic.  The desired versus undesired distinction gets into the main points of the document.

> (Section 8 does not mention any.)

I am not aware of a single, or even small set, of references that would do justice to the topic.  The intent of the phrasing is to let readers know that a lot of work has gone on in this area over a long period of time, and that readers should not make simplistic assumptions.
[ZÖr] I try to read all the specs as a dumb person would do who does not know anything - the first thing that came to my mind here was. "oh, good, where can I find those?"

> should be allowed too, otherwise it's useless)?

I'd be very happy to mention server to client notifications outside of IMAP and submission, but my understanding is that this has not been agreed to yet as an IP-based mechanism.  I suppose I could mention RFC 4146, but that seems silly.
[ZÖr] so the first question here is: do we need an IP-based notification mechanism? I would say yes.

>
>  Section 6. "Application proxies, which are a not uncommon mechanism, 
> are discussed in [PROXIES]." double negative, "are a not uncommon 
> mechanism"-> "are a common mechanism"?

The "not uncommon" expression is used to indicate a prevalence that is between "uncommon" and "common".  I could perhaps say "unfortunately becoming more common" if that is more clear.
[ZÖr] Ah, now I got it. Dave explained somewhat differently. But in the end I think that this latter one would be a better option.

> lifetimes. Unlimited lifetimes are RECOMMENDED." I am no NAT expert, 
> so I do not know how NAT sessions are reserved or anything.
> globally and there are many email sessions there will be several NAT 
> sessions, each NAT session taking up memory - and probably not all 
> routers are equipped with a big memory so I guess after a while they 
> will run out. When they do, something will happen - and this can be 
> abuse as a DoS attack. So do we really want to recommend 
> long/permanent NAT sessions? (Or, should we mention the DoS attack in 
> Section 8?)

If the number of idle sessions becomes large enough to deplete memory, the NAT box will remove the least recently used ones, as the text says.  I apologize, but I don't see the problem with the current wording, or the DoS attack (or at least any that the current wording makes more likely).  Can you explain the problem as you see it?
[ZÖr] Dave clarifired this to me - my worry was the "unlimited lifetime" and the not-so-unlimited number of concurrent NAT sessions; and that it can be exploited. According to Alexey's explanation it is not an issue - but I wonder if anyone will come up with the same questions later - the words "unlimited" and "infinite" are raising a lot of questions ususally.

> be part of bis, or will it reference it? I mean - this reference is in 
> the normative section - if it's going to be part of the bis, then 
> there is no need to have the normative reference here, right?
>  Section 12. [FIREWALLS] Excuse my ignorance, but what is the concept 
> for "normative" and "informative" reference in IETF? Isn't is so that 
> the "normative" references contain all "MUST" documents?
> "SHOULD" - should it be in the normative section (same as the comment 
> above).

I can move the references around if need be; thanks for pointing this out.
[ZÖr] Before You do first I would like to undestand what qualifies as a normative and an informative reference. You have a reason why You wrote it like this - I would like to understand why (so that I can avoid dumb questions in the future).

The issue of referencing Profile versus Profile-bis is one that Dave mentioned to me; my response at the time was that I personally don't care at all either way, so if people feel strongly or have specific reasons to go with one or the other, please speak up.
[ZÖr] I think Profile does not mention this document, while Profile-bis does. Since Profile-bis does reference this document, does this document have to refer to Profile-bis as a normative reference? One could argue (me, hehe) that this document is valid for the plain old IMAP as well, so why reference Profile(-bis) normatively? Perhaps this just comes from the fact that I do not yet understand the point behind normative and informative references in IETF.

> section 6.1 of the draft]?)

If we come up with an IP-based notification service, then a standardized port would make sense.

Thank you.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: --------------- A fail-safe circuit will destroy others.  A transistor protected by a fast-acting fuse will protect the fuse by blowing first.  After the last of 16 mounting screws has been removed from an access cover, it will be discovered that the wrong access cover has been removed.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 May 2006 17:31:08 -0700

>  I added a few questions/comments to Yours - these are tagged with [ZÖr].

Unfortunate that your client doesn't support RFC 
3676 (format=flowed) and hence doesn't do proper 
quote identification.

>  [ZÖr] :-) Good GSM terminology :-) Handover is 
> the procedure that takes place when a mobile 
> terminal moves from one BTS to another. I would 
> guess "handoff" could refer to a failed 
> handover. Not sure though - this is why I asked.

Handoff, as I understand it, is the same as your 
explanation of handover.  No failure is implied. 
(There are "hard" versus "soft" handoffs, but 
that's besides the point.)  Wikipidia confirms 
this: <http://en.wikipedia.org/wiki/Handoff>.

>  I am not aware of a single, or even small set, 
> of references that would do justice to the 
> topic.  The intent of the phrasing is to let 
> readers know that a lot of work has gone on in 
> this area over a long period of time, and that 
> readers should not make simplistic assumptions.
>  [ZÖr] I try to read all the specs as a dumb 
> person would do who does not know anything - 
> the first thing that came to my mind here was. 
> "oh, good, where can I find those?"

I agree it would be nice to have a reference (or 
two or three).  Suggestions welcome.

>  I'd be very happy to mention server to client 
> notifications outside of IMAP and submission, 
> but my understanding is that this has not been 
> agreed to yet as an IP-based mechanism.  I 
> suppose I could mention RFC 4146, but that 
> seems silly.
>  [ZÖr] so the first question here is: do we need 
> an IP-based notification mechanism? I would say 
> yes.

That's a discussion that is broader in scope than 
this document.  I believe the group is doing some 
work on notifications.  I like Dave's suggestion 
that the deployments document should reference 
profile, then it can be updated for profile-bis 
to include notifications.

>  [ZÖr] Before You do first I would like to 
> undestand what qualifies as a normative and an 
> informative reference. You have a reason why 
> You wrote it like this - I would like to 
> understand why (so that I can avoid dumb 
> questions in the future).

Normative references are required in order to 
understand or implement a document.  Informative 
ones add information but are not essential to 
understanding or implementation.

>  The issue of referencing Profile versus 
> Profile-bis is one that Dave mentioned to me; 
> my response at the time was that I personally 
> don't care at all either way, so if people feel 
> strongly or have specific reasons to go with 
> one or the other, please speak up.
>  [ZÖr] I think Profile does not mention this 
> document, while Profile-bis does. Since 
> Profile-bis does reference this document, does 
> this document have to refer to Profile-bis as a 
> normative reference? One could argue (me, hehe) 
> that this document is valid for the plain old 
> IMAP as well, so why reference Profile(-bis) 
> normatively? Perhaps this just comes from the 
> fact that I do not yet understand the point 
> behind normative and informative references in 
> IETF.

Profile is only a normative reference because the 
document is aimed at deployments of it.  This is 
an area where the normative or informative choice 
is not black and white, I think.  You make a good 
point that the deployments document could apply 
to non-lemonade IMAP and submission, although the 
document does require that the submission server 
be able to contact the IMAP server, which is not 
the case in non-lemonade situations.  It would be 
possible to reword this to avoid making profile 
normative, but I don't see any benefit to doing 
that.

-------------- Randomly-selected tag: ---------------
Why is it that we rejoice at a birth and grieve at a funeral?  It is
because we are not the person involved.                 --Mark Twain