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

[Vint Cerf]

On Oct 13, 2009, at 4:01 PM, Margaret Wasserman wrote:

> 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.

Use the Punycode decoding step to convert to U-label, if this fails,  
it isn't valid Punycode

>
> 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?

See Rationale for the best advice currently available.

>
> 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
>
>
> John Klensin needs to look at that.
vint


>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update