ICANN ICANN Email List Archives

[gnso-igo-ingo]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-igo-ingo] IGO-INGO Draft Final Report

  • To: Berry Cobb <mail@xxxxxxxxxxxxx>, "gnso-igo-ingo@xxxxxxxxx" <gnso-igo-ingo@xxxxxxxxx>
  • Subject: RE: [gnso-igo-ingo] IGO-INGO Draft Final Report
  • From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Date: Fri, 20 Sep 2013 03:39:03 +0000

Thanks Berry.

In the sentence you added at the end of the next to last paragraph before 
Section 4.1.2 on page 16 of the clean version, I think the following minor 
edits are needed: "One view discussed what whether such harm needed to be first 
proved prior to granting any protections or whether it was sufficient to only 
presume harm.  Conversely, views were expressed that whether the harms exists 
is not relevant, but when harm is detected, resources that would otherwise be 
earmarked for an organization's public interest mission are otherwise diverted 
to deal with such harm."  BTW, I like the way you did this; it now makes sense 
and reflects WG efforts in this regard.

The last sentence of the next to last bullet on page 18 of the clean version 
says: "Additionally, existing registry agreements have an exception procedure 
for 2-character second-level names, which also utilizes the RSEP."  I didn't 
have time to look this up so you may be right but I didn't think that the 
2-character exception process used the RSEP.  If it does, fine; if not, we 
should delete the addition in yellow.

Assuming the levels of support reflect the latest input and Thomas's 
assessment, everything else looks fine to me.

Chuck

From: owner-gnso-igo-ingo@xxxxxxxxx [mailto:owner-gnso-igo-ingo@xxxxxxxxx] On 
Behalf Of Berry Cobb
Sent: Thursday, September 19, 2013 7:47 PM
To: gnso-igo-ingo@xxxxxxxxx
Subject: [gnso-igo-ingo] IGO-INGO Draft Final Report
Importance: High

WG Members,

Please find attached two versions of the IGO-INGO draft Final Report.  Version 
0.6 includes all track changes from the Initial Report, while version 0.7 is a 
clean version of the report where all track changes are accepted.  I made an 
attempt to reorder the sections of this report to promote the recommendations 
section to section #3.  However, the nested numbering lists were not adjusting 
as expected and my manual intervention could not easily fix the issue.  I will 
attempt to find the root cause, but I did not want to delay the report any 
longer.

A note from our Chair..........



All,

first of all, thanks to Berry for stepping in yesterday and chairing the 
meeting. Well done!



I apologize for not having been able to participate during yesterday's meeting 
at such a crucial point in time, but I was on a business trip that could not be 
scheduled for another day.



There has been a debate also on the recent publication of the list of strings 
that are published into Specification 5 per the series of NGPC resolutions. I 
will chime in on that subject later, but let's focus on the finalization of the 
report now.



Thanks to all of you for contributing to our joint aim of getting the report 
ready for public comment. A special kudos to Chuck is in order for reviewing 
the report so diligently and thereby improving its quality tremendously.



I would like to comment on a few items that have been subject of the recent 
deliberations:



Assessment of Consensus level:

Thanks also to all that have spoken out or written e-mails expressing their 
confidence in my assessment of the consensus level. The consensus level will 
remain as it is in the present version of the report, unless we get more input 
prior to the publication of the report for public comment that would require 
changes to the consensus level.



Format of the Recommendations:

There have been requests to place some of the recommendations that did not 
reach consensus level in context with the other recommendations for the 
respective organization that reached consensus. I have extensively conferred 
with Berry today regarding the way the recommendations are presented and now 
asked Berry to accommodate that wish. The group has discussed all 
recommendations separately. There was the explicit request from many WG members 
to do that. The reason why we have displayed the recommendations in the 
previous versions of the report was because there was hope that we could 
present all recommendations that have reached consensus first and then those 
that did not reach consensus and that the GNSO Council could then look at them 
and decide on them as a package.  However, this approach has changed since the 
level of consensus for the various recommendations vary quite a bit. I have 
reported to you in an earlier call that the GNSO-Council will most likely vote 
on the recommendations one by one. In the light of this, it does make sense for 
both for the Council as well as for the community to be presented with all the 
recommendations in a way that is easier to digest in terms of context. We did 
not change substance, just the order.



Consensus Scale:

There has been a discussion on whether the recommendations, or I should better 
say the consensus level for the individual recommendations, should be called 
differently and more differentiated to reflect more accurately i.e. the level 
of divergence. While I do appreciate the desire to be as accurate as possible 
when presenting the status of our thinking to the community, I think it is not 
appropriate for us to change the terminology and have hence asked Berry to 
stick to the original terminology. The reason for that is that you will 
remember I explained to the group quite thoroughly how consensus is determined. 
We went through the consensus levels in the WG Guidelines document and all of 
you have provided input to the consensus call in the light of these terms. Even 
more: Some may have chosen not to respond because they anticipated that their 
input would not help certain recommendation to get more than "consensus" or 
less than "divergence". I am therefore afraid that a last minute change to the 
consensus levels might let the process appear not having been reliable.  
Rather, we should stick to the definitions we have used before and those who 
think that it is necessary to express their views on the support level in 
greater detail should do so using the public comment forum. This will inform 
the community as well as the Council and ultimately the ICANN Board.



Having listened to the vivid discussion on this subject via the mp3, I do agree 
with those of you, who stated that the vocabulary of the consensus scale is not 
adequate to reflect the level of support or the lack thereof. However, I do 
believe that it would not be appropriate to try to fix this retrospectively. We 
have now included a footnote in the description of the consensus scale to share 
the concerns that were expressed with the reader of the report.

Apart from that, I will suggest this as a topic to be dealt with by the SCI as 
a change of the WG Guidelines might be needed.



Timing:

As all of you know, we are working against a tight time line and I appreciate 
that you have supported us in making it possible for the outcome of our work to 
be considered by the GNSO-Council before the Buenos Aires meeting. I trust that 
you have reserved some time these days to be able to react to the refinements 
of the report. We will proceed and aim at publishing the report tomorrow, the 
20th.

While I do hope that all of you are fine with the report in its current format, 
please note that there are more opportunities for us to make changes to the 
document (I guess Berry called it that we will get back to the "well"). So 
please avail yourself of such opportunities to come and allow us to get the 
report out for public comment, unless you have spotted substantial flaws.



Thanks,

Thomas




Berry Cobb
Internet Corporation for Assigned Names & Numbers (ICANN)
720.839.5735
mail@xxxxxxxxxxxxx<mailto:mail@xxxxxxxxxxxxx>
@berrycobb




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy