Subject: draft-ietf-dnsext-insensitive-02.txt

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 20 Mar 2003 16:16:29 -0800 (PST)

A couple of issues with draft-ietf-dnsext-insensitive-02:

First of all, the draft seems much longer than it needs to be.  Keep
in mind that the draft arose from the following request from Erik
Nordmark:

   [...] it would be quite helpful to point out that the DNS servers notion
   of "case" is limited to octets that are in the ASCII range.
   Otherwise folks will continue to discuss what case sensitive means
   for octet values >128.

That could be said in a single sentence.  The text on classes and
extended label types in sections 3.1-3.2 are useful additional
clarifications, but there is no real need for an extended treatment
that at best repeats what is already said in STD 13 and at worst
conflicts with it, or for historical notes on the development of
movable type.

   2.1 Escaping Unusual DNS Label Octets

The purpose of section 2.1 is unclear.  Is it merely defining the
notation used for domain names in the remainder of the draft (if so,
why not simply refer to RFC1035 section 5?), or is it intended as a
clarification or update to RFC1035 section 5?

   Originally, DNS input came from an ASCII Master File as defined in
   [STD 13]. DNS Dynamic update has been added as a source of DNS data
   [RFC 2136, 3007]. When a node in the DNS name tree is created by such
   input, no case conversion is done and the case of ASCII labels is
   preserved if they are for nodes being created. However, no change is
   made in the name label on nodes that already exist in the DNS data
   being augmented or updated.
   [...]
   The same considerations apply when inputting multiple data records
   with owner names differing only in case. From the example above, if
   an "A" record is stored under owner name "xyz.BAR.example" and then a
   second "A" record under "XYZ.BAR.example", the second will be stored
   at the node with the first (lower case initial label) name.

I have a problem with this text.  It seems to imply that
implementations must not, and do not, update the character case of
existing labels in the database when they receive new data having a
different character case (e.g., in a dynamic update), but such
updating is not forbidden by STD 13.  One could even argue that
updating the case would be desirable since the most recently added
data are more likely to reflect the administrator's current
preferences regarding character case than the oldest data.  I would
like the draft to be changed to say that the final node may have the
character case of either the initial name or the new name, assuming
this text needs to be there at all.

Another issue that needs to cleared up is whether the text in RFC1035
section 2.3.3 saying

   In general, this preserves the case of the first label of a domain
   name, but forces standardization of interior node labels.

should be interpreted as saying that the character case of interior
node labels MAY be standardized by the server or that it MUST be
standardized.  The draft seems to be assuming a MUST, but I would
strongly suggest an interpretation of MAY.  Making it a MUST would
severely limit the options of implementers without offering any
benefit in return.  For example, it would outlaw implementations that
store a separate copy of the complete owner name with each RRset.
-- 
Andreas Gustafsson, [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>