[vip] ICANN variant project update

[SM]

Hi Andrew,
At 14:04 07-01-2012, Andrew Sullivan wrote:
>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.

I'll read your comments as those of an individual.

>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?
>ad?
>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?

I would not take a deterministic view about 
message handling as I do not have any control 
over the endpoint at the receiver's end.  The 
problem is not the MTA of today.  There are a lot 
of legacy installations out there.  Some of them 
do header field rewrites, some do not. The 
decision, generally, is about how far would you 
go to accommodate the various cases.

As there is no mention of DNAME in the 
specifications, I would take the cautious 
approach and not talk about it from a technical 
perspective.  If I say "will not normally 
rewrite" to a non-technical person, the person 
might assume that everything is ok.  You could 
get away with not talking about rewrite and just 
point out that there can be an issue (the second sentence in that paragraph).

>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.)

IDNA2008 is a bunch of RFCs.  If you want change, 
talk to the people who put code out there, listen 
to their concerns, see how you can help 
them.  You might even be solving your problem 
too.  Now, if one of the parties were to say that 
they are being oppressed because specification X 
or software Y does not allow the use of a 
confusable string, things might not move 
forward.  If I am not mistaken, it could be 
described as finding common ground and incremental progress.

>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.

By users, I mean people; "technical usage" is 
more about how the services work or can be built 
to work.  For example, if we both were to talk 
about DNS, we might be discussing it from a 
technical angle, the technical problems that are 
encountered and possible fixes.  That gets 
distilled to enable your mother to visit a web 
site without being hampered by DNS problems.

I agree that sysadmins are users are DNS.  If you 
try to cover the different classes of people, 
you'll end up trying to solve all their 
problems.  It may be easier to document how 
configure the system with X type of 
hostname.  This does not mean that the different 
needs or capabilities are ignored.

>
>
> >   "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

Ah, I see what you mean.  What you wrote makes it 
clarifies that.  The words "site renumbering" has 
a specific meaning for some communities.

>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).

Now I see what you mean.  I'll comment below.

>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.

I don't know what audience this report is aimed 
at.  I would tailor the content for the target 
audience.  Keep the technical content separate 
(somewhat related to my comment about technical 
usage).  For the technically inclined reading the 
non-technical report, provide references to where 
to find the technical information.

Getting back to the web, if you want to cover web 
issues, it may help to show what examples you 
took into account.  I don't know what objective 
you want to attain.  Sometimes we work back from 
a conclusion we wish to reach (I am not implying that you did that).

The report can be used to justify increased 
revenues.  I haven't looked at the terms of 
reference for the report.  You could lump the 
discussions about costs under financial implications.

My reading is that DNAME could be an adequate 
technical solution.  At a guess, the persons 
taking a decision after reading the report may be 
non-technical and they will remember DNAME.  As 
you can see from the above, I misunderstood 
several points you were trying to make.

Regards,
-sm