[council] FW: [soac-discussion] FW: Communication with ACSO on the next RTs

Gomes, Chuck cgomes at verisign.com
Fri Jun 11 15:20:43 UTC 2010


I sent this message to Janis regarding the composition of the AoC RTs.

 

Chuck

 

From: Gomes, Chuck 
Sent: Friday, June 11, 2010 11:00 AM
To: Janis Karklins; soac-discussion at icann.org
Cc: 'Rod Beckstrom'; 'Donna Austin'; 'Olof Nordling'
Subject: RE: [soac-discussion] FW: Communication with ACSO on the next
RTs

 

Janis,

 

After fairly extensive discussion on the GNSO Council list and
additional discussion in our Council meeting yesterday, the GNSO feels
very strongly that it is important to have four representatives on each
of the RTs.  I have included a sampling of some of the comments and
rationale provided by various Councilors below.  Note that most of these
comments were reinforced by multiple Councilors and that there was
overall agreement in the Council meeting for the position.

 

Chuck

 

General Comments

*        I'm not sure that an additional 2 GNSO reps will be detrimental
to efficiency, and I should think it would actually add to the
credibility of the process - which leaves "budgetary limitations" as the
remaining (relatively unconvincing) reason.

*        It seems to me that the ramifications of the selectors
rejecting GNSO input as to participant number are potentially
significant.  In particular, the irony of doing so while the
accountability and transparency review is underway is pretty amazing.  I
think that would play pretty well (against ICANN, that is) in a number
of important fora.

*        It'd be a lot easier if they'd just default to four across the
board in order to ensure community representation and diverse skill sets
at the table, rather than turning RT size into a needless source of
angst.

*        It is perfectly reasonable to allow one seat each to the SSAC,
GAC, and ASO. But I think it's totally implausible to assume a well
represented RT with only two for the GNSO and one each for the ccNSO and
the ALAC. I believe we make a very strong statement insisting that each
of those are doubled - four for the GNSO (one for each SG, no less), two
each for the ccNSO and the ALAC due to the size of their memberships.
That would make the RT 14 members, and that is certainly workable and
more realistic.

 

SSR RT

*        All three (SSR) are already huge issues and will directly
affect all the rollout and use of TLD's, IDN_TLDs, and ccTLDs and some
of the issues that could be coming would include:

-          Punycode storage of IDN names - Neither any human nor most
existing security mechanisms (anti-virus, firewalls, etc) can read it
directly.  It is the main reason you need "standard script" usage.

-          DNSSec - Can it and should it be pushed to all TLDs?  (After
a demo of DNS hacks a couple weeks back, I'm not sure I will ever trust
a wireless hotspot fully again.)

-          DNSSec - Credentials - Key distribution chains and processes,
rollover mechanisms, and  there will likely be some of revocation
process needed for bad behavior.

-          DNSSec - Operational issues yet to be determined too.  DNSSec
generates a 30x increase in response traffic for instance plus signature
processing overhead.

-          Network management systems likewise will likely have initial
issues with IDNs too.

-          Increased discussions of "network cyber identity
requirements" and how these might work in an IDN environment.

-          Routing reliability as IPv6 vastly increases the route table
sizes

-          IPv6 reachability and initial usage rollouts.  (Outside of
Microsoft, I could not say that anyone on the globe has a large scale
IPv6 infrastructure working yet.)

-          New "whois" issues that could be created by fact that more,
maybe most, IPv6 addresses will be indirectly assigned through an ISP to
the end user or organization rather than directly assigned via IANA and
the RIRs.

*        From an operational point of view, with implementation of TLDs,
ccTLDs, IDN_TLDs,  DNSSec, and IPv6 plus the issues with route stability
and huge growth in cybercrime; one could reasonably expect that many
unseen/unknown operational issues will affect GNSO plans and policies.
(and certainly keep the SSR busy!) 

*        The economies and critical infrastructure (communications,
power, financial, etc) of at least 50 nations around the globe are
completely tied to the security, stability, and reliability of the
Internet so SSR issues are considered very carefully by most
governments.

*        The Commercial SG provides combined expertise in technical,
operational and legal respect of security aspects of the DNS system.

 

Whois RT

*        Whereas Internet users across the whole ICANN community are
impacted by Whois policy, I don't think there is any doubt that GNSO
constituents are impacted the most.  It is gTLD registrants whose data
is displayed and used.  It is gTLD contracted parties who are required
to implement Whois and who best understand the customer service and
operational issues related to Whois offerings.  It is commercial gTLD
registrants whose businesses are affected when IP rights are violated.
It is noncommercial users who have most often pointed out the need for
privacy of Whois information and noncommercial organizations that are
impacted in similar ways as commercial businesses.

*        In addition, because of the GNSO's long and belabored Whois
policy development history and varied Whois operational offerings, the
GNSO has the best source of Whois experts from various points of view.
There is also good evidence that each SG provides a unique area of
expertise and represents different points of view with regard to Whois
policy.

*        Whois is one of the few areas where people who are generally
like-minded can have VERY different positions.

*        There really has to be four for WHOIS, the perspectives of the
SGs are just too variable for any two to represent the others, and the
whole process could become a focal point of controversy.

*        I strongly oppose accepting only two seats on the Whois.

 

New gTLDs RT

*        Similar arguments could be made for this future RT.

 

From: owner-soac-discussion at icann.org
[mailto:owner-soac-discussion at icann.org] On Behalf Of Janis Karklins
Sent: Friday, June 04, 2010 1:50 PM
To: soac-discussion at icann.org
Cc: 'Rod Beckstrom'; 'Donna Austin'; 'Olof Nordling'
Subject: [soac-discussion] FW: Communication with ACSO on the next RTs

 

Dear colleagues

 

On behalf of Selectors I would like to propose that the size and
composition of the two next review teams would be as follows:

 

                                                    Security
WHOIS
GAC, including the Chair           2                              1
GNSO                                                2
2
ccNSO                                               2
1
ALAC                                                 2
1
SSAC                                                  1
1
RSSAC                                               1
ASO                                                    1
1
Independent expert                 1-2                          2 (law
enforcement/privacy experts)
CEO                                                     1
1
                                                          13-14
10

I understand that your initial suggestions/requests were not fully
accommodated, but for the sake of efficiency, credibility of the
process, budgetary limitations Selectors have developed this proposal.
If we would take into account all wishes, the RT size would be over 20
which in Selectors' view is not credible option.

 

I hope that proposal will be equally unacceptable for everybody. I would
appreciate your comments or expression of non-objection in coming week.
Only after assessment of the violence of your opposition the Selectors
will make their proposal (in present form or modified) public.

 

Best regards

JK 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20100611/d852f712/attachment.html>


More information about the council mailing list