[Gen-art] GenArt review: draft-ietf-tls-openpgp-keys-10.txt

[Robert Sparks <[e-mail]>]

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