[vip] Integrated Issues Report draft

[Patrik Fältström]

On 11 jan 2012, at 01:59, Francisco Arias wrote:

> On 12/22/11 3:55 AM, "Patrik Fältström" <patrik at 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