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
