Integrated Issues Report draft
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
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
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
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
A few comments (in the order I was browsing/reading the report): 1. Please add an executive summary 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. 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. 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. 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. 6. I thank you for the definition of the terms Allocated/Activated/Delegated! Much appreciated. 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. 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. 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. 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...". 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? 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
This reminds me that I have the draft on ny reading list. I haven't done a proper read yet but couldn't help noticing the remarks about Cyrillic in the appendix. Some nits about this: - There have been more spellings reforms as far as I know. Peter the Great (or "the First" as the Russians say) initiated a major one (with advice by Dutch typographers) which wiped out more characters then the SU did. Around 1880 was another major one as well. I'm not sure whether it is a good idea to single out a specific reform - I have always learned that modern russian has 33 characters (and not the 32 mentioned). The are two examples of use of diacritics in the same paragraph. These are considered separate characters in Russian alphabets. If one consider these as characters with diacrits (as one could easely do), the Russian alphabet would have 31 characters. Of course, I'm not an expert in Cyrillic and slavic languages, but it might be that other readers night be just as puzzled as me. I hope to find time to read the whole draft this week. jaap
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
As annonced the documentation of the Interplus fringe to fringe framework is now published as a Draft by the IUTF. http://forum.icann.org/lists/new-gtld-applicant-support-handbook/msg00013.ht... http://iutf.org/wiki/Internet%2B_architectural_Framework This I_D will be debated on iutf@iutf.org (http://iutf.org/wiki) and on iucg@ietf.org (http://iucg.org/wiki). Variants are considered as supported by orthotypography and polynymy. The debate and experimentation will say how to continue. Comments welcome. jfc
On 11 jan 2012, at 01:59, Francisco Arias wrote:
On 12/22/11 3:55 AM, "Patrik Fältström" <patrik@frobbit.se> wrote:
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.
My point is that this is what we _already_ have to do. It is a _new_ issue, so claiming it is I think is wrong. What you could do is though to recognize this is already a problem, but the need is increasing when variants are introduced at a larger scale.
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.
But the problem is that if you only look at the receiving side (as you have done), the conclusions are wrong.
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.
My point was that the way the report is written, it sounds like if the findings are new, all of them. Some of what you have found are new issues, some get worse, some are not new at all. I just suggested you add a clarification on the matter so that people are not confused.
6. I thank you for the definition of the terms Allocated/Activated/Delegated! Much appreciated.
Great!, at least we did something good :-)
Ha ha ha!
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.
Ok, fair. But what I really say is that some cases where you talk about "higher maintenance costs" is absolutely wrong. Because if you can generate for example zone files automatically using language tables, the cost of introducing variants have to do with the increased size of the zone -- and nothing else.
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.
Ok, but this can potentially be a real issue compared to for example the maintenance costs. Today, interaction between registry and registrar model is based upon one transaction per domain name that is registered. If we have variants, the number of transactions can increase, and create race condition in systems that for example handle backorder. This is because of this an additional issue that I think you have forgot, while you have pointed out a number of things that I do not think are as important issues. Patrik
Hi Patrik, At 01:07 11-01-2012, Patrik Fältström wrote:
My point is that this is what we _already_ have to do. It is a _new_ issue, so claiming it is I think is wrong.
I don't see the point of stating the obvious as an issue. I would not be able to say that the claim is wrong as ICANN said so in a report. :-) Regards, -sm
participants (6)
-
Francisco Arias -
Jaap Akkerhuis -
JFC Morfin -
Karen Lentz -
Patrik Fältström -
SM