[OPS-DIR] RESEND: Review of draft-ietf-idnabis-protocol-16.txt

[Margaret Wasserman]

I apologize for the formatting of the previous version of this message.  Hopefully
this version will be more readable.  

Margaret

---

As a member of the Operations Directorate (ops-dir at ietf.org), I was
asked to review draft-ietf-idnabis-protocol-16.txt for it's possible
operational and management impact.

While the title of this document says that it defines a protocol, the
document itself does not actually define a protocol in the usual
sense.  It defines a set of transforms and checks that should be
performed on Internationalized Domain Names before they are registered
in the DNS, and a similar set of checks and transforms that should be
performed on IDNs before they are used DNS queries.  I did not find
any blocking issues with this document.  It is difficult to evaluate
this document in terms of the ops-dir questions, because it is not
really a protocol, and while it is clear that IDNs will have
operational impact on the Internet, this particular document doesn't
really cover those topics.

I do have two questions and one editorial comment regarding this
document. I apologize in advance if my questions reflect my lack of
expertise in this area.

QUESTION 1:

Section 4.2.1 says:

"Fake A-labels, i.e., invalid strings that appear to be A-labels but
are not, MUST NOT be placed in DNS zones that support IDNA."

How do I tell if an A-Label is a "Fake A-Label" (which is referred to
as a "FAKE A-Label in idnabis-defs, BTW)?  In idnabis-defs, a "FAKE
A-Label" is defined as a label with the prefix "xn--" where the
remainder of the label is not valid output from the Punycode
algorithm, but I can't find any text on how to unamibiguously tell if
a label is/isn't valid output from the Punycode algorithm.  Is that
explained somewhere?  Without a good way to tell, it may not be
possible for registries that accept "only an A-Label" as input to meet
the requirements of the MUST NOT quoted above.

QUESTION 2:

This document does not contain a material Security Considerations
section, instead referring to the Security Considerations sections of
other documents.  However, it does appear to me that those Security
Considerations sections complete cover the security topics related to
a registry that accepts IDNA registrations.  For instance, should a
registry consider rejecting registrations for domain names that
contain mutliple scripts?  Is there anything that registries need to
do (or even can do) to (help their customers) avoid the problems
described in section 4.3 of idnabis-defs draft?  EDITORIAL COMMENT:

There appears to be one typo in the document.  In section
2. Terminology, it says:

"It is worth noting that some of this terminology overlaps with, and
is consistent with, that used, but also in Unicode or other character
set standards and the DNS."

I am not sure exactly what change is needed to correct this sentence.
Perhaps:

s/that used, but also in/that used in

As a member of the Operations Directorate (ops-dir at ietf.org), I was
asked to review draft-ietf-idnabis-protocol-16.txt for it's possible
operational and management impact.

While the title of this document says that it defines a protocol, the
document itself does not actually define a protocol in the usual
sense.  It defines a set of transforms and checks that should be
performed on Internationalized Domain Names before they are registered
in the DNS, and a similar set of checks and transforms that should be
performed on IDNs before they are used DNS queries.  I did not find
any blocking issues with this document.  It is difficult to evaluate
this document in terms of the ops-dir questions, because it is not
really a protocol, and while it is clear that IDNs will have
operational impact on the Internet, this particular document doesn't
really cover those topics.

I do have two questions and one editorial comment regarding this
document. I apologize in advance if my questions reflect my lack of
expertise in this area.

QUESTION 1:

Section 4.2.1 says:

"Fake A-labels, i.e., invalid strings that appear to be A-labels but
are not, MUST NOT be placed in DNS zones that support IDNA."

How do I tell if an A-Label is a "Fake A-Label" (which is referred to
as a "FAKE A-Label in idnabis-defs, BTW)?  In idnabis-defs, a "FAKE
A-Label" is defined as a label with the prefix "xn--" where the
remainder of the label is not valid output from the Punycode
algorithm, but I can't find any text on how to unamibiguously tell if
a label is/isn't valid output from the Punycode algorithm.  Is that
explained somewhere?  Without a good way to tell, it may not be
possible for registries that accept "only an A-Label" as input to meet
the requirements of the MUST NOT quoted above.

QUESTION 2:

This document does not contain a material Security Considerations
section, instead referring to the Security Considerations sections of
other documents.  However, it does appear to me that those Security
Considerations sections complete cover the security topics related to
a registry that accepts IDNA registrations.  For instance, should a
registry consider rejecting registrations for domain names that
contain mutliple scripts?  Is there anything that registries need to
do (or even can do) to (help their customers) avoid the problems
described in section 4.3 of idnabis-defs draft?  EDITORIAL COMMENT:

There appears to be one typo in the document.  In section
2. Terminology, it says:

"It is worth noting that some of this terminology overlaps with, and
is consistent with, that used, but also in Unicode or other character
set standards and the DNS."

I am not sure exactly what change is needed to correct this sentence.
Perhaps:

s/that used, but also in/that used in