Patrik, I believe your comments are based on the 19-Dec version. See below my responses. Apologies for the delay, just want to say that we did look into your comments before publishing the 23-Dec version that is published for public comment. On 12/22/11 3:55 AM, "Patrik Fältström" <patrik@frobbit.se> wrote:
A few comments (in the order I was browsing/reading the report):
1. Please add an executive summary
Done.
2. That for example a server must be configured to accept mail to all variants of a domain I see as a feature, and not a problem. Reason for this is the otherwise risk of denial of service attacks where third parties might redirect domains to the mailbox in question. So be a bit more careful with what you see as "problems". They might be "issues" to consider, but I definitely do not see them as problems. I.e. specifically the issue that DNAME/CNAME is only a one-way-link.
We are listing issues in the report, the fact that you have to configure your mail server with all the names you want to "be known" is an issue worth considering for those that want what we call mirroring in the report. We are only indicating that by doing DNAME/CNAME/Parallel provisioning you won't solve much for some applications, as is the case with email.
3. Many of the examples regarding email, http etc only concentrate on the configuration on the _receiving_ end of a flow. Not the _sending_ side. I.e. even though a mail server magically can detect that X and Y are variants, and they should be equivalent, it is still required to configure whether X or Y is to be used when _sending_ mail, as source. Many conclusions seems to come to the conclusion that as long as 1) lookup etc of X and Y results in "the same result"; and 2) receiving end can detect that X and Y should be treated "the same", the problem is solved. That is not the case.
We only intended to provide examples for each issue, not to present all the examples of the same issue.
4. Issues related to rewrite of application layer domain names before used in applications (such as TLS) is correct that it must be specified, as it is not today. I think the document should even _RECOMMEND_ such an action. It would even make things like DANE solutions and use of SRV records in general for virtual hosting MUCH easier. I.e. Variants is just a piece of the problem.
This is merely an issues report, we simply flag the issue.
5. Many of the problems with "X and Y should be the same" are issues that already exists today. Much of the text is written as if this is something new, but it is not (where for example X and Y are two common spellings of the same word in LDH). I think that could be pointed out very early (in that missing executive summary). That said, no one have been looking at the problem before, and if there should be a common solution to it.
Not sure what part you are referring to where we say this is something new. In any case, I don't think it is relevant whether this is a new or an old set of issues. The fact is that if you want mirroring variants you have to confront these issues.
6. I thank you for the definition of the terms Allocated/Activated/Delegated! Much appreciated.
Great!, at least we did something good :-) I should say this is coming from the discussion in the various case studies, so thanks to all the volunteers.
7. Many of the issues where the report say "maintenance cost" builds upon the thinking that cost for management is increasing "linearly" with the number of X and Y that should be equal, and that specifically exponential growth if you have X, Y and Z that is to be used in "all possible combinations". That is a view that only holds if you use that kind of management tools. Already today, my personal management tools treat example.X and www.example.X as "the same", so the addition of the 2nd domain does increase the cost of operation with about...zero (of course, there is an incremental cost in some cases in the case of memory in the web servers hash table for virtual hosts, but that is about zero). I recommend you talk about "higher maintenance" only when it really is higher maintenance, and "higher maintenance with classical tools, but zero extra cost as the process can be automated" when in reality that is the case.
Agree that there are different progressions of increment in the complexity of the various issues identified in the report. However, we didn't have time (nor realize the need for it) to develop an scale or other tool to better convey the scope of the increment.
8. Under registry/registrar I would like to see a recommendation that ICANN develop a few standardized alternatives for what happens when a registrar is requesting registration of a domain name. Such as: "Implicit registration of one or more other domain names as well", "blocking of ...", "no implicit registration..." etc. Those different alternatives are then the only choices for the registry to choose from when designing their own version of the EPP protocol. A list like that would also make it easier for IETF to take on the task to come up with whatever extensions are needed. As it is today, the registry/registrar extension mechanism is completely broken, where registries have invented their own version of such relatively simple operations like "update IP address of nameserver", "register a domain name", "transfer a domain name from one registrar to another one" and "renew a domain name". I envision, if not variants are more clearly specified what different alternatives exists, that EPP work in this area will make things much more crazy.
Although, this looks interesting and important, I think it is beyond the scope of the report.
9. In the discussion on whois, please look at the whois review team report and SSAC document SAC051, and adjust so that you reference those when possible.
Fixed.
10. In the discussion on whois (and possibly other places) use your own terminology and not statements like "...but is not present in the DNS...".
Fixed.
11. Regarding suggestions for new work (section 7), which ones of those do you believe must be done before Jan 12, 2012? And if that is not possible, what do you suggest should be done initially in the gTLD process given you in the beginning talk about the need for being conservative?
See Appendix 5. Regards, __ Francisco.
I think thats it...for now :-)
Patrik Fältström
On 20 dec 2011, at 16:47, Francisco Arias wrote:
Colleagues,
A new draft version is available, you can see the message here:
http://mm.icann.org/pipermail/integrated-vip/2011-December/000354.html
We believe we are close to a final-draft version that will be put for public comment. Any input you may have in the next couple of days would be greatly appreciated.
Regards,
__
Francisco.
On 12/5/11 9:51 PM, "Francisco Arias" <francisco.arias@icann.org> wrote:
In case you have trouble with fonts, try the PDF version attached.
__
Francisco.
On 12/5/11 9:13 PM, "Francisco Arias" <francisco.arias@icann.org> wrote:
Colleagues,
Your input on the draft report is appreciated. The team of volunteers that is helping ICANN staff and consultants write the report is meeting next week on 12-13 December to discuss this draft. Since this is the first draft, at this point the high level input is most useful; what is missing, what should not be there, what is on the right track, what isn't and why, etc.
We are considering having another draft shortly after the meeting, and then the draft final report for public comment before the year's end.
__
Francisco.
On 12/5/11 7:19 PM, "Karen Lentz" <karen.lentz@icann.org> wrote:
Dear colleagues,
As discussed last week, we are circulating for your information the current draft of the Integrated Issues Report, compiling all of the material created to date.
We will circulate the section on User Experience issues (section 5.3.2 of the report) under separate cover shortly, so that we can begin discussing this set of issues.
This draft of the report is intended to inform the team¹s discussions at the face-to-face meetings next week. All team members are requested to review and become familiar with the document prior to the meeting. We expect that discussions on the mailing list will continue in the interim.
On this Wednesday¹s team call we will also discuss the agenda for the face-to-face meeting, and any suggestions for the agenda from the team based on the current draft are also welcome.
Best regards,
Karen Lentz ICANN