Re: [vip] ICANN variant project update
At 14:41 04-01-2012, Andrew Sullivan wrote:
ICANN is eagerly soliciting comments, and I hope that those of you interested in this topic will take the time to read the report and send your observations. Having been a participant in this particular
I browsed through the report. I found it difficult to understand. "if an email is sent to localpart@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. "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. "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. "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. "These issues are noted in recent reports from ICANN's Security and Stability Advisory Committee (such as SSAC 051)" That's a report on "Domain Name WHOIS Terminology and Structure". Which name to call WHOIS is not an issue. "Areas of application behavior, resolution and registration services, WHOIS service, and business logic all need to be examined in order to determine if these objectives are achievable." This is buried deep within the report. 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. 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. Regards, -sm
At 15:56 07/01/2012, SM wrote:
DNAME might be read as the off-the-self "solution" to technical problems.
Your analysis is of real interest. 1. it seems the debate will continue on this list. In such a case, please ICANN indicate the texte of reference for this debate, including all the annexes and provide a reformatable source (word or txt). 2. what do you mean by "off-the-self", is it a typo, an humoristic way to tell ICANN that DNAME are actually unworkable except in ICANN documents, or a call for an additional pre-request (P-DNS) service to support polynymy and orthotypography (and possibly anti-homography protection) that ICANN could couple to the IDNS solution? Best jfc
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@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@anvilwalrusden.com
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
participants (3)
-
Andrew Sullivan -
JFC Morfin -
SM