Subject: Review of draft-ietf-idnabis-defs

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 17 Oct 2009 08:43:05 -0700

I have reviewed draft-ietf-idnabis-defs.    Overall, I found the document
clear and easy to read.  

Some specific comments below.

Technical

Section 2.2

   When discussing the DNS, this document generally assumes the

   terminology used in the DNS specifications [RFC1034] [RFC1035] as

   modified by [RFC1123] and [RFC2181].  The term "lookup" is used to

   describe the combination of operations performed by the IDNA2008

   protocol and those actually performed by a DNS resolver.  The process

   of placing an entry into the DNS is referred to as "registration",

   similar to common contemporary usage in other contexts.

[BA] Does the term "registration" apply to DNS dynamic update, or only

to the initial process of placing an entry?   

Section 2.3.1

   Labels within the class of R-LDH labels that are not prefixed with

   "xn--" are also not valid IDNA-labels.  To allow for future use of

   mechanisms similar to IDNA, those labels MUST NOT be processed as

   ordinary LDH-labels by IDNA-conforming programs and SHOULD NOT be

   mixed with IDNA-labels in the same zone.

[BA] If one were to write a conformance test based on this statement,

what kinds of behavior would be prohibited in an IDNA-conforming program? 

For example, does "not processed as ordinary LDH-labels" imply that an

that these labels are not looked up? Is there also an implication that

these labels should not be registered?

Section 2.3.2.3

   Clients issuing queries or interpreting responses cannot be

   assumed to have any knowledge of zone-specific restrictions or

   conventions.

[BA] Does this statement also extend to clients issuing DNS dynamic updates?

Editorial

Section 2.3.2.1

   Specifically, for IDNA-aware applications, the three allowed

   categories are A-label, U-label, and NR-LDH-label.  Of the reserved

   LDH labels (R-LDH-labels) only A-labels are valid for IDNA use.

[BA] A similar statement is made in Section  2.3.1; you might consider
consolidating

this paragraph into that section.