Subject: Re: [Gen-art] Gen-art last call review: draft-housley-ct-keypackage-receipt-n-error-05

From: Jari Arkko <[email-masked]>
Date: Tue, 7 Jan 2014 12:50:05 -0800

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