RE: [gnso-arr-dt] RT Permanent Endorsement Process

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

Please see my responses below.

 

Chuck

 

From: owner-gnso-arr-dt@xxxxxxxxx [mailto:owner-gnso-arr-dt@xxxxxxxxx]
On Behalf Of Caroline Greer
Sent: Thursday, May 13, 2010 10:55 AM
To: William Drake; gnso-arr-dt@xxxxxxxxx
Subject: RE: [gnso-arr-dt] RT Permanent Endorsement Process

 

Thanks Bill and welcome back.

 

While I think Tim's model works fine, equally I would not be opposed to
abandoning one of the two previous 'open' slots but maintaining the
other.  So, we could have 4 SG slots and one open slot for anyone that
did not find themselves affiliated with a particular SG. In which case,
the evaluation team would still have a role, albeit minor. [Gomes,
Chuck]  I can go either way on this (4 or 5 slots) but if we recommend
up to 5, then I think it should be fully open (affiliated or
unaffiliated).

 

On some of the other issues that you raise Bill, I would leave open the
possibility that a SG could choose not to nominate a representative or
that one candidate could be endorsed by more than one SG. It is not
likely to happen in my opinion but why preclude the possibility.[Gomes,
Chuck]  Agree

 

I also think no harm in stating the diversity aspirations, if only to
encourage applications from certain under-represented groups.[Gomes,
Chuck]  Strongly agree.

 

I agree that self-identification ought to be a requirement, am fine with
dropping the time commitment piece but think we ought to specify some
sort of technical expertise / knowledge / background for the Security &
Stability Group. A similar request could well be made for the remaining
RTs but I think that it particularly important for this RT.

 

Thanks,

 

Caroline.

 

 

 

From: owner-gnso-arr-dt@xxxxxxxxx [mailto:owner-gnso-arr-dt@xxxxxxxxx]
On Behalf Of William Drake
Sent: 13 May 2010 14:51
To: gnso-arr-dt@xxxxxxxxx
Subject: [gnso-arr-dt] RT Permanent Endorsement Process

 

Hello,

 

I am back on the grid after an unavoidable absence, or at least am
crawling in that direction.  I've read very little mail in May and am
way behind, please correct any misunderstandings.

 

It appears we put the permanent process aside for the moment to focus on
the SSR and WHOIS per Janis.  So presumably we are shooting for the 10
June Council meeting, and need a motion by the 3rd, three weeks from
today.  

 

Endorsement Process

 

On 30 April Tim proposed a simplified procedure in which each SG
endorses one candidate and any diversity concerns are then addressed at
the Council level, with the addition of x people being possible via a
majority vote of both houses.  Two people replied favorably, nobody
opposed.  Some questions about going down this path:

 

1.  Can a SG decide not to endorse any candidate?  Can more than one SG
endorse the same person, e.g. someone not from one's own SG?  Both seem
reasonable, although I suppose we'd have to tweak the request that the
Selectors allocate x slots to GNSO per RT.

 

2.  Are people now inclined to abandon the concept of having an
Council-wide elected slot for people who consider themselves to be in
the GNSO community but not affiliated with/seeking the endorsement of
any particular SG?  It obviously would simplify things, but previously
there were concerns about this being exclusionary and having a slightly
cartel-like optic.  We did after all have people apply as unaffiliated
in the first round...

 

3.  Re: diversity, in this model we'd only consider adding people to
move toward the objectives , rather than e.g. going back to SGs and
asking them to reconsider their first choice.  

 

a.  Would we still state the diversity objectives?  Our existing
language says that unless the applicant pool does not allow, no more
than two nominees should come from the same geographical region,
nominees must not all be of the same gender, and the distribution
between genders should be no greater than two-thirds to one-third.
Personally, I still think it is desirable to publicly state an
aspiration and try to hold ourselves to it IF the pool submitted to
ICANN allows.  Especially if we drop down to just up to four SG endorsed
nominees in the first instance, I would hope we could aspire at least to
one woman and two non-US.

 

b.  I presume Council would only be able to pick from the pool of people
who applied to ICANN?  How many?  Worst case scenario, SGs nominate 4
white guys from the US, could we propose up to two for balance?  (which
hopefully the Selectors would give equal consideration)

 

c.  In this model, would we abandon the Evaluation Team?  If we don't
have elected slots 5 and 6 and diversity is being at the Council level
via possible additions rather than any negotiation etc, it's not obvious
we'd need this mechanism.

 

 

Additional GNSO Requirements.

 

If I recall correctly nobody thought these needed any amendment.
However, 

 

1.  In the first round we included in the in-house Action Plan (below)
the statement that "volunteers are encouraged to self- identify with any
GSNO SG / Constituency with which they feel most closely affiliated."  I
suggest we move this encourgement to the Requirements, where it should
have been.

 

2.  In light of the ICANN CFP wording should we delete the "attestation
that the applicant is able and willing to commit at least ten hours per
week during the review period"? 

 

3.  It has been suggested that for the SSR RT some indicator of
security/tech expertise would be useful.  One could argue that
specialized expertise would be useful for the competition and WHOIS RTs
as well.  Do we feel the need to add a sentence that caters to these
situations or should we just assume people will be reasonable and
self-select?

 

 

Action Plan

 

Our initial effort included a set of in-house procedures.  Depending on
what we decide about the process, will we still need to have such a
document?  For example, the existing one dealt with how to handle
unaffiliated or unclearly affiliated people.  In Tim's model, this isn't
needed as there's no elected unaffiliated slot and the SGs just endorse
whomever they like from the pool (irrespective of whether or how they've
self-identified).  We could lose the elaborate language on time lines
etc that resulted from ICANN's shifting parameters on the maiden voyage,
and the still relevant bits could probably be collapsed down to a simple
sentence or so in the publicly available Endorsement Process, e.g.
stating that by x days after ICANN's deadline for submissions the
Council will forward its nominations to the Selectors.

 

 

It would be really helpful to hear from all members of the DT on these
and any related points.  I see that the 20 May Council agenda has 25
minutes allocated to this topic and that I'm supposed to convey the DT's
recs, so any movement toward closure by then would be great.

 

Thanks,

 

Bill