Review of draft-ietf-idnabis-tables-06

[Paul Hoffman]

Section 2.2 uses NFKC, but the protocol itself uses NFC. I think it is useful to make a note to this effect in Section 2.2.

Editorial:
. . .
   This document specifies rules for deciding whether a code point,
   considered in isolation, is a candidate for inclusion in an
s/isolation,/isolation or in context,/
   Internationalized Domain Name.
. . .
   This document reviews and classifies the collections of code points
   in the Unicode character set by examining various properties of the
   code points.  It then defines an algorithm for determining a derived
   property value.  It specifies a procedure and not a table of code
procedure, and not a table, of code
   points so that the algorithm can be used to determine code point sets
   independent of the version of Unicode that is in use.
. . .
   The mechanisms described here allow determination of the value of the
   property for future versions of Unicode (including characters added
   after Unicode 5.1).  This is suitable for any newer versions of
   Unicode as well.  Changes in Unicode properties that do not affect
remove "This is...as well" because it is redundant with the sentence before.
   the outcome of this process do not affect IDN.  For example, a
   character can have its Unicode General_Category value change from So
   to Sm, or from Lo to Ll, without affecting the table results.
s/table/algorithm/
   Moreover, even if such changes were to result, the BackwardCompatible
   list (Section 2.7) can be adjusted to ensure the stability of the
   results.
. . .
   The security issues associated with this work are discussed in
   [IDNA2008-rationale] and [IDNA2008-protocol].
remove [IDNA2008-rationale], which now has only a stub for security considerations
. . .
   Overview:
      A description of the goal with the rule, in plain english.
s/english/English/