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-idnabis-tables-07.txt Reviewer: Brian Carpenter Review Date: 2008-10-05 IETF LC End Date: 2009-10-13 IESG Telechat date: (if known) Summary: Almost ready, some issues and nits -------- Comment: -------- Note: The writeup is not in the tracker comments log. I am assuming that the words in this draft are the result of considerable debate and hard-won consensus. As an example, the Introduction says the following about the defined property values: "The value of the property is to be interpreted approximately as follows." As a rule, I'd challenge use of a word like "approximately" in a protocol specification. But I will not do so here, based on the preceding assumption. Similarly I have no comment on the detailed decisions in the body of the draft, such as the exact list of exceptions (section 2.6). I have not verified the (non-normative) list in Appendix B in any way. Major issues: ------------- "5.1. IDNA derived property value registry IANA is to keep a list of the derived property for the versions of Unicode that is released after (and including) version 5.1. The derived property value is to be calculated according to the specifications in sections Section 2 and Section 3 and not by copying the non-normative table found in Appendix B." Am I misunderstanding this? Apart from the singular/plural confusions, it seems to say that IANA must recalculate the contents of Appendix B and post them as normative material after every change to Unicode. If that's correct, it seems like an enormous burden of work, needing to be done by Unicode and IDN experts. Is that really something that can be done by IANA alone? The same issue seems to apply to "5.2. IDNA Context Registry", although perhaps less seriously. Minor issues: ------------- Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 632: '...the following character MUST be Greek....' RFC 2119 keyword, line 643: '...he preceding character MUST be Hebrew....' RFC 2119 keyword, line 655: '...he preceding character MUST be Hebrew....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.). Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IDNA2008-definitions' is defined on line 2956, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4690 -- Possible downref: Non-RFC (?) normative reference: ref. 'TR15' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode5' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode51' == Outdated reference: A later version (-11) exists of draft-ietf-idnabis-defs-10 == Outdated reference: A later version (-16) exists of draft-ietf-idnabis-protocol-14
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
