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