CircleID: Comments

RE: EI, EI - NO! (Suresh Ramasubramanian)

2010-03-17T22:10:45-08:00

I find your article's tone quite smug and self satisfied, and am quite glad that there's a reasonable counterpoint at http://www.circleid.com/posts/icann_expressions_of_interest_eowhy/

If you're resting easy that this proposal is dead and buried, I think you need to revise that expectation a bit.

Link | Posted on Mar 17, 2010 10:10 PM PDT by Suresh Ramasubramanian

RE: Domain Registrars & Registries: Don't Say You Weren't Warned (Suresh Ramasubramanian)

2010-03-17T22:07:12-08:00

Beyond it driving domain squatters out of business that is.

Link | Posted on Mar 17, 2010 10:07 PM PDT by Suresh Ramasubramanian

RE: Could This Be the Silver Bullet for Cloud Computing (Virendra Gandhi)

2010-03-16T09:52:08-08:00

Darren, First the TLN will be a dot suffix like a TLD but instead register the user differently. I had mentioned that it has to be ‘all’ inclusive, including the registries, as they have the set up in place, which can be adapted to work as registries for TLN.

I don’t agree cloud computing will benefit developing countries more than the developed ones, if you are talking of India, the term now used is emerging country. We are also not immune to what is happening in the developed world for example, after Lehmann went burst, it was hell, we too have lost a lot of wealth, but the investments are happening in leaps and bounds. So the infrastructure is fairly ok, it is the application and services, which have to be developed and launched and that too universally, which are important to make cloud computing work. Hopefully this discussion can bring together all those who believe they have such offerings (including competing services) with their own revenue model and respecting their being in stealth mode.

Link | Posted on Mar 16, 2010 9:52 AM PDT by Virendra Gandhi

RE: "Thin Brand Line" Breaks as Canon Announces Plans for .CANON (Antony Van Couvering)

2010-03-16T09:44:27-08:00

We shall see. I don't think there will be a pell-mell rush, but as a wise man said, "No-one likes to be first, and no-one likes to be last." Permission has been granted, and the "omerta" that has heretofore prevailed is now broken.

Link | Posted on Mar 16, 2010 9:44 AM PDT by Antony Van Couvering

RE: "Thin Brand Line" Breaks as Canon Announces Plans for .CANON (Michele Neylon)

2010-03-16T09:41:32-08:00

Antony

I'd have to disagree with you on this. There is absolutely nothing forcing brand owners to do anything right now. They can simply sit back and wait.

They won't gain anything or lose anything by waiting. It's not like anyone else could pitch of .nike or .warner anyway, as they wouldn't have any rights in the name.

Michele

Link | Posted on Mar 16, 2010 9:41 AM PDT by Michele Neylon

RE: 25 Years of .COM, Clinton to Address Policy Makers for the Occasion (Daniel R. Tobias)

2010-03-16T08:11:56-08:00

.org, .net, .edu, .gov, and .mil are of equal age to .com, all of which were introduced at the same time. I believe there was at least one .edu registration before the first .com.

Link | Posted on Mar 16, 2010 8:11 AM PDT by Daniel R. Tobias

RE: A Little Flexibility from ICANN and We Might Just Get IDNs... for Everyone (Richard J Tindal)

2010-03-16T06:38:52-08:00

I think we'll find a solution to this. As you know, the Board passed a Resolution in Nairobi establishing a Working Group whose mission is a to find a sustainable way to support limited-resource applicants. I plan to be in that Group, as I'm sure you will. We'll find a way to allow these applicants to participate in the process.

Link | Posted on Mar 16, 2010 6:38 AM PDT by Richard J Tindal

RE: Could This Be the Silver Bullet for Cloud Computing (Darren Wilkins)

2010-03-16T06:00:07-08:00

How then will this TOP LEVEL NETWORK work? No doubt Cloud Computing is a threat to Desktop Operating Systems and it is most likely the future of computing. I strongly believe that if anyone would benefit from this new computing paradigm, it would be developing countries that cannot afford the infrastructure. To me, the "Cloud" paradigm is to computing as Satellite is to connectivity in developing countries. Cloud Computing gives developing countries access to applications for which they don't have the infrastructure to run. Satellite gives developing country connectivity in the absence of a physical infrastructure. But again, how will this TLN work?

Link | Posted on Mar 16, 2010 6:00 AM PDT by Darren Wilkins

RE: A Little Flexibility from ICANN and We Might Just Get IDNs... for Everyone (Andrew Mack)

2010-03-15T13:38:07-08:00

I appreciate the responses of Tina and Richard.

To Tina, I know a great deal of work has gone into the creation of new gTLD policy, and the entire community appreciates these efforts. That said, the fact that a script can become part of the process doesn't mean that it WILL. We all know it costs money to build out in different scripts, and simply put, unless we find a way to "bundle" smaller scripts with larger ones, I can't see how Thai or Khmer or any one of the smaller scripts will actually move forward in a way significant enough to really empower these language communities on the web. Some sort of "piggybacking" or package deals (effectively enabling one provider to do a whole series of IDNs) would strike me as the best option, since it is not a subsidy per se, but rather a way of incentivizing providers that are already going to make money in the IDN space, hence a win-win for the community.

To Richard's point, from what I understand the $185k number is calculated as an average. Hence the idea that you would charge everyone the same price for what are essentially very different goods doesn't really make sense to me. The value to a potential provider of a gTLD in Amharic can't possibly be what it might be in Chinese. So if this is an average, why not make the less desirable property cheaper? After all, real estate where I grew up in Cincinnati is cheaper than it is in San Francisco. And if the issue is cost recovery, let's draw that circle as narrowly as we can, not trying to "cost recover" sunk costs from the past as seems to be part of the $185 number.

In the end, we as a community have consistently expressed our interest in having a playing field that is open to all. If this means we have to show some creativity and flexibility in pricing, it would seem a worthwhile price to pay.

Link | Posted on Mar 15, 2010 1:38 PM PDT by Andrew Mack

RE: LTE and Spectrum Stupidity (Brough Turner)

2010-03-15T08:54:06-08:00

Alexander, Thanks for the comments.

I will concede that I used the "stupid" word to attract attention. :) On the other hand, I do believe that, had the 3GSM/LTE community had more understanding of data issues, they would have put more focus on TDD. (Note that the LTE definition includes both FDD and TDD; vendors have just chosen to focus on FDD).

Two comments: First, on synchronization. Useful LTE deployments should have 100+ Mbps backhaul per cell site today and certainly will have such backhaul links when LTE is widely deployed, say 5 years from now. With 100+ Mbps links, what is the problem about jointly optimizing TDD frame structures across adjacent cells? Whether you do this at LTE's 10 ms frame rate or the 1 ms sub-frame rate, it's certainly practical. Also, you don't require joint optimization across a huge pool of cell sites. You require local optimization between adjacent cells for just a percentage of the traffic that represents those mobile devices near cell boundaries.

Second, it is the case that instantaneous data is highly asymmetric. See my article here: http://su.pr/1Vmge3 . The problem is most people measure traffic averages over long periods of time (hours or, for Internet Transit services, over five minute intervals). This is OK once you've aggregated hundreds of people (to smooth out individual statistics) but it doesn't work at the sub-second intervals at which we schedule radio air time among the relatively small number of active users in a specific sector of a specific cell site. Unfortunately, sub-second traffic statistics are only understood by a limited group of experts, for example those designing router queuing mechanisms.

The LTE standards bodies did specify both FDD and TDD. Unfortunately as governments look for more spectrum and operators consider how to reuse what they already have, everyone is sticking to the FDD assumptions - assumptions that poorly match the actual instantaneous data demand.

Link | Posted on Mar 15, 2010 8:54 AM PDT by Brough Turner

RE: LTE and Spectrum Stupidity (Alexander Schertz)

2010-03-15T08:29:37-08:00

Dear Mr. Turner,

I think it is not so evident that it’s a stupidity to apply FDD instead of TDD. There are several arguments in favor of FDD (points 1-3 according to the book BEYOND 3G, Martin Sauter, Wiley, 2009, page 77):
1. TDD requires base stations to be tightly synchronized with each other to prevent uplink transmissions of devices in one cell to interfere with downlink transmissions of neighboring cells. This is not the case for FDD.
2. For FDD no transmission pause is necessary to give devices the necessary time to switch from transmission to reception mode.
3. FDD transmission allows more sensitive receivers in mobile devices because there are less disturbances for DL reception by UL transmissions by the receivers, which benefits overall data rates.
4. If spectrum is shared between mobile radio and broadcasting (which is the case in my country, Germany), TDD requires a broader safety margin between the parts of the spectrum allocated to those applications (in Germany: 7 MHz for TDD, 1 MHZ for FDD).
We should also take into consideration that the asymmetry between UL and DL bandwith requirements is smaller than the asymmetry between the data requirements because UL transmissions are usually less efficient than DL transmissions due to the limited power and antenna restrictions of the small devices.
The crucial question is if the asymmetry between UL and DL data requirements is so strong that the advantage of TDD (that the system can be tuned to reflect the ration between UL and DL traffic) is not compensated by the disadvantages mentioned above. In order to give a solid answer to this question we need more empirical data.

Best regards,

Alexander Schertz

Link | Posted on Mar 15, 2010 8:29 AM PDT by Alexander Schertz

RE: ICANN's Board Decisions in Nairobi Will Determine Its Credibility and Respect for Years to Come (Richard J Tindal)

2010-03-14T08:44:56-08:00

Khaled,

I'm in favor of IDN gTLDs going forward. The only thing holding them back is ICANN's Affirmation of Commitments with the US Government. It effectively says ICANN can't implement new TLDs (IDN or ASCII) until the overarching issues are adequately addressed.

I believe the root zone scaling issue is adequately addressed and the trademark and malicious activity issues are very close to being adequately addressed. The only overarching issue remaining is the cost/ benefit study. That will be progressively addressed between March and July this year by the reports from Professors Rosston and Katz.

You said the process is still littered with unresolved overarching issues. Which do you think are unresolved and why do you think that?

Best

Richard

Link | Posted on Mar 14, 2010 8:44 AM PDT by Richard J Tindal

RE: Sender Address Verification: Still a Bad Idea (John Levine)

2010-03-14T07:12:21-08:00

To abuse a famous quote, this must be a meaning of "simple tweak" with which I am not familiar.

Link | Posted on Mar 14, 2010 7:12 AM PDT by John Levine

RE: Sender Address Verification: Still a Bad Idea (Ale)

2010-03-14T05:58:44-08:00

COI forms are not standardized and can be abused in a number of ways.

A simple tweak: users should tell or confirm to their servers the list they want to subscribe to. The servers connect to each other, exchange info, and end up with two specular COI data sets: a forwarding recipe at the list server, and a forwarding agreement at the user's server.

Link | Posted on Mar 14, 2010 5:58 AM PDT by Ale

RE: Sender Address Verification: Still a Bad Idea (Daniel Kamers)

2010-03-13T10:31:30-08:00

Yes, apply to BATV too.
By the way, SPF would work if used.
A "~all" (instead off -all) that stays there FOR YEARS should be blacklisted! Its intended to be TEMPORARY (changing), but its used by some of the bulk mailers that agree with you, forever.
I am not seller nor blabher, just a user. I like BATV, domain keys, SPF, or SAV, as long as any of it just works or _at least help_.
What I really dont understand and really dont like is: have to pay (!) for beeing out of "backscatter.org", just because you are saying things like these on your note, and many users just "believe" it (because "are not able to understand"). Almost imoral.

Link | Posted on Mar 13, 2010 10:31 AM PDT by Daniel Kamers