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 <[email protected]> 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 > 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 before the > directorates get started on their reviews. > > Yoav > > > On 27 Mar 2018, at 22:09, Richard Barnes <[email protected]> wrote: > > 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 <[email protected]> > wrote: > >> Richard: Will you take care of whatever this involves? >> >> >> On Mon, Mar 26, 2018 at 12:05 PM, Yoav Nir <[email protected]> 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. >>> >>> Thanks >>> >>> Yoav >>> >>> >>> On 26 Mar 2018, at 17:52, Daniel McCarney <[email protected]> wrote: >>> >>> PR #417 was merged. This should be resolved now. >>> >>> Thanks again! >>> >>> - Daniel / cpu >>> >>> On Fri, Mar 23, 2018 at 10:43 AM, Daniel McCarney <[email protected]> >>> 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 oversight in https://github.com/ietf-wg- >>>> acme/acme/commit/5da11f713e808bd5c8a707dc67754f5ca37b120e. >>>> >>>> I opened a pull request to implement this fix >>>> https://github.com/ietf-wg-acme/acme/pull/417 >>>> >>>> Additionally, should the “finalize” URL be made optional in Section >>>>> 7.1.3, and returned only if the order status is transitioned to “ready”? >>>> >>>> >>>> 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 strong benefits. >>>> >>>> Thanks for catching another spec error! :-) >>>> >>>> - Daniel / cpu >>>> >>>> >>>> On Thu, Mar 22, 2018 at 4:10 PM, Zhang, Ning <[email protected]> >>>> wrote: >>>> >>>>> 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 >>>>> in the CSR. >>>>> >>>>> … >>>>> >>>>> "ready": The server agrees that the requirements have been fulfilled, >>>>> and is awaiting finalization. Submit a finalization request. >>>>> >>>>> >>>>> >>>>> It seems that the second statement makes more sense, by changing the >>>>> “pending” into “ready” in the first statement. >>>>> >>>>> >>>>> >>>>> Additionally, should the “finalize” URL be made optional in Section >>>>> 7.1.3, and returned only if the order status is transitioned to “ready”? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Ning >>>>> >>>>> _______________________________________________ >>>>> Acme mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/acme >>>>> >>>>> >>>> >>> _______________________________________________ >>> Acme mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >>> >>> >>> >> > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
