OK fine. -11 is up.
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
On Tue, Mar 27, 2018 at 8:59 PM, Yoav Nir wrote:
> The thing is, the comments came in before IETF LC started (minutes before,
> but still…)
>
> And IETF LC is 4 weeks because it’s assumed that people will be too busy
> t
The thing is, the comments came in before IETF LC started (minutes before, but
still…)
And IETF LC is 4 weeks because it’s assumed that people will be too busy this
week having just come back to work from IETF week. So I’d rather any changes
that we know are happening should be published befor
On Tue, Mar 27, 2018 at 8:26 PM, Sophie Herold
wrote:
>
> On 23/03/18 15:43, Daniel McCarney wrote:
> > My preference here is no. This would introduce two ways to check for the
> > same thing: whether an order is ready. One by checking the status ==
> > "ready" and one by checking if there is a f
On 23/03/18 15:43, Daniel McCarney wrote:
> My preference here is no. This would introduce two ways to check for the
> same thing: whether an order is ready. One by checking the status ==
> "ready" and one by checking if there is a finalizationURL. I think this
> will complicate things without any
Yoav: I'm going to propose we wait until IETF LC ends, and cut a new draft
before sending it to the IESG. Merging PRs is just the modern way of doing
accepting LC comments and addressing them before IESG evaluation.
On Mon, Mar 26, 2018 at 8:00 PM, Daniel McCarney
wrote:
> Richard: Will you tak
Richard: Will you take care of whatever this involves?
On Mon, Mar 26, 2018 at 12:05 PM, Yoav Nir wrote:
> Hi
>
> Since you’re merging stuff, then please submit a new version of the draft
> ASAP. We *are* in IETF LC, and we wouldn’t want everyone to read an “old”
> version of the draft.
>
> Th
Hi
Since you’re merging stuff, then please submit a new version of the draft ASAP.
We *are* in IETF LC, and we wouldn’t want everyone to read an “old” version of
the draft.
Thanks
Yoav
> On 26 Mar 2018, at 17:52, Daniel McCarney wrote:
>
> PR #417 was merged. This should be resolved now.
>
PR #417 was merged. This should be resolved now.
Thanks again!
- Daniel / cpu
On Fri, Mar 23, 2018 at 10:43 AM, Daniel McCarney
wrote:
> Hi Ning,
>
> It seems that the second statement makes more sense, by changing the
>> “pending” into “ready” in the first statement.
>
>
> Agreed, this was an
Hi Ning,
It seems that the second statement makes more sense, by changing the
> “pending” into “ready” in the first statement.
Agreed, this was an oversight in
https://github.com/ietf-wg-acme/acme/commit/5da11f713e808bd5c8a707dc67754f5ca37b120e
..
I opened a pull request to implement this fix
h
In Section 7.4, the following two statements seem to in conflict with each
other:
A request to finalize an order will result in error if the order indicated does
not have status “pending”, if the CSR and order identifiers differ, or if the
account is not authorized for the identifiers indicated
10 matches
Mail list logo
