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] > <mailto:[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] > <mailto:[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] >> <mailto:[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] >> <mailto:[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 >> >> <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 >> <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] >> <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/acme >> <https://www.ietf.org/mailman/listinfo/acme> >> >> >> >> _______________________________________________ >> Acme mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/acme >> <https://www.ietf.org/mailman/listinfo/acme> > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
