The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
draft-ietf-idnabis-tables-09

[Ballot discuss]
5.1.  IDNA derived property value registry

  IANA is to create a registry with the derived properties for the
  versions of Unicode that is released after (and including) version
  5.2.  The derived property value is to be calculated according to the
  specifications in Section 2 and Section 3 and not by copying the non-
  normative table found in Appendix B.

  If IANA during this process finds non-backward compatible changes to
  the table of derived properties, or otherwise problems during the
  creation of the table, that is to be flagged to the IESG.  Changes to
  the rules (as specified in Section 2 and Section 3), including
  BackwardCompatible (Section 2.7) (a set that is at release of this
  document is empty), require IETF Review, as described in RFC 5226
  [RFC5226].

This is way to complicated for IANA to deal with without any help from experts. So I would recommend changing this to Expert Review.

[Ballot comment]
1.  Introduction

  RFC 4690 [RFC4690] suggests an inclusion based approach for selecting
  the code points from The Unicode Standard [Unicode52] that should be
  included in the list of code points that may be used in
  Internationalized Domain Names.

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119 [RFC2119].

This paragraph seems to be out of place. It seems to break the surrounding text.

  Specifically, RFC 4690 [RFC4690] says the following:

      The IAB has concluded that there is a consensus within the broader
      community that lists of code points should be specified by the use
      of an inclusion-based mechanism (i.e., identifying the characters
      that are permitted), rather than by excluding a small number of
      characters from the total Unicode set as Stringprep [RFC3454] and
      Nameprep [RFC3491] do today.  That conclusion should be reviewed
      by the IETF community and action taken as appropriate.

[Ballot discuss]
5.1.  IDNA derived property value registry

  IANA is to create a registry with the derived properties for the
  versions of Unicode that is released after (and including) version
  5.2.  The derived property value is to be calculated according to the
  specifications in Section 2 and Section 3 and not by copying the non-
  normative table found in Appendix B.

  If IANA during this process finds non-backward compatible changes to
  the table of derived properties, or otherwise problems during the
  creation of the table, that is to be flagged to the IESG.  Changes to
  the rules (as specified in Section 2 and Section 3), including
  BackwardCompatible (Section 2.7) (a set that is at release of this
  document is empty), require IETF Review, as described in RFC 5226
  [RFC5226].

This is way to complicated for IANA to deal with without any help from experts. So I would recommend changing this to Expert Review.

IANA questions/comments:

IANA understands that, upon approval of this document, two new registries are
to be created: a derived property value registry and a context registry. These
are to be new registries and IANA understands that modifications to the
registry require RFC 5226 IETF review.

For the derived property value registry, can the editor or a designee give us
some assistance in creating the initial table from Unicode 5.1? In addition,
is the format of the table in Appendix B the model for the table that IANA
should create?

For the Context registry, IANA understands that Appendix A should form the
base. As an example, should, for each codepoint, we simply use A.1 as a
model? That is, register codepoint, overview, lookup, and ruleset for each one?

IANA understands that the creation of this pair of registries is the only
action required upon approval of the document.