Re: [NA-Discuss] On the cost of application, and Joint Application Support related
On 4/4/11 4:10 AM, Patrick Vande Walle wrote:
imposing DNSSEC from day one on new gTLDs is *also* a competition issue
Of course it is a competition policy issue. Synchronous mass creation can only be accomplished where one or more critical resources have limited allocation regimes, but significant reserve capacity in one or a few actors, through monopoly, or oligopoly. Employer independent DNSSEC experience is limited. Verisign, Afilias, NeuStar and CORE have DNSSEC experience and excess capacity. In the 2000 round, all but one of .aero, .biz, .coop, .info, .museum, .name and .pro arose from separate capitalizations, separate technical capacities, and separate staffs. Only .name has been acquired by the incumbent monopoly operator, a competition policy error on ICANN's part. Each requirement in excess of the 2000 and 2004 requirements has the effect, individually in the case of the empty zone signing requirement with key management cost prior to first production resolution, and in the aggregate in other cases, of restricting the structural choices of applicants. The imposition of synchronous mass requirements can only result in significantly distinct outcome, much more likely to favor incumbents with reserve capacity over new entrants lacking that capacity, than the iterative imposition of the same requirements, where capacity is not some neutral condition or consequence of merit, but the likely consequence of mere possession of a prior grant of franchise. The impossibility of the ALAC advancing a coherent position which advances the public interest is demonstrated by individuals who are overtly destructive to applicants those individuals deem lacking the capacity to meet a requirement which they advocate and cannot justify except through appeal to externalities, and by individuals who are covertly destructive to applicants through the advocacy of regimes of resources starvation.
I hope this answers your concerns.
Only in part. The indifference to applicant cost, and to operational utility, of a At Large RO contributor, and the non-responsiveness of that contributor, as a contributor to an At Large consensus based activity, raise both substance and process issues. Make no mistake, when I observed cache poisoning demonstrated in a small meeting of DNS people at the Dublin IETF meeting in under 3 seconds, I fully understood that the economics of attack had changed. However, attack has not become "free" and therefore not pervasive, and rational attackers rationally target, and zones for which less financial, or political benefit exists have less risk. Zones which exist for the purposes of sustained financial transaction are worth signing. Zones which exist for the purposes of Pay Per Click advertizing inventory disposal are not worth signing. Signing .mil may have some operational utility. The operational utility of signing .museum, other than the benefit to the community of a first gTLD implementer experience(*) is far more conjectural. It is less than sufficient to comment, when the DAG has "DNSSEC is mandatory to implement", that "operators are encouraged to deploy DNSSEC from day one". The correct comment is "advised only when the utility of zone signing and key management justifies the cost, as with all other engineering choices". The star above is intended to draw attention to another inherent failure of synchronous mass requirements. The operational experience of each registry informs not only its participants, but informs any successors. As one wag put it, "time is nature's way of ensuring that everything doesn't happen at once". The model Staff has chosen, and several At Large participants advocate as well, a large cohort of simultaneous events, to prevent a "first in market" effect, ensures that no experience, including experience resulting in failure, can be known to any members of the cohort. Finding "no first in market" to be a greater public interest than the public interest in empirical decision making is peculiar. Eric
Hi Eric, On 4 April 2011 09:14, Eric Brunner-Williams <ebw@abenaki.wabanaki.net>wrote: The impossibility of the ALAC advancing a coherent position which
advances the public interest is demonstrated by individuals who are overtly destructive to applicants those individuals deem lacking the capacity to meet a requirement which they advocate and cannot justify except through appeal to externalities, and by individuals who are covertly destructive to applicants through the advocacy of regimes of resources starvation.
While I agree with in in some areas, it's not helpful to personalise things. Given our limited human resources, ICANN At-Large has to rely on the people who step forward to help and to wordsmith. The need for broadly-based assistance to do such a time-consuming task is the reason ALAC has working groups (that are open to all ALS and NARALO individual members, not just ALAC members). If you don't like what's there, contribute to the process. I can understand characterising ideas as destructive, but referring to *people* as destructive is a nasty accusation bordering on abuse -- is it really warranted here? Please remember that ALAC operates globally, and outside this North American sandbox you've chosen your tone is extremely uncollegial to say the least. Is your goal confrontation and alienation -- or a useful global At-Large consensus that can benefit from the depth of your experience? If you truly believe the existing policy to be destructive to the public good, that's a serious issue that I want to confront and address directly. But let's do this in a way that attempts to educate your opponents rather than insult or bully them.
I hope this answers your concerns.
Only in part. The indifference to applicant cost, and to operational utility, of a At Large RO contributor, and the non-responsiveness of that contributor, as a contributor to an At Large consensus based activity, raise both substance and process issues.
We work with the people who step forward. That kind of human resource dependency is common to most volunteer orgs with which I've ever worked. Actively participating in working groups during the formative stages of policy development is always preferable to staying outside the process and then complaining that the finished product doesn't reflect your contrary viewpoint. The contributor is non-responsive because you've addressed him in a forum to which he doesn't belong. Surely you've been around ICANN and At-Large long enough to understand the basic courtesies of speaking *to* people rather than *at* them.
Make no mistake, when I observed cache poisoning demonstrated in a small meeting of DNS people at the Dublin IETF meeting in under 3 seconds, I fully understood that the economics of attack had changed. However, attack has not become "free" and therefore not pervasive, and rational attackers rationally target, and zones for which less financial, or political benefit exists have less risk.
Eric, your depth in this field is quite amazing -- and potentially invaluable to the process of At-Large policy development. It certainly is at a level that sometimes makes my dizzy (which also suggests that we have a task in making your points more accessible to the casual Internet end user). But for that to happen you need to meet some of the other policy developers part-way. You don't have to be buddies with everyone, but please try to be less antagonistic. Now... some of the frustration you have is quite understandable. The shortage of support staff has made it difficult to let At-Large members know what the various policy working groups have on their plates at any given time. But, again, you should be aware enough of this process to at least know who to ask.
Zones which exist for the purposes of sustained financial transaction are worth signing. Zones which exist for the purposes of Pay Per Click advertizing inventory disposal are not worth signing. Signing .mil may have some operational utility. The operational utility of signing .museum, other than the benefit to the community of a first gTLD implementer experience(*) is far more conjectural.
Agreed.
It is less than sufficient to comment, when the DAG has "DNSSEC is mandatory to implement", that "operators are encouraged to deploy DNSSEC from day one". The correct comment is "advised only when the utility of zone signing and key management justifies the cost, as with all other engineering choices".
That's quite reasonable. Making DNSSEC required where it's not necessary may be an unfair indirect barrier to entry for some. Patrick, is there a reason NOT to modify our position this way? And Eric, I suggest that if you actually want maximum impact for your well-grounded positions, I suggest you re-consider your choices of sandboxes in which to debate them as well as the tone of your argument. These are not North-America-only issues. Either the working group or the global ALAC list would have been a far more suitable venue for this debate. The only time IMO that NARALO-specific discussions on global policy is warranted is when ESTABLISHED policy of ALAC runs counter to the opinion of NARALO, sufficient to justify a minority statement. But before the ALAC policy is set in stone it's inappropriate to limit debate on a per-region basis, IMO. I agree with your points, but would like to hear Parick's answer. Let's please keep this debate as productive as possible, if the goal is to make public-interest policy rather than publicly embarrass people. - Evan
Evan, 1. If you can, find a way to write interlinear comments that retain the attributions. 2. I described an exchange of notes on another ALAC list. 3. At no time, other than to refer to Patrick as the initial drafter of a document developed on that other ALAC list, did I suggest that the view I characterized as harmful to applicants came from that particular contributor to that draft. As small as the number of contributors are to that list, and it is quite small, that number is in excess of two (2). If you could refrain from confusing issues with your highly developed sense of email politess, that would at least not remove information from the mailing list as a means of communications. Anyone reading your contribution to this subject would conclude that Patrick and I disagree on something fundamental, which I think will surprise Patrick as much as it surprises me. Eric
Hi again, On 4 April 2011 12:50, Eric Brunner-Williams <ebw@abenaki.wabanaki.net>wrote:
1. If you can, find a way to write interlinear comments that retain the attributions.
There weren't many in the original mail of yours that I responded to.
2. I described an exchange of notes on another ALAC list.
That wasn't made clear, nor was the rationale behind moving from a global list to regional one on a global issue. 3. At no time, other than to refer to Patrick as the initial drafter of a
document developed on that other ALAC list, did I suggest that the view I characterized as harmful to applicants came from that particular contributor to that draft. As small as the number of contributors are to that list, and it is quite small, that number is in excess of two (2).
Again, unclear. If you are going to say that *people* are harmful (as opposed to their ideas or opinions), you ought to indicate who. Otherwise, what's the point of the name-calling?
If you could refrain from confusing issues with your highly developed sense of email politess, that would at least not remove information from the mailing list as a means of communications.
That's probably the first time in many decades of using email -- dating back to my telly!evan UUCP days -- that I've ever been accused of excess politeness. I can't tell whether to be flattered or insulted. In any case, I think most would agree that email politeness is a resource suffering from extreme scarcity.
Anyone reading your contribution to this subject would conclude that Patrick and I disagree on something fundamental, which I think will surprise Patrick as much as it surprises me.
Excellent. That means having the two of you collaborating on a decent consensus position will be easier than I envisioned. -- Evan Leibovitch, Toronto Canada Em: evan at telly dot org Sk: evanleibovitch Tw: el56
I must agree with this e-mail. I have tried to engage Eric and have been treated rudely and in a bullying manner which made me shut down. This is said in my own personal manner and is not subject to any group. D Darlene A. Thompson CAP Administrator N-CAP/Department of Education P.O. Box 1000, Station 910 Iqaluit, NU X0A 0H0 Phone: (867) 975-5631 Fax: (867) 975-5610 dthompson@gov.nu.ca ________________________________________ From: na-discuss-bounces@atlarge-lists.icann.org [na-discuss-bounces@atlarge-lists.icann.org] on behalf of Evan Leibovitch [evan@telly.org] Sent: Monday, April 04, 2011 12:03 PM To: Eric Brunner-Williams Cc: ICANN AtLarge Staff; patrick@vande-walle.eu; na-discuss@atlarge-lists.icann.org Subject: Re: [NA-Discuss] On the cost of application, and Joint Application Support related Hi Eric, On 4 April 2011 09:14, Eric Brunner-Williams <ebw@abenaki.wabanaki.net>wrote: The impossibility of the ALAC advancing a coherent position which
advances the public interest is demonstrated by individuals who are overtly destructive to applicants those individuals deem lacking the capacity to meet a requirement which they advocate and cannot justify except through appeal to externalities, and by individuals who are covertly destructive to applicants through the advocacy of regimes of resources starvation.
While I agree with in in some areas, it's not helpful to personalise things. Given our limited human resources, ICANN At-Large has to rely on the people who step forward to help and to wordsmith. The need for broadly-based assistance to do such a time-consuming task is the reason ALAC has working groups (that are open to all ALS and NARALO individual members, not just ALAC members). If you don't like what's there, contribute to the process. I can understand characterising ideas as destructive, but referring to *people* as destructive is a nasty accusation bordering on abuse -- is it really warranted here? Please remember that ALAC operates globally, and outside this North American sandbox you've chosen your tone is extremely uncollegial to say the least. Is your goal confrontation and alienation -- or a useful global At-Large consensus that can benefit from the depth of your experience? If you truly believe the existing policy to be destructive to the public good, that's a serious issue that I want to confront and address directly. But let's do this in a way that attempts to educate your opponents rather than insult or bully them.
I hope this answers your concerns.
Only in part. The indifference to applicant cost, and to operational utility, of a At Large RO contributor, and the non-responsiveness of that contributor, as a contributor to an At Large consensus based activity, raise both substance and process issues.
We work with the people who step forward. That kind of human resource dependency is common to most volunteer orgs with which I've ever worked. Actively participating in working groups during the formative stages of policy development is always preferable to staying outside the process and then complaining that the finished product doesn't reflect your contrary viewpoint. The contributor is non-responsive because you've addressed him in a forum to which he doesn't belong. Surely you've been around ICANN and At-Large long enough to understand the basic courtesies of speaking *to* people rather than *at* them.
Make no mistake, when I observed cache poisoning demonstrated in a small meeting of DNS people at the Dublin IETF meeting in under 3 seconds, I fully understood that the economics of attack had changed. However, attack has not become "free" and therefore not pervasive, and rational attackers rationally target, and zones for which less financial, or political benefit exists have less risk.
Eric, your depth in this field is quite amazing -- and potentially invaluable to the process of At-Large policy development. It certainly is at a level that sometimes makes my dizzy (which also suggests that we have a task in making your points more accessible to the casual Internet end user). But for that to happen you need to meet some of the other policy developers part-way. You don't have to be buddies with everyone, but please try to be less antagonistic. Now... some of the frustration you have is quite understandable. The shortage of support staff has made it difficult to let At-Large members know what the various policy working groups have on their plates at any given time. But, again, you should be aware enough of this process to at least know who to ask.
Zones which exist for the purposes of sustained financial transaction are worth signing. Zones which exist for the purposes of Pay Per Click advertizing inventory disposal are not worth signing. Signing .mil may have some operational utility. The operational utility of signing .museum, other than the benefit to the community of a first gTLD implementer experience(*) is far more conjectural.
Agreed.
It is less than sufficient to comment, when the DAG has "DNSSEC is mandatory to implement", that "operators are encouraged to deploy DNSSEC from day one". The correct comment is "advised only when the utility of zone signing and key management justifies the cost, as with all other engineering choices".
That's quite reasonable. Making DNSSEC required where it's not necessary may be an unfair indirect barrier to entry for some. Patrick, is there a reason NOT to modify our position this way? And Eric, I suggest that if you actually want maximum impact for your well-grounded positions, I suggest you re-consider your choices of sandboxes in which to debate them as well as the tone of your argument. These are not North-America-only issues. Either the working group or the global ALAC list would have been a far more suitable venue for this debate. The only time IMO that NARALO-specific discussions on global policy is warranted is when ESTABLISHED policy of ALAC runs counter to the opinion of NARALO, sufficient to justify a minority statement. But before the ALAC policy is set in stone it's inappropriate to limit debate on a per-region basis, IMO. I agree with your points, but would like to hear Parick's answer. Let's please keep this debate as productive as possible, if the goal is to make public-interest policy rather than publicly embarrass people. - Evan ------ NA-Discuss mailing list NA-Discuss@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/na-discuss Visit the NARALO online at http://www.naralo.org ------
Eric, Le 04/04/2011 14:14, Eric Brunner-Williams a écrit :
It is less than sufficient to comment, when the DAG has "DNSSEC is mandatory to implement", that "operators are encouraged to deploy DNSSEC from day one". The correct comment is "advised only when the utility of zone signing and key management justifies the cost, as with all other engineering choices".
You will have probably just received the following: Please note that Olivier Crépin-Leblond, ALAC Chairman, has extended the call for comments on the draft ALAC Statement on the Public Call by the Stability, Security and Resilience of the DNS Review Team (SSR-RT) *to 23:59 UTC on Wednesday, 6 April.* I hope that this will give you and Patrick (and any other interested parties) sometime to be able to amend the current statement to one which is palatable to all parties. I understand that the statement as it stands favours DNSSEC for everything, as seen from the discussion on the Technical Issues WG list and the other solution is to favour choice, "when the utility of zone signing and key management justifies the cost". Having understood the logic of the pros & cons behind each choice, I'd be inclined to say that insisting on DNSSEC for everyone would be a top-down requisite, whilst giving the choice to the TLD owner is a bottom-up process. I favour bottom-up. But that's my personal choice. Now please can others chime in on this, before we run out of time on a status quo? What are the risks (if any) to leaving the choice on DNSSEC use to applicants & individual Registry choice? Kind regards, Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
On 4 Apr 2011, at 19:41, Olivier MJ Crepin-Leblond wrote:
Eric,
Le 04/04/2011 14:14, Eric Brunner-Williams a écrit :
It is less than sufficient to comment, when the DAG has "DNSSEC is mandatory to implement", that "operators are encouraged to deploy DNSSEC from day one". The correct comment is "advised only when the utility of zone signing and key management justifies the cost, as with all other engineering choices".
You will have probably just received the following: Please note that Olivier Crépin-Leblond, ALAC Chairman, has extended the call for comments on the draft ALAC Statement on the Public Call by the Stability, Security and Resilience of the DNS Review Team (SSR-RT) *to 23:59 UTC on Wednesday, 6 April.*
I hope that this will give you and Patrick (and any other interested parties) sometime to be able to amend the current statement to one which is palatable to all parties. I understand that the statement as it stands favours DNSSEC for everything, as seen from the discussion on the Technical Issues WG list and the other solution is to favour choice, "when the utility of zone signing and key management justifies the cost".
Having understood the logic of the pros & cons behind each choice, I'd be inclined to say that insisting on DNSSEC for everyone would be a top-down requisite, whilst giving the choice to the TLD owner is a bottom-up process. I favour bottom-up. But that's my personal choice.
Now please can others chime in on this, before we run out of time on a status quo? What are the risks (if any) to leaving the choice on DNSSEC use to applicants & individual Registry choice?
Olivier It depends on how you view DNSSEC If you view it as being a "pressing" issue that "needs" to be addressed everywhere in the DNS, then you'll probably want to have it in all TLDs But, personally, I don't think that DNSSEC is as important as many other aspects of the DNS and if a registry operator does not want to offer it from day 0 then why force them? Other technical issues are probably a lot more pressing, like IPv6, though some would argue that imposing IPv6 is a pre-requisite is too limiting for some applicants. Personally I'd disagree. I'll go back to lurking now Regards Michele Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
While I agree with Michele about DNSSEC, I do not agree about IPv6, the requirement for which is still, to my mind, primarily political. a. On 4 Apr 2011, at 13:55, Michele Neylon :: Blacknight wrote:
On 4 Apr 2011, at 19:41, Olivier MJ Crepin-Leblond wrote:
Eric,
Le 04/04/2011 14:14, Eric Brunner-Williams a écrit :
It is less than sufficient to comment, when the DAG has "DNSSEC is mandatory to implement", that "operators are encouraged to deploy DNSSEC from day one". The correct comment is "advised only when the utility of zone signing and key management justifies the cost, as with all other engineering choices".
You will have probably just received the following: Please note that Olivier Crépin-Leblond, ALAC Chairman, has extended the call for comments on the draft ALAC Statement on the Public Call by the Stability, Security and Resilience of the DNS Review Team (SSR-RT) *to 23:59 UTC on Wednesday, 6 April.*
I hope that this will give you and Patrick (and any other interested parties) sometime to be able to amend the current statement to one which is palatable to all parties. I understand that the statement as it stands favours DNSSEC for everything, as seen from the discussion on the Technical Issues WG list and the other solution is to favour choice, "when the utility of zone signing and key management justifies the cost".
Having understood the logic of the pros & cons behind each choice, I'd be inclined to say that insisting on DNSSEC for everyone would be a top-down requisite, whilst giving the choice to the TLD owner is a bottom-up process. I favour bottom-up. But that's my personal choice.
Now please can others chime in on this, before we run out of time on a status quo? What are the risks (if any) to leaving the choice on DNSSEC use to applicants & individual Registry choice?
Olivier
It depends on how you view DNSSEC
If you view it as being a "pressing" issue that "needs" to be addressed everywhere in the DNS, then you'll probably want to have it in all TLDs
But, personally, I don't think that DNSSEC is as important as many other aspects of the DNS and if a registry operator does not want to offer it from day 0 then why force them?
Other technical issues are probably a lot more pressing, like IPv6, though some would argue that imposing IPv6 is a pre-requisite is too limiting for some applicants. Personally I'd disagree.
I'll go back to lurking now
Regards
Michele
Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612 UK: 0844 484 9361 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
------ NA-Discuss mailing list NA-Discuss@atlarge-lists.icann.org https://atlarge-lists.icann.org/mailman/listinfo/na-discuss
Visit the NARALO online at http://www.naralo.org ------
While I agree with Michele about DNSSEC, I do not agree about IPv6, the requirement for which is still, to my mind, primarily political.
I set up IPv6 on my web server last month and was surprised how much v6 traffic it's getting. There are already cable and mobile networks that can't get sufficient blocks of v4 space, so they're native v6 and connect to the v4 net through layers of NAT. For e-mail, it makes no difference and it'll be many years before any mail you want will need v6, but for web servers it makes sense to look at v6 now. Also, if you feel that end users should be able to run their own servers at home, you need v6 for that. I blogged at some length on this: http://jl.ly/Internet/v6incor.html http://jl.ly/Internet/v6incor2.html http://jl.ly/Internet/v6incor3.html Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
participants (7)
-
Avri Doria -
Eric Brunner-Williams -
Evan Leibovitch -
John R. Levine -
Michele Neylon :: Blacknight -
Olivier MJ Crepin-Leblond -
Thompson, Darlene