I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-openpgp-rfc2440bis-19.txt
Reviewer: Miguel Garcia <[EMAIL PROTECTED]>
Review Date: 2007-03-26
IETF LC End Date: 2007-03-27
Summary: This draft is on the right track but has open issues, described
in the review.
Comments:
The document is well written and easy to understand, however, I have a
couple of (probably important) open issues that should be further discussed.
1) Section 10.3.3 creates a registry of hash algorithm identifiers. I am
aware of an existing similar registry in IANA. I would draw the author's
attention to this registry:
http://www.iana.org/assignments/hash-function-text-names
which was created about a year ago to explicitly list hash function
textual names. In my opinion, this draft should not create a new
duplicated registry, but use (and perhaps extend, if needed) the
existing one.
Note that in case this comment is accepted, you may need to re-write
other parts in the draft, such section 5.2.2
I would encourage the authors to find out if IANA already has other
additional existing registries that could be used. For example, I was
trying to find a registry of compression algorithms (Section 10.3.4),
but the closest registry I found is:
http://www.iana.org/assignments/comp-meth-ids
Although I am afraid you can't use this last one, which seems to be
specific for TLS. But I would like the authors to comment about this and
other potential existing registries.
2) I found that the draft lacks a lot of references in the text. So,
unless the reader is VERY familiar with the technology, it is hard to
find references, either normative or informative. Take as an example
Section 1, which mentions RFC 2440, 1991, RSA, MD5, IDEA, GPG, RFC 2434,
etc. without a single reference to them.
Similar applies to Radix-64 in Section 2.4, PKCS#1 in Section 5.2.2; RFC
1950, RFC 1951 and BZip2 in Sections 5.6 and 9.3.
Connected to the above: I would suggest to add one more column to each
of the tables in Section 9, where you add a reference to each of the
rows in the table.
Note that this are just examples, there are many places in the draft
where there aren't appropriate references to normative or informative
specifications.
Nits:
3) Section 10.3.4 creates the compression algorithms registry and refers
to IANA to Section 9 in the draft to populate the registry. I guess you
are referring to Section 9.3 (Section 9 is not precise enough for IANA).
4) Section 3.4 mentions RFC 2279 as a UTF-8 reference. Notice that RFC
2279 has bee obsoleted by RFC 3629.
5) Section 10.2.2.1: The section creates a registry of Signature
Notation Data types and initially populates the registry with the data
found in Section 5.2.3.16. This Section 5.2.3.16 refers to the data as
"flags" rather than "data". I would like to synchronize both terms in
one or the other way.
6) I wonder why the draft refers to "ZIP" when speaking about RFC 1951,
when RFC 1951 is the "Deflate" algorithm. As far as I know "ZIP" is not
the name of a compression algorithm: its proper name is "deflate".
7) Please run idnits at http://tools.ietf.org/tools/idnits/idnits.pyht
There are many nits reported, including down references and references
to obsolete documents.
8) Be careful with the examples in Section 6.5. The lines cross the 72
character limit, so the last column folds over the next line and makes
the examples unreadable.
/Miguel
--
Miguel A. Garcia tel:+358-50-4804586
Nokia Research Center Helsinki, Finland
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
