[idn] Comments on draft-hall-dm-idns-00.txt

[Erik Nordmark <Erik.Nordmark@eng.sun.com>]

Overall a quite readable document!

The text on page 7 says that
            ... as long as the calling application, the stub resolver, the 
            local caching servers, and the authoritative servers for 
            the specified domain name are compliant with this 
            specification.
but the actual protocol then correctly points out that if any of
the DNS servers used (e.g. any server along the delegation chain) doesn't
support the EDNS extended label type, then a FORMERR will result
and the protocol will fall back to ACE.
It would probably be good to clarify the text on page 7
to make this clearer and avoid knee-jerk reactions.

FWIW: The DNSEXT and NGTRANS WGs decide to move bit-string labels (RFC 2673)
to historic because of its use of the extended label type made it
too hard to introduce incrementally.
Your spec seems to explicitly deal with this.


DNSSEC isn't even mentioned in the document. I think this needs to
be worked out and filled in.

I see at least 3 issues around DNSsec (and folks that understand
it better might see other issues):
 - The conversion between ACE and UTF-8 in resolving servers (item n. on page 
   18) means that the stub resolver and application can't verify the SIGs since
   the SIG will be for the ACE query and not the UTF-8 query.
   I don't see how the protocol can have any box between the entity
   verifying SIGs and the authoriative server convert questions and/or
   answers since this breaks DNSsec.
 - DNSsec is supposed to work with offline zone keys doing offline signing of
   a zone. This means that if the server is supposed to be able to
   answer questions for <ace-1> IN CNAME <ace-2> as well as 
   <utf8-1> IN CNAME <utf8-2> then it needs to have a SIG for each one of those
   RRsets. (And if it does this, why not have both CNAME RRsets in the zone
   instead of creating them on the fly?)
 - NXT ... In order for NXT to work as expected is there is need to have
   two different views of the name space in the zone i.e. a different
   NXT when answering an ace query (which indicates the next ace name)
   from wen answering a utf8 query (the NXT indicating the next utf8 name)?
   I don't know the answer - but it makes my head hurt.


   Erik