[CCWG-ACCT] Notes-Recordings-Transcript links for CCWG ACCT Meeting #75 - 7 January

Brenda Brewer brenda.brewer at icann.org
Fri Jan 8 14:51:26 UTC 2016

Hello all,


The notes, recordings and transcripts for CCWG ACCT meeting #75 - 7 January will be available here:


A copy of the notes may be found below.


Thank you.


Kind regards,




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 TR (2 min)

*        No one on dial only - no changes to SOI.

2. Recommendation 1 - Inspection rights MW (45 min)

See: http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009306.html

*        MWeill - ICANN concern this could consume extraordinary amount of resources. We have also
received a memo from the lawyers on this topic - relevant extracts have been included in the above
noted document. Firstly scope and limitation of inspection rights. Secondly criteria for deciding to
use the inspection - Sole Designator. Thirdly which is not related to inspection is the
admissibility of the GAC to the Empowered community.

*        MWeill - Our lawyers have advised as to which documents inspection rights apply to. These
could be included in our report and could address some of the concerns from the Board. Are there any
issues with this regarding the scope and limitation. Support in the chat.

*        BTonkin - requirement for more clarity given the basic accounting GL information would not
be helpful. In trying to provide additional information to be useful but needs to be framed so it is
not unlimited.

*        MWeill - Adding recommendations from the lawyers would seem to meet some of the

*        BTonkin - need to look at this not from the POV of a California court but rather from an
IRP panel - needs to definition of terms. Best approach may be for the Board to provide some
suggested red-line text to be clear.

*        MWeill - Second issue - Thresholds for making a request - The third draft proposed that the
SD would submit a request requested by a single SOAC. Board requested standard support level similar
to the thresholds for other powers.

*        JCarter - The lawyers position seemed more reasonably which did not require a high
threshold vs what the Board require.

*        AGreenberg - Answer to this depends on what there is a right to request - so the two issues
are related. My position is between the Board and JC's position. It is not reasonable, personal
opinion, allowing a single SOAC to request. Cal law is clear that this should not be for business
interests. Would need at least 2 SOACs to approve. Board is overreacting but the current proposal is
overly liberal and open to abuse.

*        JCarter - supports lawyers position on principal. This is not really a power, it is the
result of the compromise for moving away from membership. Disagree with AG that this will be abused
by the gNSO given their internal processes.

*        EMorris - Agree with JC. Need to keep things simple so it can be used and not allow it to
be twisted by the Board or staff to delay or block requests. Similarly for who can make a request.
DIDP request example. Making it too complicated is not useful.

*        MWeill - comment by Holly - Holly J. Gregory (Sidley): if requested information is
reasonable related to a community power or right, Alan's concern about improper use of inspection
rights to obtain commercial information is addressed

*        GShatan - Follow on Holly - AG's concerns may be misreading counsel comments on this. gNSO
is not made up of single intent group. Gaining commercial advantage via this information should not
be allowed.

*        MWeill - space is already pretty narrow.

*        CChalaby - Board sees it as a community power vs a designator power. As such using the
standard thresholds would make sense. On fraud or mismanagement a third party could be hired to make
the determination if there was fraud or mismanagement.

*        MWeill - The proposed investigation power proposed by the Board is good and should be noted
in our proposal. CC are things clear.

*        CChalaby - heard but it does not seem that the standard thresholds should apply.

*        BTonkin - The example EM gave was instructive. Accounts will tell you how much we paid a
supplier vs a document inspection right which could show if a contractor has met the requirements of
the contract. So standard financial records it could be ok to have a single SO or AC. For anything
more complex a higher threshold.

*        MWeill - This sounds like an interesting way forward.

*        HGregory - interpretation of our advice has been correct. There may be confusion on what is
covered by inspection rights which does not cover investigations. We were simply trying to match
what members would be allowed under Cal. law.

*        KArasteh - (no sound)

*        MWeill - different levels of requests would require different approval.

*        SDBianco - discussion of sole member vs sole designator - thresholds would of applied to
the sole member so this is consistent. If we had a sole member we would be having the same

*        MWeill - will update the document to reflect low thresholds for accounting records and then
include higher thresholds for investigations and include restrictions for vexatious or frivolous
request in implementation should be allowed to be dismissed.

*        MWeill - not allowing the GAC to be a decisional member. Until we receive formal GAC input
on this we should not discuss this at this point but rather once GAC input has been received.

*        RGross - Caution if we have before NTIA and Congress if we present a proposal with the GAC
being a decisional participant. which could undermine the transition. Also consider rec. 11.

*        MWeill - This discussion will be taken up at a later meeting.

*        KArasteh - We must wait for the GAC to take a position. There is a big difference bet rec.
1 and rec. 11.

*        MWeill - The inspection rights are as discussed here. DIDP is not a community power and is
available to all. This concludes this section.

3. Recommendation 2 - Escalation timeframe LS (45 min)

See:  <http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009307.html>

Discussion points:

*        Notice and opportunity to comply extend periods

*        Extension of deadlines

*        Empowerment of Councils or Charis for the initial steps

*        Removal of certain process steps (simplification)

*        JCarter - 15 day deadlines originally proposed with few steps. Dublin increased the number
of steps substantially. Keeping deadlines short may not allow the use of such powers. Overextending
the timelines may imply its too long to be of any use. The proposal in the document offers 4 options
as noted above. Having examined these it seems that merging the conf. call and forum steps and
extend deadlines. This could allow for extending timelines to 30 days.

*        LSanchez - Opens to questions and comments

*        AGreenberg - Empowerment of councils in unclear. Re merging the levels no major issues
except, need to specify reasonable processes to socialize the intent to use a power.

*        LSanchez - way forward is to include a requirement to socialize any proposed use of a power
in the next draft. We could also include JC's proposal for discussion in the next call.

*        LSanchez - ALAC objection to threshold adjustment proposal - AG should present.

*        AGreenberg - Clarification objected only for the Board removal. ALAC was ok for approving
changes to fundamental Bylaws. Board removal is as revolutionary as you can get. It generates issues
which make no sense especially if it allows 3 SOACs to remove the Board.

*        TBenJemaa - Removing the Board is dramatic - and there is no need to reduce the threshold.
3 is not acceptable. Also for other powers. The reduction proposal is not acceptable. Original
version was better.

*        ASullivan - concerned trying to apply a 3 value system to a 2 value decisions system. I do
not care how this works out - if people can abstain then you have to adjust accordingly.

*        JCarter - The scenario that gave rise to this was not an abstention - the issue was trying
to deal with an SOAC that cannot decide (but we have not defined what counts as an abstention vs not
participating). In this case it ends up requiring unanimity for using a power which is against the
base principles of the CCWG.

*        SDelBianco - explanation from Dublin, need strong support in absence of clear objections.
SOACs have 4 options, support, against, abstain or just communicate to the community.

*        AGreenberg - RE JC comment - we should not psychoanalyze SOAC if they have no answer.
Similar comment. Unrealistic that if someone says no they could enable the action to go forward.

*        JCancio - unfortunate we are discussing the participation of the GAC. Remind everyone this
is about the exercise of community power and this is only sensible if supported by the community at
large - so lowering thresholds is not good and would undermine this exercise.

*        MWeill - Useful debate - threshold on fundamental bylaws could paralyze the company, and it
is special because it is special given it is an approval vs a veto. We could simply lower
fundamental bylaw approval thresholds. this could be a way forward.

*        TBenJemaa - are we reconsidering the Dublin? this should not happen. Abstention is
participation. Thresholds have to be kept as per Dublin.

*        Seun - Supports TBJ and give rationale - we have recall to SOACs have their own processes
to reach agreement. We should avoid reducing thresholds and am in favour of unanimity to remove the
entire Board. Fundamental Bylaw is critical and threshold should not be reduced. Participation by
GAC - why is this still an issue.

*        LSanchez - going forward co-chairs will redraft with the proposed amendments by MW and test
this on the list to understand if this is acceptable to the CCWG.

*        LSanchez - Board suggestion regarding the changing of the number of SOACs.

*        BTonkin - The concept is that ICANN may involve in the future - as such it would be prevent

*        AGreenberg - I have distributed a chart showing the Board proposal if there is a decrease
will not work. Adding units may really depend on circumstances. We should not cast in concrete needs
to be a case by case, it should be a guideline.

*        JCarter - Agree with AG. We will have to consider anyways given adding a new SOAC will
require a change of Bylaws.

*        TBenJemma - agree with AG but also agree with Board that it has to evolve with the changes.

*        LSanchez - co-chairs will draft recommendation based on the discussion and circulate to
consideration by the CCWG.

*        SdelBianco - in considering adding SOAC implies a change in Bylaws but a change of
thresholds are a fundamental bylaw and require approval by the Designator.

*        Lsanchez - reasonable and to be taken into account at time of drafting.

*        LSanchez - Is this approach in line with the concerns of the Board?

*        BTonkin - will consider the written text early next week.

*        LSanchez - concern of = weight between SO and ACs. Still waiting on input from gNSO on this
- as such would recommend this be a pending issue and discuss it when the gNSO input is received so
all comments can be concerned.

*        LSanchez - this concludes this section and we can go to the Break.

Post break notes.

4. Recommendation 4 - Budget (IANA) TR (45 min)

See:  <http://mm.icann.org/pipermail/accountability-cross-community/2016-January/009308.html>

TRickert - subjects:

1.  Confirm clarifications requested by CWG regarding transparency, rationale and role of CWG
Stewardship in elaborating a process for IANA Budget (see pages 5 and 6)

2.  Discuss and refine role of operational communities in IANA Budget veto power as suggested by
ICANN Board and taking into account IAB specific input (IAB does not want "a direct voice in the
budget, either regularly or on its rejection") (see page 6, paragraph 22)

3.  Discuss whether to provide clearer guidelines on caretaker budget or leave it to implementation
(Draft Report was mentioning that details are "under development")

4.  Discuss input regarding inclusion of Budget power as a Standard (instead of Fundamental Bylaw)
(as suggested by NiRA, AFTLD)

*        Trickert -  On the first point, this was included in the second draft but unfortunately not
carried over to the third draft. As such we propose to simply re-introduce the text from the second

*        Seeing no objection this will be carried forward.

*        TRickert - On the second point - IANA Budget Veto. Note from IANA says it does not wish to
participate in a Budget veto. (reads suggested text in the above document).

*        AGreenberg - Comment, should the IANA budget be vetoed it is of concern to all of the
community and not just the operational community. As such do not agree with the Board

*        IOkutani - The ASO believes the third version of the CCWG proposal meets the needs of the
ASO. The fees are adequately addressed by the SLA bet. ICANN and the ASO. This element of the
proposal should not block the transition.

*        JCarter - originally thought this was useful comment by the Board. In WP1 this was not of
interest. Also the IAB and ASO positions it would seem the third draft would be acceptable. Agree
with AG.

*        ASullivan - uncomfortable with para. 22. The relationship bet the IETF and ICANN is managed
by the IAB on the IETF side and the IAB does not want to participate in budget discussions because
they have an SLA for services. The IAB suggested a different approach in the second draft - that the
budget of the IANA operation be frozen over a fixed period. For us this is a straightforward
supplier service agreement.

*        TRickert - AS how can we reword to satisfy the IAB.

*        ASullivan - need to to consider contractual commitments.

*        CChelaby - Board perspective - the idea agrees with the work on the budget - but IANA is a
service to customers so it made sense to have those communities oversee this. Takes note of AG
comments. Comfortable with proposal para 22 and removing IETF/IAB.

*        KArasteh - the only non-SO is IETF - other communities must be involved beyond the
operational communities

*        BTonkin - The last sentence is the key and may have to improved. Have to understand how the
caretaker budget functions. Elaborating further that allows it to deliver on its contracts and SLAs
and services for the security and stability of the Internet.

*        TRickert - the essence of para 22 seems ok but needs some finessing as per the discussion
above. The next draft should go to the mailing list.

*        TRickert - Thrid point - caretaker budget - more details in the proposal or leave it to
implementation? JC to provide background.

*        JCarter - not much to add. there has been good discussions and the principles are solid.
There is not much difference between the options. No view on either option. JZ?

*        JZuck - principles are mostly agreeable for the community. Agree with JC much of this is
going to be technical and such be left to implementation.

*        TRickert - we are doing the third question under budget.

*        CLangdon-Orr - for those not involved in CWG work, there is DT0 which is working on the
caretaker budget. Leave the details to implementation - which the CWG is currently working on.

*        CChelaby - Agree with JZ, and the proposal, caretaker budget should be part of the
fundamental bylaw which was included in the Board comments.

*        JZuck - need to not have too many details in the bylaws. but high level is fine.

*        CChelaby - makes sense.

*        TRickert - it seems clear this is fit for implementation with the amendments as per the
above discussion.

*        TRickert - 4th point - Fundamental vs standard bylaw - Strong wish from the Board for
fundamental. Also CWG requirement makes this a requirement for a fundamental bylaw. Additionally
this has always been presented as a fundamental bylaw. As such it would not seem advisable to make
it a standard bylaw. Would like to hear from those wanting a standard bylaw.

*        AGreenberg - changing now does not seem wise.

*        Trickert - this would close this section.

5. Recommendation 5 - Mission MW (45 min)  refer to public comment summary -

Presentation:  <https://community.icann.org/x/qpRlAw> https://community.icann.org/x/qpRlAw

Deck Meeting #75 Mission Statement

*        MWeill - I will hand it over to Becky to deliver her presentation.

*        BBurr - presentation of the slides - Straw men/persons:

*        GAC Advice, PICs, Contract Provisions: Questions

*        In what way does/should ICANN's Mission Statement constrain the Board's ability to comply
with GAC Advice?

*        Proposition:  The GAC may provide Advice on any matter it sees fit; ICANN must duly
consider such Advice in accordance with the Bylaws, and if it decides to follow such Advice, must do
so in a manner consistent with ICANN's Bylaws, including its Mission Statement.

*        How does/should the Mission Statement limit the permissible scope of ICANN's agreements
with contracted parties?

*        Proposition:  ICANN's agreements with contracted parties may reflect:           (a)
bottom-up, consensus-based, multistakeholder policies on issues for which uniform or coordinated
resolution is reasonably necessary to facilitate the openness, interoperability, resilience,
security and/or stability of the DNS; and (b) other provisions in service of that Mission.

*        GAC Advice, PICs, Contract Provisions: Questions

*        Who should be able to challenge whether or not a contract provision is in "service of" that
Mission, and under what circumstances?

*        To what extent should contracted parties be free to propose or voluntarily accept (and
obligated to comply with) contract provisions that exceed the scope of ICANN's Mission, e.g., to
serve a specific community, pro-actively address a public policy concern?

*        If "voluntary" commitments may exceed the scope of ICANN's Mission, how do you ensure that
such commitments are truly voluntary?

*        Proposition:  Individually negotiated commitments will be deemed to be voluntary.  Existing
RA and RAA language (including standard PICs) are "grandfathered" (as defined in Notes).  Going
forward, a mechanism should be available to permit contracted parties to enter into agreements
without waiving the right to challenge (collectively) a contract provision on the grounds that (a)
it exceeds ICANN's Mission and (b) was extracted by ICANN on an other than voluntary basis.

*        Contracting and Regulatory Prohibition:  Questions

*        The ICANN Board asserts that the prohibition on regulation of services that use the
Internet's unique identifiers, or the content that such services carry or provide is "not
appropriate for inclusion of the Mission Statement."  The Board further suggests that the CCWG
should direct the Bylaws drafting team to incorporate limitations on the reach of Registry and
Registrar contracts in another part of the Bylaws. 

*        Where?  GNSO Section?  General Provisions (Article XV)?

*        Include challenge mechanism to test voluntariness?

*        Impact of this change?

*        KArasteh - Did the GAC identify any limitation of    ICANN accepting GAC advice. Suggest
there should be language to accept requirements of GAC. Second question ICANN Board proposes mission
should be precise and concise - rest should go to scope etc. - is there a proposal how to do this.

*        BTonkin - Board did not object on GPI - Board has simply stated they will need to consider
GPI if their concerns are not addressed. Also yes we need a specific mission. gTLD specific issues
should probably be in the gNSO. The other parts can be included in the respective parts.

*        AGreenberg - on consumer trust - AOC text on this is only an interpretation, and ALAC feels
this is important. Much of the policies should be bottom up vs invalidating PICS which are not
bottom up. RE Picket Fence - policies have certain qualities - and have to remove these from the

*        BBurr - no one is thinking of specs 1 and 4 should be in the mission - they are only notes
for drafting. Current text provides a handle to address the non-bottom up concern of AG.

*        MMueller - the current mission has had consensus for the three rounds. We are not
discussing if the mission is narrow and limited but rather talking about how best to do this and we
cannot move away from this without risking consensus on everything. Agree with implication of BB
analysis. GAC concern re advice Do GAC believe there should be no mission limitations? GAC advice
against mission vs new TLDs would be an involuntary criterion.

*        MWeill - have to close.

*        MHutty - Agree with BB and Milton. One problem vs voluntary commitments. We need to work
things we can get through and not worry about the things we will not.

*        JCancio - (GAC Switzerland): @staff Please include this on the notes as probably I won't
have time to speak: jorge cancio (GAC Switzerland): Dear all: I feel for policy maker what the GAC
and others are seeking is quite simple, which is an impact assessment of the proposed changes. This
is current practice and should be acceptable without any doubt. In the GACs input a series of
elements are identified which should be part of that impact assessment. Otherwise we have no clarity
at all and no objective and neutral assessment at hand which would allow us to determine whether the
proposed changes (which have been subject to last minute changes for a long time) outlaw certain
important instruments which are available now, such as the PICs

*        MWeill - need to keep working on this complex issues. BB should take up the discussions.

6. AOB LS (3 min)

*        Friday CCWG meeting prior to ICANN 55 Marrakech is confirmed



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160108/720981cc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5035 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160108/720981cc/smime-0001.p7s>

More information about the Accountability-Cross-Community mailing list