Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

[Doug Barton <[e-mail]>]

On 02/24/2011 02:37, Stephane Bortzmeyer wrote:
> On Wed, Feb 23, 2011 at 11:47:20AM +0000,
>   Suzanne Woolf<[e-mail]>  wrote
>   a message of 69 lines which said:
>
>> Per the announcement to the list last night, the -00 of the
>> "aliases" problem statement has been posted to the i-d repository.
>
> Well, thanks to the authors, it is a very necessary document and I
> appreciate that two courageous persons decided to actually work on it.
>
> This being said, I'm not terribly happy with the result. IMHO, such a
> document should be used to help people understand the issues before
> claiming "We need variants in the DNS" and I'm afraid it is too
> complicated at this stage to fill this role.

So it's too complicated, but you want to add to it? :)

> More specifically:
>
> The document does not mention clearly that the starting point is a
> difference of expectations between normal humans and IETF
> members.

I certainly don't think we need to draw the dichotomy quite that way. :)

> Normal humans assume that some names are identical
> (color.example == colour.example, café.fr == cafe.fr, wells-fargo.com
> = wellsfargo.com, ibm.example = IBM.Example, etc) and the DNS does not
> deliver what they want. IETF participants know that my last example
> works and not the other three but, when you try to explain that to
> normal humans, they don't understand and they are right. It should be
> stated from the beginning that we simply cannot provide a DNS
> behaviour that will be seen by normal users as "natural" and
> "unsurprising" (because of the complexity of the rules and their
> language-dependant character). So, we should warn users, not try to
> create mechanisms that will *always* fall short of their expectations.

I agree that more examples would help improve the readability of the 
document for the non-tech folks, and there will be quite a few of them 
who will be reading/interested in this document. I disagree however that 
the logical conclusion of "the problem is a difficult one" is "therefore 
we should do nothing." I think this document makes a good start at 
laying out the problems, and should be expanded to make it more clear 
where solutions are possible in the DNS layer, and for which problems 
solutions will have to come from other layers.

> Second, the document seems to assume that the problem is mostly, if
> not exclusively, an IDN thing. As the examples above (and the examples
> of phishing sites) show, this is far from true. In registries which
> are still discussing IDN registration (like .FR, see
> <http://www.afnic.fr/actu/nouvelles/271/10-february-2011-idn-workshop-organised-by-afnic>),
> some people keep telling that IDN are complicated and we should not
> allow them because of this complication. But the examples above show
> that IDN are not the only issue. It would be better if the document
> clearly stated that. (Another french story: in .FR, the law - not the
> registry policies - says that city names are reserved to the city
> council, and this is done in a dash-independent way: saint-quentin.fr
> and saintquentin.fr are therefore part of the same "bundle". Since the
> law is only for cities, not for corporations, saint-gobain.fr and
> saintgobain.fr are still distinct. Imagine the user confusion!)

Registry policy could help with this user confusion. If only we knew 
someone in a position to help with that ...

> The case (pun intended) of case-insensitivity is a complex one. It is
> obviously impossible to change the rules now but the document says
> several times that the case-insensitive rule is a good one, which is
> not obvious. The case-insensitivity rule is not perfect (in French,
> Poussin is a painter and poussin a bird) and users legitimally ask
> "why case is not important but a stupid dash is?". The document's only
> negative remark about case-insensitivity is about its use in
> compression (section 2.3.1), which seems to me an useless detail
> (because only implementers see it). I suggest to drop this sentence
> about compression: the biggest lack of consistency is not in
> compression, it is in the fact that DNS is fuzzy on some criteria
> (case) and strict in others (dash, spelling).

That would have value for the non-technical audience of the document, yes.

> The document mentions several times (for instance 3.1.1) the perceived
> need to be able to distinguish if a name is a member of a bundle. This
> need is not explicitely stated in the Proposed Requirments section (4)
> and is questionable. What is the rationale for this unstated
> requirment?

My understanding is that it is to help application developers to be able 
to auto-configure things to handle multiple variants. I think this is a 
good idea, and you made a good catch in noting that it's not in Section 4.

> The section on Applications (3.3) apparently does not mention the fact
> that many application protocols (HTTP and SMTP are two obvious
> examples) need to be configured to recognize the bundle. (Which is a
> strong argument against a new DNS solution, since it will be useless
> anyway.)

I believe that the common case will be that there are few enough 
variants that users who wish to use them all will simply configure them. 
This is already the case for "the same" domain in multiple TLDs, or 
non-IDN "variants" (of which your dash examples are a great case in 
point), and IS already the case for those who have chosen to provision 
the IDN variants they've been delegated. There is nothing about 
providing a DNS solution to the variant problem which makes _using_ the 
variants harder (or for the most part, different) and we have at least 
the chance to make life easier.

To that end, the security and/or application section(s) of the document 
could probably use a mention of name-based virtual hosting for http. It 
would also be nice to provide a discussion of the fact that HTML5 + 
DNSSEC + CERT has a chance to replace hostname-based SSL certs 
altogether, but given that I'm fuzzy on the details and don't have the 
time to do the research to provide text consider it only the whispiest 
of hints of a suggestion. :)


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/