RESEND: Review of draft-ietf-idnabis-protocol-16.txt

Margaret Wasserman mrw at sandstorm.net
Tue Oct 13 22:12:30 CEST 2009


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







More information about the Idna-update mailing list