[Gen-art] GenArt review: draft-ietf-tls-openpgp-key-11.txt (was: GenArt review: draft-ietf-tls-openpgp-keys-10.txt)

[Robert Sparks <[e-mail]>]

All of my concerns with -10 have been addressed in version -11. I  
have no new concerns.
This document is ready for publication as an Experimental RFC.

Thanks Nikos!

RjS

On Jul 24, 2006, at 10:46 AM, Robert Sparks wrote:

> I am the assigned Gen-ART reviewer for draft-ietf-tls-openpgp- 
> keys-10.txt
>
> For background on Gen-ART, please see the FAQ at <http:// 
> www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
>
> Normally, the Gen-ART LC review occurs during IETF Last Call, but  
> in this case the draft was not assigned
> for review until after IETF Last Call concluded. Please consider  
> these late Last Call comments and coordinate
> with your AD before taking action on any of them.
>
> This draft is basically ready for publication as an Experimental  
> RFC, but has some minor nits that should be addressed
> before publication.
>
> 1) The third paragraph in 2.3 is potentially confusing. I believe  
> it's trying to say that the content of the
>      OpenPGP public key appearing in the Certificate message is  
> defined in section 10.1 of [OpenPGP].
>      It would be better to state that directly, rather than have  
> the reader wonder if this paragraph is attempting
>      to define a new composition of OpenPGP packets.
>
> 2) Section 2.5: Is an "empty" OpenPGP key well-defined? I didn't  
> find an answer to this question quickly
>     skimming 2440. If this is defined somewhere, could you add a  
> reference. If not, could you clarify
>     what it should contain?
>
> 3) Section 2.5 (again): This section uses lower-case "should" and  
> "may" where 2119 terms would
>      make sense. Was the choice to not make these SHOULD and MAY  
> intentional?
>
> 4) Section 2.6 (tiny nit): I realize this is document is targeting  
> Experimental, but constructs like this
>     catch my eye as a source of unending implementer arguments  
> about whether this 'such as' list
>     is comprehensive and exclusive. The intent here is to say _ALL_  
> the remaining handshake
>     messages are unchanged from the definitions in [TLS]. It might  
> save pain later to change the
>     words now to say just that, and have a separate sentence saying  
> "including, but not limited to"
>     giving examples if you need them.
>
> 5) I see there were several messages on the tls list around what  
> text the security considerations
>     section should contain. The document seems to reflect the  
> conversations there, but without
>     the context of those conversations, it feels weaker than it  
> should. An explicit note in the security
>     considerations section reinforcing that all the security  
> considerations of 4346 and the documents
>     it relies on would not hurt. Are there any guidelines in  
> existing documents that this document could
>     point to in order to help the reader understand what kind of  
> issues he may be facing when making
>     the decisions this document leaves to local policy?
>
> As a matter of personal preference, I think the document would  
> benefit from a Table of Contents.
>
> I have a few grammar nits that I will send directly to Nikos.
>
>
> RjS


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art