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

Rosette, Kristina krosette at cov.com
Fri Jun 11 15:33:35 UTC 2010


Thank you, Chuck. Well done.


________________________________

	From: owner-council at gnso.icann.org
[mailto:owner-council at gnso.icann.org] On Behalf Of Gomes, Chuck
	Sent: Friday, June 11, 2010 11:21 AM
	To: council at gnso.icann.org
	Subject: [council] FW: [soac-discussion] FW: Communication with
ACSO on the next RTs
	
	

	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/f08110ef/attachment.html>


More information about the council mailing list