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