> 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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
