<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">Olivier is exactly right</div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px"><span style="color:rgb(11,83,148);font-family:tahoma,sans-serif">Allegations of subversion of process are </span><b style="color:rgb(11,83,148);font-family:tahoma,sans-serif">absolute bullshit</b><span style="color:rgb(11,83,148);font-family:tahoma,sans-serif">. The process is working </span><u style="color:rgb(11,83,148);font-family:tahoma,sans-serif">exactly</u><span style="color:rgb(11,83,148);font-family:tahoma,sans-serif"> as <div class="gmail_default" style="display:inline">ICANN's</div> bylaws demand;</span><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px"><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><span style="font-size:12.8px"><br></span></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><span style="font-size:12.8px">- The GNSO has created policy in the interest of domain buyers and sellers.</span><br><span style="font-size:12.8px"><br></span></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><span style="font-size:12.8px">- Meanwhile, the GAC is doing just what the bylaws tell it to do ... advise ICANN. It has no defined decision-making role in the policy development process, and its advice -- like that of any AC -- may be ignored, usually without consequence.</span><br><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">But not this time.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">What has got the GNSO in its current whinging fit is the "or else" threatened if ICANN blows off the GAC advice on IGOs ... in the way it has customarily blown off previous AC advice that counters the GNSO's will.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">To this, my reaction is less "how could this happen" but rather "this was inevitable, I'm amazed it didn't happen sooner".</div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">Welcome, finally, to the consequences of ICANN's deliberate separation of stakeholders into different classes; those who must be heeded (the GNSO) and those who only give advice and may be casually blown off (the ACs). ICANN must now deal with this unequal, unfair structure of its own design. </div></div></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">I welcome the discussion Olivier calls for, that recognizes and elevates the interests of those who neither buy nor sell domains, yet are profoundly impacted by ICANN policy.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><br></div><div class="gmail_default"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px"><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">Until then .... the onus, should it wish to avoid a conflict, is on the GNSO to accommodate the AC, not vice versa. </div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">Preferably there is a negotiated middle ground -- in a meeting of equals, not an invitation as a guest to an already-slanted working group. I have seen my share of GNSO WGs where the invited advisory council reps were factored out of the final consensus because the output was, after all, subject to GNSO ratification and nobody else's. Indeed, I was part of a 2012 working group that considered IOC and ICRC requests and, eventually, blew them off. So they DID try the bottom-up process and it failed because the GNSO overpowered the complainants. What we see now is the payback for that.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)"><br></div></div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px">I've also been happy to see that CCWGs are working well. Maybe that is the answer. "We invited them to our process that only we need to ratify" is likely insufficient inclusion. Perhaps the discussions Olivier asks for will result in CCWGs being the default bylaw-mandated structure for PDPs.</div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px"><br></div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px">But enough about process....</div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px"><br></div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px">Lest we get distracted by process as ICANN does so often and so well, let's also remember the substance of the issue. Multiple people on this thread have complained "why should we afford protection to the XXX if we don't give it to someone else deserving?" or "why should ICANN give protection to XXX that it doesn't get elsewhere?"</div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px"><br></div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px">Such arguments are so commonplace<span style="font-size:12.8px"> within ICANN that I consider them to be corporate culture, the standard retort to anything that suggests change to the status quo. Their logic can be compressed into:</span></div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px"><br></div><blockquote style="color:rgb(11,83,148);font-family:tahoma,sans-serif;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><i>If you can't fix everything, don't fix anything.</i></blockquote><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px"><br></div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px">I reject that argument, deliberately advanced to stifle improvement and innovation while enabling past errors to remain errors in perpetuity.</div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px"><br></div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px">The issue in front of us -- should ALAC advise on the matter -- is not about the value of MSF or trademark protections of IGOs. We are constrained to deal with protection of IGO strings within gTLDs. Inside that narrow regard there is a public interest in which, IMO, we should engage.</div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px"><br></div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px">At very least, I cannot understand why anyone considering the public interest would oppose reserving ICRC strings; that body that is explicitly mentioned in the most fundamental of international humanitarian treaties. Its names and symbols are most certainly abused regularly. </div><div class="gmail_default" style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px"><br></div><div class="gmail_default"><font color="#0b5394" face="tahoma, sans-serif"><span style="font-size:12.8px">In the case of Alan's favourite example.... the International Organization for Standardization has members from 163 countries, that produces information critical for interoperability in thousands of fields. Its protection is not quite as critical as the ICRC (and UNICEF, UNHCR, etc) because it does not solicit public funds. </span></font><span style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px">However the public information it produces is not just useful but required to be complete and accurate by both the private and public sectors. So on the balance I would support its protection. As a matter of general criteria I would want to protect any IGO that either solicits public funds or has a significant public-information role.</span></div><div class="gmail_default"><font color="#0b5394" face="tahoma, sans-serif"><span style="font-size:12.8px"><br></span></font></div><div class="gmail_default"><span style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px">If ICANN wishes an internal body to identify criteria for organizations whose strings are in need of public-interest protection, At-Large is actually the appropriate place to advise on that. </span><font color="#0b5394" face="tahoma, sans-serif"><span style="font-size:12.8px">But if brinkmanship between the GAC and GNSO demands a binary answer from ALAC, the massive public benefit of protecting the ICRC and other fundraising IGOs overrides the domain industry's entitlement to commoditize IGO strings. </span></font><span style="color:rgb(11,83,148);font-family:tahoma,sans-serif;font-size:12.8px">The more obscure IGOs don't require protection, but reserving their strings is harmless from a public-interest point of view should we be faced with an all-or-nothing choice.</span></div><div class="gmail_default"><br></div></div><div class="gmail_extra"><div class="gmail_default" style="font-family:tahoma,sans-serif;color:rgb(11,83,148)">- Evan</div>
</div></div>