Robert: thanks for the review. Russ: thanks for the update. I have placed a no-obj in the ballot for this document.
Jari On Dec 1, 2013, at 7:35 AM, Russ Housley <hous...@vigilsec.com> wrote: >> Document: draft-housley-ct-keypackage-receipt-n-error-05 >> Reviewer: Robert Sparks >> Review Date: 26 Nov 2013 >> IETF LC End Date: 27 Nov 2013 >> IESG Telechat date: not yet scheduled >> >> Summary: Ready >> >> Two nit-level comments: >> >> I found the formulation 'The key package error content type MUST be signed >> if the entity generating it is capable of signing it' awkward. Protocols >> break if you don't follow a MUST. As written, this says its ok to break the >> protocol. Is this, instead, really trying to say something about the thing >> that's going to evaluate the error content type (like "expect a signature >> unless you're explicitly configured to allow a lack of one")? > > Given that this is an error response, I was trying to allow for the situation > where the signature cannot be created. I was trying to say: If it can be > signed, please do so. > >> The word "above" in "Error codes above this point" is ambiguous. It can mean >> either "earlier in the document" or "with numbers greater than this value". >> That ambiguity may be harmless (it's easy to resolve by looking at the >> referenced document), but if you want to remove it, I suggest saying "The >> error codes listed here with values <=33". > > No problem. Fixed in -06. I shortened the suggested phrase to avoid a line > wrap: > > -- Error codes with values <= 33 are aligned with [RFC5934] > > Russ > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
