[CCWG-ACCT] Notes-Recordings-Transcript link for CCWG Accountability Meeting #92 - 27 April 2016

Wed Apr 27 15:20:22 UTC 2016

Hello all,

The notes, recordings and transcripts for CCWG Accountability Meeting #92 - 27 April 2016 will be available here:  https://community.icann.org/x/mCeAAw

A copy of the notes may be found below.

Thank you.

With kind regards,
Brenda Brewer
MSSI Projects & Operations Assistant
ICANN - Internet Corporation for Assigned Names and Numbers

Notes

These high-level notes are designed to help you navigate through content of the call and do not substitute in any way the transcript.

1.  Welcome, roll call, SOI (LS)
*        TRickert has updated his SOI.

2.  Timeline for CCWG Comment on Draft Bylaws

        - Apr 27th :  CCWG ACCT Meeting #92

        - May 3rd :  CCWG ACCT Meeting #93

        - May 10th :  Submission
*        No objections to proposed timeline.

3.  Introductory remarks from Holly and Rosemary

4.  Q&A (TR)
*        Email question on Human Rights from Niels has been responded to by Rosemary Fei and this will be included in the CCWG response to the public consultation on the draft Bylaws.
*        TTropina - Only lawyers can suggest clarifications?
*        HGregory - Anyone can propose clarifications but the CCWG needs to decide which to accept.
*        TR - no wordsmithing please.
*        GShatan - The difference between HG proposal and mine is that HG suggested language perpetuates the ambiguity. FOI approval is business as usual per CCWG procedures.
*        RFei - Ambiguity comes in in the parenthetical - the INCLUDING CO APPROVAL - this causes the confusion - this should simply be removed and approval is then according to standard process.
*        TR - there seems to be general support for RF proposal but participants would like to see the language.
*        LSachez - WHOIS review has been deferred several times - the Bylaws speak to the timing of reviews (5 years from start of previous one). Given the previous WHOIS review was in 2010 the approval of the new Bylaws would automatically put us in default. How would lawyers recommend we deal with this issue - possibly via a footnote?
*        RFei - The CCWG never intended to create a situation where when the Bylaws came into effect this would create such a situation. All we need is confirmation of this and lawyers can fix this.
*        TR - Reminder the only thing we are doing here is ensuring consistency between our final report and the draft Bylaws. Adding things that are beyond our report is not our responsibility.
*        AGreenberg - True, but the previous Bylaws gave the Board room to fix such things which when the new Bylaws come into effect will no longer be possible for the Board. Yes such a change is beyond what was in the CCWG recommendations.
*        HGregory - Such things will happen in this type of large document. Now that we are aware of this we, including ICANN legal, should be able to propose language to the CCWG.
*        GShatan - Transitional bylaw would make sense as a place to fix this - but do not want top open the door to wholesale delaying of reviews.
*        TR - I do not know if there are any other topics which require such action and if this is not the case then it may not be our responsibility to handle this. Let us ask the legal teams to consider this.
*        HGregory - whatever we come up with should be part of the CCWG response to public comment on the draft Bylaws.
*        TR - any further comments or questions? none. We can move to the next agenda item.

5.  ICANN Legal discussion on section 1.1 d of the draft Bylaws (MW)   Document shared:  Explanation of grandfathered agreements.pdf<https://community.icann.org/download/attachments/58730392/Explanation%20of%20grandfathered%20agreements%20%2800788389xA3536%29.pdf?version=1&modificationDate=1461735615000&api=v2>
*        MW - this is about the GRANDFATHERING provisions in the Mission and Core Values. The conclusion of our previous call was that we would hold a plenary discussion of this. Our lawyers have provided formal input to us on this topic explaining their support for the language.
*        SEisner - We provided an explanation document on the various grandfathering clauses. The contracting of the IANA function had to be added to ensure ICANN could continue to perform its historic mission wrt IANA. This does not add anything to ICANN's mission, but simply confirms that these responsibilities and contracts cannot be challenged as not being in ICANN's mission.
*        JJeffrey - This is a good start. We all need to know what those documents, PTI Byalws, ICANN-PTI contract etc. but these will be the subject of public consultation etc.
*        ASullivan - What JJ has said is part of what I am concerned about. there are provisions in the grandfathering clauses that refer to documents that have not yet been written and refer to parties which do not exist (PTI).  What is more troubling is that including external documents in the mission could technically modify the mission without a formal process for approving such changes. This seems to create a truck-sized hole. More concerned about 2 provisions - the PTI agreement and the 5 year plan. But overall the notion of including things which are not yet in existence in the mission.
*        RFei - I understand why this is a concern - what is important is that those documents need to be in existence when the Bylaws come into effect as the draft Bylaws currently state. The discomfort should be about what those documents will actually say.
*        ACooper - this conversation clearly shows the issue is timing. It is quite likely that there will not be sufficient time to have a proper and thorough review of the PTI documents. This provision is not necessary to implement the results of the CWG and the CCWG and creates a giant loophole which would create the opportunity to amend the mission indirectly. Do not think we can approve these Bylaws with this clause. The ICG proposal says the most important thing is that the IANA functions continue to be performed properly vs having ICANN perform these functions.
*        JCarter - I am more relaxed on this given the community will review those proposals which are not yet defined.
*        GShatan - As a lawyer who does this type of work regularly - convergent drafting - all documents WILL exist at the time they come into force. RA and RAA grandfathering should not be up for discussion here. So this type of situation is not exceptional.
*        SEisner - PTI contract development - We are working with the community to ensure that the community can be properly consulted. It is important to note that there is not a lot that ICANN can put in the PTI documents given it is about performing the IANA function. The intent is not about preserving ICANN performing the IANA functions - if the operational communities think ICANN should be performing those IANA functions then ICANN should be able to do so without being challenged that it is not in mission. On the PTI Sidley will be involved.
*        Holly J. Gregory (Sidley) from chat:  We also assume that as counsel to CWG we will have an opportunity to weigh in on the PTI Articles and Bylaws and "certify" consistency with the CCWG and CWG Proposals
*        ASullivan - I was listening the discussion on phone and did not follow the chat. There may be a deeper and fundamental issue - the entire grandfathering section sets up a condition that there is no way to question agreements covered by it. I do not understand why this needs to be a piece of fundamental Bylaws and a carve out - including contracts in the mission of ICANN seems to go against the notion of simplicity and clarity for the mission.
*        MW - good to have this discussion. recap of points presented. The two points of view are protecting the right of ICANN to perform the IANA functions for the communities vs having external contracts in the mission. This is a surprising situation with no clear way forward - given ACooper has stated in the chat that additional process safeguards would not fix this.
*        ASullivan - what new text would help (from chat)? There is no need for section D. If there is a need for sub-section D we have a bigger problem. Many issues make it too dangerous. Just remove it.
*        ACooper - On the contracts that are not yet written - we went through this process to define a clear narrow mission - IF the PTI agreements would not expand the mission as originally intended then there is no need for this clause. The situation for existing documents / agreements is different (RA, RAA).
*        MW - sections 11D has several sub-sections, the RA and RAA have been discussed and is not at issue here. B are existing and not at issue. C and D (RZ Maintainer and PTI) are at issue. Uncertain that we can make more progress today. Lawyers have to find a way to ensure that the scope of the ICANN mission as per the CCWG recommendations is preserved. The way the CCWG has scoped the mission cannot be modified by including these yet undefined documents. This discussion should continue on the list.
*        RFei - Concerns about this protection changing the scope of the mission - my understanding is that these agreements would be negotiated to be consistent with the mission.  the purpose is to protect agreements that have been agreed by the community.
*        ASullivan - the IETF considers its relationship with ICANN to be that with a service provider. As such there could be a consensus problem.
*        MW - we will need to summarize these discussions and refer to the CCWG recommendations for the mission. The PTI contract and the RZM agreement will not go through the same approval process as the CCWG recommendations have - the requirement is simply that they go through public comment - which is quite different. There should be no loopholes in the mission. We should ask our lawyers to confer on this and suggest how to address this. I am coming out of this discussion with two different views I would like to avoid having people from the operational communities putting in public comments against these provisions as this would be unfortunate.
*        ASullivan - Nobody wants this transition to fail. The challenge is simply how to write this so it works well for everybody. There is a concern that some may be favoring incumbent (ICANN).
*        MW - We need to follow the requirements of the recommendations of the CCWG. This needs to be discussed on the list and lawyers need to consider this. We should get back to this at our next meeting.

6.  AOB -LS
*        clarification of deadlines.
*        No other points.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160427/68b8f1b0/attachment-0001.html>