Last Call Review of draft-housley-ct-keypackage-receipt-n-error-05

Request Review of draft-housley-ct-keypackage-receipt-n-error
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-11-27
Requested 2013-10-31
Authors Russ Housley
Draft last updated 2013-11-26
Completed reviews Genart Last Call review of -05 by Robert Sparks (diff)
Secdir Last Call review of -05 by Radia Perlman (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-housley-ct-keypackage-receipt-n-error-05-genart-lc-sparks-2013-11-26
Reviewed rev. 05 (document currently at 07)
Review result Ready
Review completed: 2013-11-26


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

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")?

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 


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".