[vip] ICANN variant project update

[Andrew Sullivan]

Hi,

Thanks for the comments.  I write to express my own views, and not as
a representative if ICANN or the team.  I have some questions.

On Sat, Jan 07, 2012 at 06:56:27AM -0800, SM wrote:
> At 14:41 04-01-2012, Andrew Sullivan wrote:
> 
>   "if an email is sent to localpart at dname.example.com and that name has a
>    DNAME that resolves to realname.example.com, the mail transport agent is
>    not going to rewrite the server-part of the address."
> 
> I have some doubts about whether the above is correct.

Hrm.  I suppose it is possible that the MTA could be configured to
rewrite the server-part to get this right, since I know you can
configure postfix, anyway, to do just about anything to nearly any
part of mail it is sending.  But I know of no MTA today that does this
habitually.  That may well merely be my ignorance, however, so I'd be
pleased to learn of a counter-example.  In any case, since "…not going
to…" is so strong, what about "…will not normally rewrite…" instead?
Also, to be clear, this is the server-part of the address in the
header that it is supposed to be altering (which will, of course,
affect what happens when the RCPT TO: command is given, which is I
guess what you're disagreeing with?).  Is that not plain from the
text?

>    "It might, however, be one important type of variant-inspiring
> behavior, because
>      most of the deployed code today supports IDNA2003 and not IDNA2008."
> 
> I did not find any comment in the report about how to reverse the trend.

No, I don't think there is such a comment there.  Do you have any
suggestions?  Because I'd have thought IDNA2008 recommended itself if
only because it broke the dependency on a version of Unicode that
nobody uses any more.  But apparently not, and I have no idea how to
inspire the changeover beyond "wait long enough".  (UTS 46 isn't
helping, IMO.)

>    "The users of the DNS are varied in respect of what they expect,
> what they want, and
>     what they need."
> 
> This section lumps users and technical usage together.  There is not
> much of a difference between Law enforcement and other security
> investigators and end users.  Instead of System administrators and
> Software developers, it would have been clearer to discuss technical
> usage and the issues that may occur.

I guess I'm not sure what you mean by "users and technical usage"
here.  What do you mean by "users"?  To me, sysadmins are users of the
DNS just as much as my mother is when she's visiting a web site,
although they're users of different sorts, with different needs, and
of different capabilities. 
 
>   "Similarly, any site renumbering and so on will require twice the effort"
> 
> I don't see what site renumbering has to do with (DNS) strings.

If we add "…because all all the A and AAAA records will need to be
alterned in double the number of zones," does it help?  If you
renumber one site known by one name, you have to alter the A and AAAA
records for that site in that zone.  If it's known by two names
without using any aliasing, then you have to alter such records in two
zones; and so on.

> There are some examples to illustrate how the Internet, which has
> been reduced to web and email, may be affected.  The web examples
> are simplistic.

Yes.  Some earlier drafts (and some text that nobody except me ever
saw) had some more complicated examples, but either people didn't
understand them or else I thought they couldn't be made understandable
by people who didn't already have a clear idea about how the
underlying protocols work.  I'm extremely uncomfortable with the focus
on the web and on email in this report, but those protocols have a few
advantages: (1) they're well-known to (if not well-understood by) just
about anybody; (2) they're relied upon widely enough that nobody needs
an argument why making them behave in really surprising ways tomorrow
would be a bad idea; and, (3) they're each in their way linked fairly
closely to the names by which the servers in question are known, with
one type of server absolutely requiring knowledge of names for which
it is the final desitnation and the other type practically requiring
the same thing after HTTP 1.1.  That said, I'd be really interested in
suggestions for other protocols you think would be good illustrations,
particularly taking into account (1) and (2).

> The two words which stand out in the report are Cost and DNAME.  The
> report emphasizes that there will be higher costs in all areas; i.e.
> an increase in revenue for anyone with an interest in the work, from
> ICANN or the software developer.  DNAME might be read as the
> off-the-self "solution" to technical problems.

I'm not sure how to read this paragraph.  Are you suggesting that the
report, with its discussion of cost, is setting out an argument for
increased revenues?  As for DNAME, my reading of the text was that it
made fairly strong arguments for why DNAME is not a good "solution" to
these technical problems.  Is that not how you read things?  If so,
I'd be interested to understand what you thought the text was saying
instead.

Thanks very much for the remarks and for raising your observations
here where we can discuss them.

Best regards,

A
-- 
Andrew Sullivan
ajs at anvilwalrusden.com