Review of draft-ietf-idnabis-protocol-16.txt
Vint Cerf
vint at google.com
Wed Oct 14 01:36:05 CEST 2009
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
More information about the Idna-update
mailing list