Document: draft-ietf-openpgp-rfc2440bis-19.txt Reviewer: Miguel Garcia 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.