Hi, I thought I was in this group, but somehow, I wasn't. I am now, so just catching up.
any subsequent round should be more predictable, timely and accountable.
This is certainly a good hope. The first principle of the round we are in was predictability. We see how ell that went. That is the first of many principles I think this round missed on. Accountability at ICANN is a permanent quest. And timely should come with time, and experience. And a few more guidelines. Also now that the garden has been seeded with a thousand possible blooms, it is time to work on specific areas of the garden that may need further development and care. Focusing more on type, might help in terms of timeliness. I question the degree to which we need future rounds like this one for undifferentiated standard applications. It may be time to consider putting those on a rolling first come first served model. Given the skills people developed for digital archery, perhaps these are mini rounds that last a day, sort of like the groupings that were done in this round. I am sure a lots of details would need to be worked out. Especially if there are separate tracks for different sorts of application. If we do any rounds, a problem we need to fix is the ability for those who do compete for names to actually negotiate to change their string. This was something that I believe was in the intent of the GNSO recommendations but that the staff vetoed in its implementation, indicating it would be too hard. In the GNSO PDP we had many discussions about 3 applications for bear, where in the end one went for something like .grizzly, one went for .ursus and one went for .teddy. We would also need to allow another thing I think many of us argued for, but which was rejected by staff such as appeals on name contention and on the determination of confusion. I think that the experience in the current round showed us that this is an area where substantial rework of the processes is required. As I said, I do not really see call for another major round like this round, but rather micro rounds that approach a first come first serve model. I do however, see call for two remedial rounds: 1. I believe we need a remedial for applicants from developing economies. We not only need to make these minimal to no cost, but we need to make sure that outreach is significant and then that aid and other ongoing assistance is available for enabling these to become viable registries. I see this as part of ICANN's commitment to globalization. I believe there is strong support for this in ALAC and GAC. This might also include considerations such as assisting with the creation of regional RSPs in development areas. As the monies from auctions have not yet been allocated, this is one use for those funds. The work JAS did might be helpful, but that is only a step in the direction of the remediation that is required. This is a program that could start planning even before the current round ends given its degree of specialization and its long outreach and education lead time. As I understood it, there had been a very extensive proposal for global outreach before he last round started, but it was cancelled for reason only the staff know. Perhaps it can be dug out of mothballs and reused as part of a remedial plan for developing economies. 2. I believe that we need a round for communities only. We need to remediate the mess made out of community applications in this round. The GNSO created a program that was supposed to nurture and protect community applications. Instead we build a system that attacked them as frauds and put them through an extra special punitive ordeal. This needs to be remediated. Such a round could be similar to the Supported gTLD round which occurred before the current round. I also think that now that we know what the categories of gTLD are, we may want to fine tune the processes so that special variants in the process apply to these categories. Two sizes fit all was a workable model before we understood the variations between types of gTLD. Now we have enough information to be able to create some special considerations and perhaps even some specialized streams of application. The one thing I think we must avoid doing is running the same processes we are currently muddling through. This time, we need to specify the requirements of the program in much greater detail to make sure that the right thing is done in implementation. And whatever we do, we need to take advantage of the Implementation Team approach that is included in the current PDP model so that this runaway mess is less likely to occur again. avri