jsha at letsencrypt.org
Sun Feb 5 21:56:45 UTC 2017
On Sun, Feb 5, 2017 at 1:34 PM, Kirk Hall via Public <public at cabforum.org>
> Many of us have complex validation and issuance programming already based
> on months and anniversaries, and there doesn't seem to be a good reason to
> reprogram all this to a set number of days
Peter's proposal wouldn't require you to reprogram any of that, because it
is strictly more permissive than the months / anniversaries code you
already have. The best approach would be to continue what you are doing,
and always issue on the first of the month or some other anniversary. Then
you get the human-readable benefit, and would be sure that you are within
the 398 day period.
> - plus, again, it's harder for humans to calculate the last time or the
> next time a task had to be done. That's my opinion.
The 398 day period (vs 365 days) is specifically intended to give the
wiggle room needed for subscribers and CAs to be able to schedule a renewal
at the same time each year. If you always schedule your renewal for March 1
every year, you would still be able to do that just fine, and have a month
(or ~31 days) of leeway.
> Should be easy to reach agreement on what 13 months means, and how to
Yep, that's the topic of this thread! Peter is proposing that the easiest
way to measure 13 months is to define it as 398 days. I think you will find
broad consensus among programmers that it's easier to reliably measure
periods in terms of days than in terms of months.
Another way to think of this: The goal is to renew every year (~365 days),
but give people some leeway so they can keep the renewal on the same date.
If we make that leeway 32 days, everything works out nicely.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public