[dnsext] Short summary of ICANN ad-hoc meeting on variants

[Kim Davies <[e-mail]>]

Here is a short summary of some of the key comments during the discussion from the ad-hoc meeting held a little over a week ago in San Francisco regarding "variants". It was a freeform discussion so sorry the notes lack much structure.

— ICANN's project is to undertake a number of case studies of 5 different scripts/cases in the IDN space, to try and establish problem statements regarding what the end user expectation is on how IDNs should function. ICANN is aware the IETF needs a careful statement of what problems need to be solved, and we don't have that right now.

— What sort of statement of requirements would be useful for the IETF? ICANN is looking for assistance, so it asks the right questions, so that it comes up with a statement of requirement that is useful for the IETF. Comments heard: 1. Back-and-forth is useful, rather than a statement; 2. The iteration process of creating the problem statement which starts to look at the solution space, which in turn frames the problem space; 3. Important to focus on the issues/impact further down the DNS tree, not just at the first level of delegation.

— 3 separate issues could be defined. One that has no impact on IETF is what registry policy is. Second is "user experience and sameness", but have to define what "same" means to different people, but for certain subset of same that can already be done in the DNS today. Third is other variant issues like final-form versus medial-form. Comments heard: when we talk about user experience, it is not just end user but system admins etc. If you solve the problem in the DNS but it means the admin has to configure lots of variants in mail/web/etc. configs, you've just shifted the work to a different place, not solved it. If it is a requirement that configuring different variants for administrators goes away, it needs to solve the problem beyond the DNS space.

— Need to be careful about false positives: it is probably worse to receive a "the website is not configured" to a variant domain on a web site, than to get an NXDOMAIN. If you delegate a bunch of variants to point to the one place and the target machine can't cope, it is not useful.

— .GR had to register variants from day 1, often register 4-5 names as bundles, and use the DNAME in the DNS. Soon found out DNAME was not the right way to deal with it, because there are specific things are not supported. FIrstly, the first level were not the same. e.g. cnn.com<http://cnn.com/> and www.cnn.com<http://www.cnn.com/>, because of the server; but if it is IDN, www.cnn.com<http://www.cnn.com/> would work, cnn.com<http://cnn.com/> would go nowhere. DNAME starts one level below. There needs to be some kind of mechanism to take 3 different TLDs and turn them into 1. Recognise there are DNSSEC issues to be considered.

— One of the arguments is the users can manage variants, others say it isn't. It is useful to know if that is a consideration to help make the tradeoffs. Another thing to recognise is there are things we simply won't do, anxious to communicate there are some things that can't be changed. e.g. Not going to make an RR type that makes DNSSEC deployment impractical,  Not going to do something that solves problems that make things easy at the top-level, but make life hard for those further down the tree. Need to be consistent throughout the DNS. One of the proposals works only for leaf zones only, maybe that is an OK tradeoff, but suspicious of that.

— Concern that talk is around trying to resolve 2 domains names resolve to 1 IP address, particular the focus of those with already have 2 strings. As soon as you make those domains look the same, we'll run into the next problem, whatever that is. Just solving that small problem, without looking at the other potential problems, is being naive and need to look to the bigger problems, so that any solution doesn't make other problems worse/bigger/difficult to solve.

— There are end user expectations, wide range of end users, not just the user who uses a web browser; its the web developer that codes a web page; the
guy that runs the website; guy that manages the DNS throughout the tree; developers that build software; pretty sure we'll invent security problems we havent thought of before. Concerned that being dangerous by assming the answer to the is in the DNS. (Disagree, we're not) Pretty sure we could get HTTP/SMTP/etc people here. Need to work out what the use cases are, and not just assume they are DNS solutions. Lets identify the use cases we know of. People ave tried before, you'll be able to help us. Can we try and focus on identifying the use cases first, and go from there?

— Linguistic scope is up to policy to come up. Dont care how you decide which strings are considered equivalent. Do care if there is a difference between whether they are universal or zone-by-zone equivelance, as it dictates solution. cross site scripting issues, mail configuration, etc. are issues that are in the middle and the ones that need to be gone through. Who are the appropriate people to help solve these problems.

— See the criticial piece that is missing is "How do you mean, the user needs these things to work the same way?" Dont know how else to do that but to talk about the use case of the users, not in specifics - not to survey the world - but can talk to linguistic people, UI / human interaction people, and understand "What happens to an Arabic user that is confronted with this string? What will the user do?" Last time we faced this problem, made the decision in the DNS "color" and "colour" are not the same label. User community may be different when DNS first invented, than a new iPhone user who types in an IDN. New users dont have a theory on how the computer works. Dont know if it OK to have one canonical label, and the rest are second class. If we agree on that a bunch of solutions can be taken off the table. Thats the kind of information wanted from this effort. This effort will be hopeless unless get the feedback on sameness. It is a lousy tradeoff in configurations balloon.

— Regarding use cases: Non-technical end user who uses an iPhone. Describing a context, and a user of the context, so the discussion is not merely between 2 strings, but rather the role of the confusion to a particular user. Could come up with, for example, a use case once a year that doesn't matter very much. Probably not a problem to solve. On the other hand, happens frequently and consequence is really bad. That is a higher priority. Comparing errors in context of other problems in use, makes it easier to understand importance and alternatives.

— Conclusion: Meeting wasnt to solve problems, but to share a sense of the enormity of the task. Not saying that ICANN's project will come up with any case that requires a technical or DNS solution, but there may be some that are best solved with one. Would like to keep that option open. This has been an informal meeting, taking advantage of people that were available here. Some complaint it wasn't scheduled in time, no proper agenda, not open to all. That wasnt the intent. If there is need for a formal meeting, ICANN can help organise a meeting. Leave that to you to decide. Clearly ICANN needs help in identifying the use cases, help in looking at those, considering the implications of any possible solution, like configuration problems, abuse problems, whatever. Have as much input that is appropriate.

ps. The formal meeting that was on the agenda was recorded, you can view it athttp://icann.adobeconnect.com/p73581095/

kim