[IOTF] Question on PTI implementation approach

Wed Jun 1 09:43:21 UTC 2016

All,

Alissa’s points make good sense to me.

Jonathan

From: Alissa Cooper [mailto:alissa at cooperw.in] 
Sent: 31 May 2016 17:58
To: Alan Greenberg <alan.greenberg at mcgill.ca>
Cc: Alissa Cooper via Iotf <iotf at icann.org>
Subject: Re: [IOTF] Question on PTI implementation approach

On May 29, 2016, at 5:49 PM, Alan Greenberg <alan.greenberg at mcgill.ca <mailto:alan.greenberg at mcgill.ca> > wrote:

I am obviously missing something here.

In that case of "separation" ICANN would still be the steward of the IANA names functions. It would be the entity contracting with the successor of PTI. So it could well make arrangements for the employees to continue with the successor organization. Or not if the employees were in fact part of the problem.

Exactly. If the employees are part of the problem and the performance of the functions has gotten so bad that the community wants to use the separation process, that process should not be hamstrung by the fact that ICANN committed to offering the employees the option of being employed by the successor. 

Regardless of the details, as the steward of the names function, is not likely to be inclined to take action to sabotage things.

I wasn’t referencing the sabotage of anything. I think what needs to be clear is that, as Avri says, the employees always have their choice of employ. ICANN’s role is to make sure the choices within ICANN’s control are available to those employees, but not to control what other choices they may have with successors whose hiring decisions are not within ICANN’s purview.

Alissa

Alan

At 29/05/2016 07:48 PM, Greg Shatan wrote:

I think it does mean that ICANN will allow its seconded employees to leave the employ of ICANN and go to PTI or to a successor (if that's the way the separation is occurring).  I can't see any other interpretation.  As Chuck points out, it also seems to assure these ICANN employees that, if they do not want to join PTI/successor or are not offered a job there, that they will have the option of continuing as ICANN employees.

The secondment scenario does create some concern that ICANN could encourage these employees to stay with ICANN in the event of a separation (or to put it another way, discourage these employees from moving from secondee to employee within the IANA provider (PTI or successor)).  This could have negative security and stability impacts.  We may want an assurance from ICANN that it will not solicit or otherwise encourage the seconded employees to remain ICANN employees rather than continue to be part of the IANA provider.  I could see some awkward moments otherwise.

Greg 

On Sat, May 28, 2016 at 10:44 AM, Gomes, Chuck <cgomes at verisign.com <mailto:cgomes at verisign.com> > wrote:

Good questions Alissa.

It seems to me that with or without the sentence you quote, the affected employees would have the three options assuming that the applicable organizations gave them the employment option.  Like you say, ICANN may not have any control over what the successor might do, but it is at least committing to offer employment to the seconded employees if they want it so this clause may be of some assurance to those employees.

Chuck

-----Original Message-----

From: iotf-bounces at icann.org <mailto:iotf-bounces at icann.org>  [ mailto:iotf-bounces at icann.org <mailto:iotf-bounces at icann.org> ] On Behalf Of Alissa Cooper

Sent: Saturday, May 28, 2016 2:12 AM

To: Alissa Cooper via Iotf

Subject: [IOTF] Question on PTI implementation approach

Hi all,

Apologies that I have not been able to make the last few calls.

I was reviewing the PTI implementation approach document and I noticed that Section 2.3 says:

"In the event of separation, ICANN commits to an effectuating an orderly transition, including providing the seconded employees the option of employment with the affiliate, the successor, or ICANN. This commitment will be reflected in the naming function contract between ICANN and PTI.â€

What does it mean for ICANN to provide the option of employment with the successor? I assume by "successor" what is meant is the new operator to replace PTI, for one or more IANA functions. In that case, ICANN wouldn't likely have the option of offering employment by the successor -- the successor would be a separate organization altogether, which is the point of separation. Does this mean ICANN won't prevent PTI employees from being employed by the successor (e.g., it wonâ€™t impose some sort of non-compete agreement)? If that is not what it means, what does it mean?

Also, given that the second sentence says that this commitment will be reflected specifically in the naming function contract, does that mean it will not also apply to the seconded employees performing the other two functions (to the extent that employees are assigned wholly to either or both of the other two functions)?

I read through the transcript for call #10 but did not see these questions raised on the call.

Thanks,

Alissa

_______________________________________________

IOTF mailing list

IOTF at icann.org

https://mm.icann.org/mailman/listinfo/iotf

_______________________________________________

IOTF mailing list

IOTF at icann.org <mailto:IOTF at icann.org> 

https://mm.icann.org/mailman/listinfo/iotf

Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Microsoft-Exchange-Diagnostics:
         1;SN1PR0301MB2030;9:0+ZiF373MgecgwhfjdnXDj9HBCxQlxBfcYlS6xEgVnnZsuI8gFRsXN/m+rAP6oPjL+vN+5XlPhm/+EVYFquY8LJBrCmI4P+SUs/O8moMS3LX/znyb34B3xoIJbiSSwuTdOrLmtt24VsigyO6F5MHw0/nQ6D5Za/ieTviw6oJQbAmSIAzS38lY4IxJeAnFWMw

_______________________________________________
IOTF mailing list
IOTF at icann.org <mailto:IOTF at icann.org> 
https://mm.icann.org/mailman/listinfo/iotf

_______________________________________________
IOTF mailing list
IOTF at icann.org <mailto:IOTF at icann.org> 
https://mm.icann.org/mailman/listinfo/iotf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/iotf/attachments/20160601/c4827d24/attachment-0001.html>