Subject: [sieve] Working Group Last Call: draft-ietf-sieve-vacation-seconds-00

From: Cyrus Daboo <[email-masked]>
Date: Tue, 28 Sep 2010 10:02:24 -0400

Hi folks,
We are starting a working group last call on 
<https://datatracker.ietf.org/doc/draft-ietf-sieve-vacation-seconds/> 
today. This will run for two weeks, i.e. finish Tuesday October 12th. 
Please review this document and provide comments back on this list, to the 
authors and chairs. If you review it and have no issues, please also send a 
comment to the list to that effect.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 28 Sep 2010 10:25:40 -0400

Hi,
Some comments on draft-ietf-sieve-vacation-seconds-00:

Section 2: a maximum of 2**31 seems a little excessive. Also, the base 
vacation spec does allow sites to override the maximum value (:days MUST be 
> 7, SHOULD be > 30). I think it makes sense to at least allow a similar 
maximum limit for :seconds. I would suggest MUST be >= 86,400 (1 day).

Section 2: base vacation spec does not allow a minimum of zero. Why do we 
allow it here? If it is OK here, perhaps we should add some text calling 
this out as one key difference from the base vacation behavior.

Section 4: Second sentence seems a little weak. It only says 
implementations "SHOULD consider the number of auto-replies ... generated". 
It does not state why that is important, or what might be done to alleviate 
any problem related to it. So I think we need some more text here.

Section 5: Please change the contact email to <[email-masked]>.

-- 
Cyrus Daboo

---

From: [email-masked]
Date: Tue, 28 Sep 2010 09:04:48 -0700 (PDT)

> Section 2: a maximum of 2**31 seems a little excessive.

As a practical matter, people are likely to implement this stuff using time_t
values, and it's unlikely that all implementations will, if actually given a
value as large as 2**31, do the right thing. OTOH, the 2**31 isn't the largest
value an implementation has to accept - we have other means of limiting that -
it's the largest value that the protocol allows, so this really doesn't do any
harm AFAICT.

> Also, the base

RFC 5228 says that implementations are able to impose reasonable
limits; a maximum on this would certainly qualify so we don't *have* to
have explicit text to authorize implementations to do this. OTOH, if 
we want to discourage implementations from setting a maximum that's too
low. So I think adding this is a good idea.

> this out as one key difference from the base vacation behavior.

I have to say I view this as a case of accepting operational reality. For
better or worse, people often use Sieve vacation to implement autoresponders
rather than out of office messages. When you do that it's unacceptable to 
suppress any replies on a temporal basis.

We had no choice but to eliminate the nonzero value limitation in our
implementation years ago. Do so has caused, AFAIK, no operational problems
at all.

That said, some text discussing this change would be a good idea.

> any problem related to it. So I think we need some more text here.

Perhaps something like "MAY impose additional limits on the number of replies 
generated" would help.

> Section 5: Please change the contact email to <[email-masked]>.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Wed, 29 Sep 2010 02:08:37 -0400

> this out as one key difference from the base vacation behavior.

Including Ned's comments to this also, I've made the text this:

      The time value is specified in seconds, and MUST be greater than
or equal to
      0 and less than 2**31.  All valid values MUST be accepted
without error, but
      sites MAY define a minimum value to actually be used if a smaller value is
      specified, and/or a maximum value to be used if a larger value
is specified.
      If a site imposes a maximum value, that value MUST be at least
86400 (one day).

      If 0 is specified and used, it means that all auto-replies are
      sent, and no attempt is made to suppress consecutive replies.
      This changes the base vacation specification, which does not
allow ":days 0";
      the change is necessary to allow operation of an auto-responder
      (see <xref target='I-D.ietf-sieve-autoreply' />).

...and I've added an informative reference to sieve-autoreply.  Please comment.

> Section 4: Second sentence seems a little weak. It only says implementations
> "SHOULD consider the number of auto-replies ... generated". It does not
> state why that is important, or what might be done to alleviate any problem
> related to it. So I think we need some more text here.

Text is now this:

      Security considerations for the Sieve Vacation extension
      <xref target='RFC5230' /> apply equally here.  In addition,
      implementations SHOULD consider the number of auto-replies that
      might be generated by allowing small values of ":seconds" (including 0),
      and MAY impose additional limits on that number.
      See the Security Considerations section of RFC 3834 <xref
target='RFC3834' />
      for a fuller discussion.

...and I've added an informative reference to RFC 3834 (I had
previously thought that the reference to 5230 and *its* reference to
3834 sufficed).  Please comment.

> Section 5: Please change the contact email to <[email-masked]>.

Yeh, missed that on the previous round.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 29 Sep 2010 10:14:47 -0400

Hi Barry,

--On September 29, 2010 2:08:37 AM -0400 Barry Leiba 
<[email-masked]> wrote:

>       sites MAY define a minimum value to actually be used if a smaller
> value is       specified, and/or a maximum value to be used if a larger
> value is specified.

Works for me.

>> implementations "SHOULD consider the number of auto-replies ...
>> generated". It does not state why that is important, or what might be
>> done to alleviate any problem related to it. So I think we need some
>> more text here.
>
> Text is now this:
>
>       might be generated by allowing small values of ":seconds"
> (including 0),       and MAY impose additional limits on that number.

Works for me.

Thanks.

-- 
Cyrus Daboo

---

From: [email-masked]
Date: Wed, 29 Sep 2010 08:13:53 -0700 (PDT)

> Works for me.

Yes, this looks good.

> Works for me.

And for me. Hopefully the IESG wlil agree...

				Ned