February 2015 - Internal-cg

Attendance Roll Call for ICG Call #12
by Jennifer Chung Feb. 25, 2015

Feb. 25, 2015

Hello All, As requested by Alissa, below is the roll call for ICG Call #12. Please let me know if you note any discrepancies. ICG Participants: Kavouss Arasteh (GAC) Alissa Cooper (IETF) Alan Barrett (NRO) Demi Getschko (ISOC) Keith Davidson (ccNSO) Milton Mueller (GNSO) Daniel Karrenberg (RSSAC) Jean-Jacques Subrenat (ALAC) Jari Arkko (IETF) Joseph Alhadeff (ICC/BASIS) Lars-Johan Liman (RSSAC) Lynn St Amour (IAB) Mary Uduma (ccNSO) Michael Niebel (GAC) Mohamed El Bashir (ALAC) Narelle Clark (ISOC) Paul Wilson (NRO) Patrik Fältström (SSAC) Russ Mundy (SSAC) Wolf-Ulrich Knoben (GNSO) James Bladel (GNSO) Xiaodong Lee (ccNSO) Apologies: Jandyr Ferreira dos Santos (GAC) Jon Nevett (gTLD Registries) Elise Gerich (IANA Staff Expert) Manal Ismail (GAC) Hartmut Glaser (ASO) Keith Drazek (gTLD Registries) Kuo-wei Wu (Board Liaison) Martin Boyle (ccNSO) Russ Housley (IAB) Thomas Schneider (GAC) Best Regards, Jennifer

1 0

Action items from ICG Call #12, 25 February 2015
by Jennifer Chung Feb. 25, 2015

Feb. 25, 2015

Hello All, Please find a list of action items from ICG Call #12 below: 1. Cooper and ICG chairs to coordinate with Ismail to draft explanatory text to be published with the 10 September 2014 published timeline (https://www.icann.org/en/system/files/files/icg-process-timeline-graphic-10 sep14-en.xlsx) as an update and send to the internal-cg mailing list for ICG's review. 2. ICG to discuss and call for volunteer/pen holder on the internal-cg mailing list to consolidate information collected during the assessment process of the operational communities' proposals in an ICG report that can be published together with the final proposal. 3. Arkko to provide further information (diagram) to the internal-cg mailing list about the IETF's current overall internal accountability and oversight system related to IANA interaction. 4. Cooper to confirm with ICG members on the internal-cg mailing list that the ICG has completed Step 2 of the assessment process (https://www.icann.org/en/system/files/files/iana-transition-assembly-finali zation-24dec14-en.pdf) for the protocol parameters and numbers proposals. Best Regards, Jennifer

1 0

Finalizing the comments proposal
by joseph alhadeff Feb. 25, 2015

Feb. 25, 2015

Kavouss: By way of clarification, I think you are highlighting a confusion in the drafting which we need to clarify. If ICG poses a question to a community related to a proposal, whether originated by us or one that we receive which we believe needs to be addressed , it must be answered - there is no latitude in that. The more voluntary language was meant only to address an individual question which has come to us form an individual or group outside of the ICG which we don't require an answer to. While we suggest that the community endeavor to address those, as appropriate, we do not require that those questions be answered in an individualized manner. Clearly the current draft, is resulting in confusion and needs to be clarified. Joe

2 1

Action item from ICG F2F
by Jari Arkko Feb. 25, 2015

Feb. 25, 2015

I had an action item from Singapore: > 2. Arkko to do write up of jurisdiction and NTIA oversight in the Protocol parameters operational community. The description for the action item is a bit brief, but my understanding at the meeting was that we had two kinds of questions for the IETF proposal, the first being ones that the community needs to be asked about. We send one such question to the IETF/RIR community. But the second type was requests for further information that can be provided by us or by reference to other, existing materials. These are typically for clarification. The way that I understood my task was that I was expected to list these questions and provide a written answer, having provided brief answers earlier in the discussion and in the meeting. However, this overlaps with the list that we already got from Jennifer. The main items on my list were: 1. What is the situation with enhancements to the agreements between IETF and ICANN? 2. Can you explain what jurisdiction applies for the IETF’s arrangements with regards to IANA and ICANN? 3. Can you explain what oversight, if any, NTIA currently has over the protocol parameters? I believe the latter two questions were already in Jennifer’s table, and I don’t think we need to do more. Does anyone think we need to do more? I can write some additional text, but if it is needed please point out what you would like to see in that text. In any case, the first question is not in Jennifer’s list, and I would suggest adding it to the table: 1. What is the situation with enhancements to the agreements between IETF and ICANN? Answer: The IETF and ICANN update the SLA on a yearly basis. These updates typically specify things that we have together identified as being useful additional or changed procedures. For instance, in the previous SLA in early 2014, a clause was added for performing a 3rd party audit that policies are correctly being followed when performing the IANA function. Most recent SLA can be found on the IETF web site (http://iaoc.ietf.org/documents/2014-ICANN-IETF-MoU-Supplemental-Agreement-E…) Now in 2015 the IETF and ICANN are again updating the SLA and are currently in the process of negotiations. The responsible party on the IETF side is the IAOC. IAOC’s roles and structure is defined in RFC 4071 (http://www.ietf.org/rfc/rfc4071.txt) The parties will provide updates when there is something to report. The IETF general procedure is to keep the SLA as up to date as the current view of IETF requirements is, addressing needs that have come up during the ongoing SLA period.

1 0

Reminder - Senate Hearings Wednesday
by James M. Bladel Feb. 25, 2015

Feb. 25, 2015

ICG Colleagues: Just in case folks weren't already aware, the Senate Commerce Committee will hold hearings tomorrow on the IANA Transition. Scheduled to provide testimony are Fadi Chehade (ICANN), Larry Strickling (NTIA), and Amb. David Gross. The session will begin at 10:00EST (7:00PST - 15:00UTC) and a video stream should be available here (short link): http://x.co/7pGUJ Thanks- J. ----- James Bladel GoDaddy

1 0

Regrets - will miss call
by Elise Gerich Feb. 25, 2015

Feb. 25, 2015

The departure of my flight has been delayed and now I will be on a plane at the time of our phone call. My apology as I will miss the call. Regards, -- Elise

2 1

ICG call
by WUKnoben Feb. 25, 2015

Feb. 25, 2015

Colleagues, prior to the ICG call tomorrow where timeline as well as step2 assessment shall be discussed I’d like to draw your attention to ongoing CWG discussion re the level of implementation detail needed to be covered by the proposals (see attached). I deem the ICG owes to the 3 communities to provide respective guideline as the NTIA was raising the implementation question during the Singapore meeting. There may be a great variation in implementation details. And the various detail options shall directly impact the time needed to elaborate – hence our timeline. I’d like to encourage for the discussion tomorrow in order to come up with guidlines applicable for all the communities. Best regards Wolf-Ulrich From: Greg Shatan Sent: Monday, February 23, 2015 11:59 PM To: Jonathan Robinson Cc: John Poole ; cwg-stewardship(a)icann.org Subject: Re: [CWG-Stewardship] A liaison from the Board to CWG It's all very nice that Milton and Seun and John agree with each other, but I don't think any of us can be the authority on the level of detail required in our proposal -- not me, not Milton, not Seun, not John. Because it's not our opinion that matters. I'll leave it to our chairs to determine exactly how to proceed, but I think we should seek clarity from the ICG regarding the level of implementation detail they expect in our proposal. For instance, is it sufficient to provide the skeleton of an SLA/MoU (as the CRISP team did) or even just a general indication that additional documentation is needed (as the IETF team did)? Or is a fully drafted contract, ready for signature (or at least negotiation) the only thing that is sufficient? Or something in between (a detailed term sheet)? Similarly, if a new group needs to be formed (even if it is just an ICANN working group) is it sufficient to say that a charter will be drafted that will contain at least x, y and z, or is a fully drafted charter needed? Or is it something in between? For the IAP, do we need an actual dispute resolution procedure or just a mention that there will be one? I don't want to make more work for everybody (including me). And I'd rather have less work than more, and get this done faster rather than slower. So, I would actually prefer to be wrong. But let's find out from the ICG what they would consider to be a complete proposal. That's what matters. They in turn can consult Larry Strickling if they feel there's any ambiguity in their own minds. Then we can go forward with certainty. I keep coming back to one thought, however -- if the CRISP/IETF level of detail is sufficient, and we turn in something with that level of detail, and that's essentially what goes to the NTIA, and the NTIA approves that, there will be mamy weeks (er even months) of further work needed before the IANA Functions Contract can be terminated and the post-IANA world can begin. Is that really what's intended? Greg

6 6

Re: [Internal-cg] Question from the ICG
by Jari Arkko Feb. 23, 2015

Feb. 23, 2015

Dear Alissa and the ICG, We refer to the question that the ICG asked the IETF community on 9 Feb 2015 http://www.ietf.org/mail-archive/web/ianaplan/current/msg01610.html > The numbers proposal sees these changes as a requirement of the > transition and the protocols parameters proposal does not. If these > aspects of the proposals are perceived as incompatible would the numbers > and protocol parameters communities be willing to modify their proposals > to reconcile them? We do not observe incompatibilities between the proposals from the numbers and protocol parameters communities. The numbers community expresses a preference to transfer the trademark and domain, while the IETF proposal does not oppose such transfer. This is not an incompatibility, it is something that can be satisfied by implementation of both number and protocol parameters community’s proposals, as already specified. To confirm this, and to determine whether the transfer of the trademark and domain would be acceptable, we consulted the community. It is the opinion of the IANAPLAN working group that they would support a decision by the IETF Trust to hold the trademark and domain on behalf of the Internet community. For details, see http://www.ietf.org/mail-archive/web/ianaplan/current/msg01659.html The IETF Trust also looked at this issue. The trustees decided that the IETF Trust would be willing to hold intellectual property rights relating to the IANA function, including the IANA trademark and the IANA.ORG domain name. For details, see http://www.ietf.org/mail-archive/web/ianaplan/current/msg01664.html In short, we find no incompatibility between the proposals and no need to modify the protocol parameters proposal. Best Regards, Jari Arkko and Russ Housley on behalf of the IETF community and the IETF Trust

3 3

Numbers community response to question from the ICG
by Alan Barrett Feb. 23, 2015

Feb. 23, 2015

The numbers community has made the following response to the question asked by the ICG: ----- Forwarded message from Izumi Okutani <izumi(a)nic.ad.jp> ----- Date: Sat, 21 Feb 2015 08:33:57 +0900 From: Izumi Okutani <izumi(a)nic.ad.jp> To: ianaxfer(a)nro.net Subject: Re: [NRO-IANAXFER] Question from the ICG Dear Alissa and the ICG, We refer to the question that the ICG asked the numbers community on 9 Feb 2015 <https://www.nro.net/pipermail/ianaxfer/2015-February/000397.html>: > The numbers proposal sees these changes as a requirement of the > transition and the protocols parameters proposal does not. If these > aspects of the proposals are perceived as incompatible would the numbers > and protocol parameters communities be willing to modify their proposals > to reconcile them?> We do not observe incompatibilities between the proposals from the numbers and protocol parameters communities, for reasons given below. * It is expectations of the numbers community that the IANA trademark and IANA.ORG domain are available for the use of IANA Numbering Services in the future, even if the IANA Numbering Services Operator is changed from ICANN to some other operator, or if different communities choose different IANA operators in the future. * In order to meet that expectation, it is the preference of the Internet Number Community that the mark and the name be transferred to an entity independent of the IANA Numbering Services Operator. * The numbers community considers the IETF Trust as an acceptable option, provided this is supported by the IETF community, and the IETF Trust is willing to accept it. This is not the only option, and the numbers community is open to consider other solutions which work for other affected parties. This reflects the discussions in the number resources community on this <ianaxfer(a)nro.net> mailing list archived at: Question from the ICG https://www.nro.net/pipermail/ianaxfer/2015-February/subject.html To summarize: The numbers proposal does not set a "MUST" condition to transfer the mark and domain to the IETF Trust or to any other specific entity, and the IETF proposal does not say it will oppose transfer of the mark and domain to the IETF Trust, so we do not observe any incompatibilities. From discussions on the IETF ianaplan group, we observe subsequent decisions by the IETF ianaplan group and the IETF further support the position that there is no conflict. Best Regards, Izumi Okutani on behalf of the CRISP Team _______________________________________________ ianaxfer mailing list ianaxfer(a)nro.net https://www.nro.net/mailman/listinfo/ianaxfer ----- End forwarded message -----

2 1

Singapore questions on the numbers community proposal
by Paul Wilson Feb. 23, 2015

Feb. 23, 2015

Dear all, In Singapore I heard the following questions about the numbers proposal, both from Mr Arasteh. I have only just passed these on the the CRISP team for their response, so I expect we won’t hear back before the meeting on Wednesday. Thanks, Paul. > II.B.2. If the policy sources identified in Section II.A are affected, identify which ones are affected and explain in what way. > > A decision by the NTIA to discontinue its stewardship of the IANA Numbering Services, and therefore its contractual relationship with the IANA Functions Operator, would have no significant impact on the continuity of IANA Numbering Services currently provided by ICANN. However, it would remove a significant element of oversight from the current system > > ICANN has historically provided IANA Numbering Services via the IANA Number Registries under the terms of the NTIA IANA Functions contract, and therefore IANA Numbering Services for the RIRs are currently subject to change in accordance with that agreement. Question: What specifically is the “element of oversight” which is referred to in this section, and how is it to be replaced under this proposal? > III.A. The elements of this proposal > > • ICANN to continue as the IANA Functions Operator for the IANA Numbering Services, hereinafter referred to as the IANA Numbering Services Operator, via a contract with the RIRs; > • IPR related to the provision of the IANA services remains with the community; > • Service Level Agreement with the IANA Numbering Services Operator; and > • Establishment of a Review Committee, with representatives from each RIR, to advise the NRO EC on the review of the IANA functions operator’s performance and meeting of identified service levels. > > This proposal assumes that specific IANA customers (i.e., the number community, the protocol parameter community, and the name community) will have independent arrangements with the IANA Functions Operator related to maintenance of the specific registries for which they are responsible. At the same time, the Internet Number Community wishes to emphasize the importance of communication and coordination between these communities to ensure the stability of the IANA services. Such communication and coordination would be especially vital should the three communities reach different decisions regarding the identity of the IANA Functions Operator after the transition. Efforts to facilitate this communication and coordination should be undertaken by the affected communities via processes distinct from this stewardship transition process. Question: Given the stated need for “communication and coordination” between the communities, how is this to be achieved under this proposal? ________________________________________________________________________ Paul Wilson, Director-General, APNIC <dg(a)apnic.net> http://www.apnic.net +61 7 3858 3100

2 2