ASO AC Attendees
Alan Barrett, AB (Vice Chair)
Fiona Asonga, FA
Naresh Ajwani, NA (Vice Chair)
Tomohiro Fujisaki, TF
Aftab Siddiqui, AS
Louie Lee, LL (Chair)
Ron da Silva, RS
Jason Schiller, JS
Ricardo Patara, RP
Jorge Villa, JV
Hartmut Glaser, HG
Dmitry Kohmanyuk, DK
Wilfried Woeber, WW
Elise Gerich, EG – ICANN
Carlos Reyes, CR – ICANN
Hans Petter Holen, HPH – RIPE Chair
Axel Pawlik, AP – RIPE NCC
Nick Hyrka, NH – RIPE NCC
Antony Gollan – RIPE NCC
Susan Hamlin – ARIN
Hollis Kara – ARIN
Paul Wilson, PW – APNIC
Connie Chan – APNIC
Kenny Huang – APNIC
Akinori Maemura – APNIC
Maria Gayo – LACNIC
Masato Yaminishi – Softbank BB Corp
Toshio Tachibana – ISOC, Japan
Martin Levy – Cloudflare
Rob Blokzijl (online) – RIPE Chairman Emeritus
German Valdez, GV – NRO
Suzanne Taylor Muzzin, STM – RIPE NCC (Scribe)
Douglas Onyango, DO
Filiz Yilmaz, FY
- Agenda Review
- Transition of NTIA Stewardship of the IANA Functions
- ASN Global Policy Regional Consultation
- 2015 ICANN Board Selection Process
- ASO Website Revamp
- ASO Briefing to the ICANN Community Preparations
- Any Other Business
LL opened the meeting and asked GV to perform a roll call. Twelve members from five regions were present and quorum was established at 8:17 UTC. Observers introduced themselves.
2. Agenda Review
LL reviewed the agenda and suggested moving the item regarding the ASO Briefing to the ICANN Community Preparations to the end of the meeting. He said there would be a separate time to speak with the NRO EC.
# FA joined the meeting at 8:22 UTC.
3. Transition of NTIA Stewardship of the IANA Functions
LL asked PW for an update on this issue. PW said that everyone is being asked to comment on the transition, and the public, press and government are all interested, so the messaging is important. He said there was no real surprise about the announcement and the transition was always expected. He said ICANN has gone from a private to a multi-stakeholder organization over the years, but the transition was still expected and steps have been taken throughout the contract with ICANN. He said it’s quite important to keep saying how expected this is, despite the fact that the press want to hear something more newsworthy. He added that the RIRs are ready to do their part during this process.
PW said that what happened at the I* meeting last October was a general look at trust issues within the Internet ecosystem, and that there is a false association between the undermining of trust and the globalization of ICANN, and that this is not the first time this kind of statement has been made. He said that everyone here is well aware of the process of ICANN’s open call for proposals, that the NRO submitted comments and supported the IAB’s call for this transition process to be carried out through different communities. He said that names, numbers, and protocols are seen as ICANN’s three main communities, and that the IAB called for each of those to comment and that the proposed steering group should have a light-weight role in overseeing that process. He said that the NRO supported that and, in the addressing community, they are ready to take on their delegated responsibility.
PW suggested the work that needs to be done is community consultation. He said the relationship with ICANN is well documented, and proposed reviewing existing arrangements, which are well understood and work well, to make sure they’re documented and transparent. He suggested making small adjustments only as needed.
PW explained that what’s happened recently is that ICANN’s plan has been published and the coordination group, which includes PW and Adiel Akplogan, AFRINIC, starts next month with its first meeting. He said there’s been lots of description about how the coordination group should be assembled but not much about how it will work, and that’s okay because it’s up to the group to figure out how they will work.
PW said he hasn’t had any discussions yet with others, but from the NRO side, he thinks the group should continue to look at delegation in a substantial way and have a clear alliance between the addressing communities to come up with the “meat” of the plan. He said that’s what’s already been happening and communities are already organizing meetings, etc., and it’s the coordination group’s job to simply ensure that continues to happen.
PW asked AP whether he wanted to add anything, but AP had no further comment.
EG added that ICANN is conducting business as usual.
PW added that the big question on the number side involves the separation of policy from implementation. He said he is trying to point out to various parties that this separation already exists, and they have followed the ICANN model from the start and agreed on an MoU, that the ASO brings policy to ICANN but ICANN doesn’t mess with the policies, and that ICANN simply ensures that policies are carried out correctly. He said this is different from what’s happening in the names community, and that when people say that structural and functional separation is needed, it’s sometimes because of domain name issues. He said it’s important not to change ICANN functions fundamentally – only where needed if people are concerned about specific issues – because ICANN functions well as is and he wants to make sure that is preserved. He said that proposals about IANA being taken out of ICANN altogether are radical and would have a major impact, and that everyone should look at policy formation only in the names community if that’s where change is needed.
JS said that sometimes people talk about changing the name side of things without realizing how this would impact the address side, such as a proposal about not making whois data publicly available, which would have a major impact on the address side of things.
LL said the group might contribute to the name side of things, in terms of infrastructure and explaining how the registry works, as well as helping with writing policy that affects only specific regions.
WW said he supports these kinds of statements, but looking at history, the numbers community has played a small role. He asked the group to consider contingency planning in case ICANN fails one way or the other. He also asked the numbers community to be alert to signs that the larger community is not listening, and said that some contingency planning would be wise.
LL said the ASO AC enjoys having people who understand the numbers community on the ICANN Board.
HPH asked to share his perspective as the newly appointed RIPE Chair. He said that the RIR system is all bottom-up one and is responsible to the community, so JS’s suggestion that address policy could become top down is not something he sees happening, as everything has to go through the bottom-up model. He said RIRs need someone for a coordination function, and to think about IANA being accountable to the RIRs, then their members, then the end users. He asked how to set up an oversight function so that end users (ISPs) can be sure that IANA has implemented policies as they were set out, and it’s this kind of oversight role he thinks might be needed. He said the numbers structure already in place needs to stand on its own.
LL said the numbers community has a different structure than other groups that ICANN works with, so it’s possible to keep its current structure as part of a bigger ICANN structure.
EG said that ICANN now undergoes third-party audits, including three years of DNSSEC audits. She said there is a separate audit this year of the IANA system and ICANN has just gotten the report from it. She said there is a standing MoU with the IETF, which was just amended to include standard audits. She explained that the RIR component was not included, but they will include systems that support the RIRs.
DK said a new operational contract is needed for things involving numbers issues, such as Whois data, and that while operational functions might fall through the cracks, the group should think about these details. He said he doesn’t believe there is anything to worry about; he just wants to have it in writing if this doesn’t already exist.
LL said they might look at something like an SLA.
There was no further discussion on the topic.
4. ASN Global Policy Regional Consultation
LL asked whether the ASO AC members had gotten more feedback on this issue from their communities.
RP said that in the LACNIC region, the community felt that nothing should be done. He said that, considering the pace of ASN assignments, there’s no need for a global policy to separate 16-bit from 32-bit ASNs in order to deal with their assignment separately. He said the feeling is that a pool of 16-bit ASNs should be reserved for those who can’t use 32-bit ASNs.
AB said there is no real interest in the AFRINIC region in changing the policy. He said some members have turned in their 32-bit ASNs and requested 16-bit ASNs instead, and the AFRINIC staff have been accommodating these requests. He said the community feels the situation is fine and can continue as is.
LL said the RIRs all seem to be on the same page and don’t feel a policy change is needed. He asked for any further feedback.
AS said that AFRINIC would take up to five years to use all the 16-bit ASNs they have, and LACNIC has some until next year. He said that at APNIC, the policy is to assign 4-byte ASNs unless 2-byte ASNs are requested instead. He said there is no consensus in the APNIC region on this, and that there are about three months left before they will run out of 2-byte ASNs. He said APNIC feels they need a policy to deal with the remaining pool of 500 2-byte ASNs that IANA has.
LL said regional assignments are a regional matter, but the group still needs to respond to IANA about whether the policy allows IANA to differentiate between the two types when they get requests from the RIRs. He asked whether everyone felt comfortable enough to respond to IANA at this point in time.
JS summarized the issue by stating that there are two questions being asked. He said the first is whether an RIR can specify how much of each type of ASN they want when requesting more ASNs from IANA (something that he pointed out has already happened in the past). He said the second question is whether RIRs are allowed to maintain two distinct pools (one of 2-byte ASNs, the other of 4-byte ASNs) and whether, if they have run out of only one type of ASN but still have some of the other left, they can they ask for more.
JS said that, in the ARIN region, they have the opposite problem from some other regions, in that they don’t have any 2-byte ASNs left but do have 4-byte ASNs, and they don’t know whether they can ask for more. He said the ARIN community feels there is no technical reason to not be able to deal with 4-byte ASNs, so they’re happy forcing people to use 4-byte ASNs at this point.
LL asked again whether the group is ready to respond to IANA and whether there’s a volunteer to draft the ASO AC’s advice.
JS read out an email from LV that included the text of the 2010 IANA policy on allocating ASNs to RIRs, which stated that RIRs can receive two separate blocks from IANA and that after this date, IANA and the RIRs will cease to distinguish between ASN types and allocate from one mixed pool. He said the question from IANA is whether to allow two distinct pools, and how this relates to regional policy, if at all.
WW said that there are two separate issues. He said the first directly affects the operation of IANA, and has already been answered. He said that allocated blocks of ASNs do not have to come from a contiguous set, which was done specifically to allow IANA to include both types of ASNs in their allocations. He said the second question is whether RIRs should be allowed to internally distinguish between the different ASN types, which falls outside IANA’s mandate and is a regional issue, so it is up to each RIR to decide what they want to do. He added that if anyone thinks a global policy is needed to manage how RIRs deal with this, then the ASO AC should talk about that. But, he concluded, he feels the question dealing with the IANA aspect has already been answered.
AB said that 4-byte ASNs have been around for nearly 10 years, and he has little sympathy for anyone who hasn’t updated their code and hardware in that time. Regarding IANA, he said there are two questions. He said the first is about when an RIR is allowed to go to IANA to request more ASNs, and the second is whether they can ask for a specific allocation of each type. Regarding the first question, he said, IANA is not allowed to differentiate between ASN types but must consider the entire ASN space as one. Regarding the second question, he said, the ASO AC already responded to IANA earlier this year that it can split up its allocations. He said the issue of how RIRs allocate the different types is dependent on their own internal policies. He said that at AFRINIC, policy treats all ASNs as an undifferentiated pool, but in practice, the staff allocate 2-byte ASNs to those who request them.
JS echoed everything AB said. He said he believes ASN space should be undifferentiated, and regarding the second question, RIRs can ask IANA for a split of different types of ASNs. But, he said, the group didn’t give advice on the details of how that should work. He said that the five RIRs could come to an agreement regarding the allocation of the 500 remaining 2-byte ASNs, but he doesn’t know whether the ASO AC should provide advice to the RIRs about that. He said that ARIN gives out 4-byte ASNs unless they can’t be used, in which case they give out 2-byte ASNs. So, he said, he agrees with AB and thinks the group could discuss things further, but that they don’t have to as part of their mandate.
LL said that if the group did give any advice to the RIRs, then they would need to be very open about it so that the communities in the different regions know what to expect.
DK said that rules would need to be set up to make sure one RIR doesn’t try to grab more than their fair share of the remaining 2-byte ASNs, in order to keep things balanced.
JS said it could be a bottom-up process, that there could be a global policy proposal on the remaining 2-byte ASNs, but that it would be a long process.
LL agreed it would be a long process that would need to be further discussed.
RS said the global policy process would take longer than the remaining 500 2-byte ASNs would last.
There was no further discussion on the topic.
5. 2015 ICANN Board Selection Process
LL said that RAP’s term is coming to an end in 2015 and the ASO AC needs to think about when to start the process of appointing another member to the ICANN Board. He said he has made some inquiries with ICANN Board members and staff, as well as HPH. He said that the ASO AC cannot wait until the October 2015 ICANN Meeting to announce their selection, because the NomCom needs it before that.
LL said the feedback so far is that June 2015 might be acceptable, because the NomCom will not make final selections until then anyway. If June 2015 is okay, then LL suggested aiming for a mid-May 2015 deadline for the ASO AC to give ICANN the name. Working backward, he said, that means the ASO AC might have to start the process in late-October 2014 and open the nominations then. He also added that the ASO AC members who are voting should be intimately involved in the interviews and questionnaire round, and that interviews won’t start until at least mid-January 2015.
WW said the group should double check when the summer ICANN Meeting will be next year. He said that the NomCom usually goes through the final rounds of the selection process then, and they will need a few weeks to digest the group’s input. He said that skill sets and geographic distribution would both be important considerations.
CR said the summer ICANN Meeting will be during the same week next year, from June 21-25, 2015.
HG suggested starting the process in October 2014 and finishing by May 2015, as usual. He said having the name in advance is helpful and encouraged the group to maintain the same timeline as usual.
GV reiterated the idea of starting in October 2014 and giving the name in May 2015, after which point ICANN staff would start their review process.
JS said that interview questions would need to be formulated, for both written and in-person interviews. He said the process will continue into 2015, and asked whether it is fair to start the process before new ASO AC members start. He asked what level of input these new members should be able to provide, and how much input departing members should have, which raises questions about the number of votes, etc.
LL said that if an appointment is coming, he would appreciate it if it could be made earlier than December so that the group knows who will be involved.
HPH said that knowing the names in June could leave the NomCom with very few candidates because of the geographic distribution requirements set out in the ICANN Bylaws. He said he is less concerned about skill sets because of the types of issues currently being tackled.
WW said that there is a clear procedure in place and those newly elected ASO AC members coming in on upcoming year are invited to fully participate on the ASO AC, but cannot vote. If anyone is leaving, he said, then the term ends then. Formally, he said, it’s already very clear, and the ASO AC just has to appoint someone else if someone leaves.
HG agreed with WW.
There was no further discussion on the topic.
6. ASO Website Revamp
LL asked to move the presentation about the updated website to later in the day, but asked for a quick update.
NH gave an overview of the current status, saying that the website is nearly ready to go live, pending the group’s approval.
LL noted that the ASO review has not been completed fully.
The website review was moved to the afternoon meeting session.
7. ASO Briefing to the ICANN Community Preparations
LL said the group would discuss the workshop later in the day. He said items to include might be Geoff Huston’s graph on IPv4 depletion, APNIC’s and the RIPE NCC’s soft-landing policies, the status of IPv4 transfer policies in the different regions, IPv6 adoption and the World IPv6 Launch, etc. He asked the group to think about these topics, how much time should be spent on them, and who might want to present.
8. Any Other Business
No other topics were discussed.
LL asked for a motion to adjourn. DK made a motion to adjourn and AS seconded. There were no oppositions or abstentions and the motion passed. The meeting concluded at 9:29 UTC.