Re: [lemonade] I-D ACTION:draft-ietf-lemonade-futuredelivery-02.txt

Randall Gellens <randy@qualcomm.com> Thu, 15 September 2005 21:34 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1N2-00038b-Np; Thu, 15 Sep 2005 17:34:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1N1-00038T-HH for lemonade@megatron.ietf.org; Thu, 15 Sep 2005 17:34:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11728 for <lemonade@ietf.org>; Thu, 15 Sep 2005 17:34:12 -0400 (EDT)
Received: from warlock.qualcomm.com ([129.46.50.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG1Rp-0007b6-Fn for lemonade@ietf.org; Thu, 15 Sep 2005 17:39:18 -0400
Received: from [129.46.172.15] (loud.qualcomm.com [129.46.172.15]) by warlock.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8FLXq7S013490; Thu, 15 Sep 2005 14:33:53 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p07000c14bf4e4a021425@[129.46.172.15]>
In-Reply-To: <E1E5TvG-0001wO-4E@newodin.ietf.org>
References: <E1E5TvG-0001wO-4E@newodin.ietf.org>
X-Mailer: Eudora for Mac OS X v7.0a
X-message-flag: Using Outlook? Upgrade to Eudora: <http://www.eudora.com>
Date: Thu, 15 Sep 2005 14:33:43 -0700
To: g.a.white@comcast.net, GregV@ieee.org
From: Randall Gellens <randy@qualcomm.com>
Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-futuredelivery-02.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: lemonade@ietf.org
X-BeenThere: lemonade@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enhancements to Internet email to support diverse service enivronments <lemonade.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:lemonade@ietf.org>
List-Help: <mailto:lemonade-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/lemonade>, <mailto:lemonade-request@ietf.org?subject=subscribe>
Sender: lemonade-bounces@ietf.org
Errors-To: lemonade-bounces@ietf.org

I think you should reference draft-gellens-submit-bis-02.txt instead 
of RFC 2476, since submit-bis is in the RFC editor's queue.

It's quite a nit, but if you do publish a revision prior to approval, 
I'd suggest changing "voted" to "agreed" in section 13.1.

In section 4.1.1, the first two requirements seem a little silly to state.

In 4.1.2.6, I wonder if perhaps it might be more clear to say 
"exceeds" rather than "strictly greater than".  We seem to like using 
"strictly" in situations where I think our meaning isn't clear 
("strictly increasing", to use an example from a different context). 
My assumption is that in this case, "strictly greater than" means 
just "greater than", and is used to exclude equality, which I don't 
think would be implied anyway.

This also applies to 4.3.1.1: "the value of the 
future-delivery-interval-param MUST be strictly less than the value 
of the accompanying by-time parameter" should perhaps be "the value 
of the accompanying by-time parameter MUST exceed the value of the 
future-delivery-interval-param".

(I like section 4.2.1.1 -- it makes me think of a server that 
implements "whenever Joe sends a message, hold it for three days and 
then bounce it")

In 4.2.2.1 and 4.2.2.2, I think there is a potential ambiguity in "If 
an MSA generates a DSN for a message that includes a Future Delivery 
request" -- it could be read that the DSN has a future delivery 
request.  Perhaps, just to be sure, this could be reworded slightly, 
maybe just change "that includes" to "which included" or "which 
used"; the use of past tense might make this more clear.

In 4.3, there is a blank line in the middle of the first paragraph.

In 5.2, I'm not sure that it is proper to say "An MSA's 
future-delivery storage SHOULD be subject to a per-user quota" -- I 
don't think we can justify the SHOULD on interoperability grounds, 
and the text already points out to implementors that there is a 
security consideration in managing storage.  How the implementation 
decides to protect against this risk should be up to it.




-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
... But as records of courts and justice are admissible, it can
easily be proved that powerful and malevolent magicians once
existed and were a scourge to mankind.  The evidence (including
confession) upon which certain women were convicted of
witchcraft and executed was without a flaw; it is still
unimpeachable.  The judges' decisions based on it were sound in
logic and in law.  Nothing in any existing court was ever more
thoroughly proved than the charges of witchcraft and sorcery
for which so many suffered death.  If there were no witches,
human testimony and human reason are alike destitute of value.
                      --Ambrose Bierce, "The Devil's Dictionary"

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade