Minutes of the 2020-09-09 IAB Teleconference
- Jari Arkko
- Ben Campbell
- Alissa Cooper (IETF Chair)
- Michelle Cotton (ICANN Liaison)
- Stephen Farrell
- Wes Hardaker
- Cullen Jennings
- Mirja Kühlewind (IAB Chair)
- John Levine (Temporary RFC Series Project Manager)
- Zhenbin Li
- Cindy Morgan (IAB Executive Administrative Manager)
- Mark Nottingham
- Karen O’Donoghue (ISOC Liaison)
- Colin Perkins (IRTF Chair)
- Amy Vezza (IETF Secretariat)
- Jiankang Yao
- Harald Alvestrand (ICANN Liaison)
- Jared Mauch
- Tommy Pauly
- Alvaro Retana (IESG Liaison)
- Jeff Tantsura
- Alexey Melnikov (CFRG Chair)
- Stanislav Smyshlyaev (CFRG Chair)
- Greg Wood
1.2. Agenda bash & announcements
No changes were made to the agenda.
1.3. Meeting Minutes
The following meeting minutes were approved:
• 2020-08-26 business meeting – (draft submitted 2020-08-26)
2. IAB Review of Crypto Forum Research Group (CFRG)
Alexey Melnikov and Stanislav Smyshlyaev joined the IAB to give an overview of the CFRG’s activities. According to the CFRG charter:
- The Crypto Forum Research Group (CFRG) is a general forum for
discussing and reviewing uses of cryptographic mechanisms, both
for network security in general and for the IETF in particular.
- The CFRG serves as a bridge between theory and practice, bringing new cryptographic techniques to the Internet community and promoting an understanding of the use and applicability of these mechanisms via Informational RFCs (in the tradition of, e.g., RFC 1321 (MD5) and RFC 2104 (HMAC). Our goal is to provide a forum for discussing and analyzing general cryptographic aspects of security protocols, and to offer guidance on the use of emerging mechanisms and new uses of existing mechanisms. IETF working groups developing protocols that include cryptographic elements are welcome to bring questions concerning the protocols to the CFRG for advice.
The CFRG’s goals include:
- Defining/standardizing crypto primitives for use by IETF and other SDOs (e.g. W3C)
- Being a meeting place for both academics (cryptographers) and practitioners (security protocol designers and implementors)
- Educating IETF participants
- Providing cryptographic expertise for IETF WGs and the ISE
CFRG has published a number of RFCs:
- RFC 7539, “ChaCha20 and Poly1305 for IETF Protocols”, 2015-05, Obsoleted by RFC8439
- RFC 7664, “Dragonfly Key Exchange”, 2015-11
- RFC 7748, “Elliptic Curves for Security”, 2016-01
- RFC 8032, “Edwards-Curve Digital Signature Algorithm (EdDSA)”, 2017-01
- RFC 8125, “Requirements for Password-Authenticated Key Agreement (PAKE) Schemes”, 2017-04
- RFC 8391, “XMSS: eXtended Merkle Signature Scheme”, 2018-05
- RFC 8439, “ChaCha20 and Poly1305 for IETF Protocols”, 2018-06
- RFC 8452, “AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption”, 2019-04
- RFC 8554, “Leighton-Micali Hash-Based Signatures”, 2019-04
- RFC 8645, “Re-keying Mechanisms for Symmetric Keys”, 2019-08
Much of CFRG’s output feeds directly into IETF work in groups like TLS, MLS, IPSECME, LAMPS, and DCRUP. IETF occasionally comes to CFRG with specific requests, such as what is the key lifetime boundary for a particular cryptographic mode of operation, or which elliptic curves/PAKEs should be used in a particular specification.
The Crypto Review Panel is a panel of experts (academics and applied security experts) that reviews literature on new crypto algorithms. They review documents for readability and implementability, as well as outlining whether there may be security issues with the documents, based on the current state of research. They are chartered to do reviews of CFRG documents, documents from the Security Area of the IETF, and the Independent Stream. There are currently nine members who are appointed for two-year terms ending in December 2021.
In the short term, CFRG has a number of documents that are ready or nearly ready for IRSG review, including:
- draft-irtf-cfrg-hash-to-curve, “Hashing to Elliptic Curves”
- draft-irtf-cfrg-pairing-friendly-curves, “Pairing-Friendly Curves”
- draft-irtf-cfrg-hpke, “Hybrid Public-Key Encryption”
- draft-irtf-cfrg-spake2, “SPAKE2, a PAKE”
In the medium term, there are several other active CFRG documents:
- draft-hoffman-c2pq, “The Transition from Classical to Post-Quantum Cryptography”
- draft-irtf-cfrg-cpace, “CPace, a balanced composable PAKE”
- draft-irtf-cfrg-vrf, “Verifiable Random Functions (VRFs)”
- draft-irtf-cfrg-voprf, “Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups”
- draft-krawczyk-cfrg-opaque, draft-haase-cpace (PAKEs)
- draft-irtf-cfrg-kangarootwelve, “KangarooTwelve” (hash/XOF)
- draft-irtf-cfrg-ristretto255, “The ristretto255 Group” (technique for constructing prime-order groups from non-prime-order elliptic curves, e.g., Curve25519)
Overall, CFRG strives to be a place where people are happy to bring their ideas and be a center of cryptography-related expertise for the whole Internet Community. They focus on having an obviously open, inclusive, and transparent process.
Colin Perkins noted that the IAB’s Evolvability, Deployability, & Maintainability (EDM) Program might be of interest to CFRG. Mirja Kühlewind encouraged the chairs to sign up for the EDM mailing list.
Colin Perkins thanked the CFRG chairs for their update.
3. Monthly Reports
3.1. ISOC Liaison Report
–Begin ISOC Liaison Report, Karen O’Donoghue–
Internet Society Liaison Report — September 2020 ISOC IWN Internet Impact Assessment Toolkit Released The Internet Society Internet Way of Networking project has released an IWN Internet Impact Assessment Toolkit. The objective of this toolkit is to create a powerful narrative that empowers the Internet Society and its community of chapters and members better understand the foundation that underpins the success of the Internet. By defining the critical properties of the Internet, we now have a baseline against which new developments – from technology proposals to regulatory interventions - can be analyzed. https://www.internetsociety.org/issues/internet-way-of-networking/internet-impact-assessment-toolkit/ ISOC Foundation Launches New Grant Programme: The Internet Society Foundation has launched a new grant programme supporting research on the future and sustainability of the Internet. This programme will be open to independent researchers and research institutions around the world, awarding grants of up to US$200,000 for research lasting up to two years and initially focused in one of two categories: -- Greening the Internet – how the Internet affects and is affected by the environment -- The Internet Economy – how digital technologies are transforming our economic landscape The programme began accepting statements of interests on 1 September 2020. Full proposals will be accepted on a rolling basis thereafter. These grants are intended for applied research that will be published and made available to the scientific community at no cost. https://www.isocfoundation.org/2020/09/announcing-our-new-research- grants-exploring-the-future-of-the-internet/
–End ISOC Liaison Report, Karen O’Donoghue–
3.2. IRTF Chair Report
–Begin IRTF Chair Report, Colin Perkins–
IRTF chair report to the IAB for the month ending 8 September 2020. # Research Groups * Seeking co-chair for DINRG * Side meetings on 6G-and-IP and FIPE (“Future Internet Protocol Evolution”, a.k.a. “NewIP”) were held along with IETF 108. The 6G-and-IP proponents are developing their proposal, with focus on routing privacy for identifier-locator routing systems. The FIPE proponents have yet to return with an updated proposal. # ANRP * In the process of putting together the award committee and call for nominations. Nominations will open in the next few days and close 22 November. # ANRW * Discussing format and potential co-chairs for 2021 workshop. # Documents and Errata draft-irtf-icnrg-nrs-requirements-03 in IRTF chair review draft-irtf-icnrg-nrsarch-considerations-04 in IRTF chair review draft-irtf-panrg-what-not-to-do in IRSG review draft-irtf-panrg-questions in IRSG review draft-irtf-icnrg-icnlowpan-07 in IRSG review draft-oran-icnrg-qosarch in IRSG final poll draft-irtf-icnrg-icn-lte-4g-05 in IRSG final poll draft-irtf-nwcrg-network-coding-satellites in IESG conflict review draft-irtf-cfrg-argon2 in IETF conflcit review draft-irtf-cfrg-randomness-improvements with RFC Editor draft-irtf-icnrg-disaster with RFC Editor Started processing RFC errata backlog.
–End IRTF Chair Report, Colin Perkins–
3.3. ICANN Liaison Report
–Begin ICANN Liaison Report, Harald Alvestrand–
ICANN report - up to September 9, 2020 This report covers ICANN events from June 16 to September 9. It only calls out a few items of special notes. Meetings ICANN remains on a “no physical meetings” basis. The October Annual General meeting (AGM, ICANN 69) is going ahead as a pure virtual meeting, and there’s no sign that there will be a non-virtual part of the spring meeting either. So far, the ban on meetings also applies to community and committee meetings, including the NomCom; this has led to a certain delay in the reporting of results from NomCom. New TLDs (aka gTLD Subsequent Procedures) The GNSO WG tasked with defining the rules for the next gTLD round delivered its “draft final report” for public comment on August 20, with a comment deadline of September 30. This appears to have created no big waves in the community, indicating that the output was close to what the community expected. The report will be revised based on community feedback, and issued as a final report that has to be approved by the GNSO Council before being sent to the board. EPDP phase 2 (aka WHOIS in the age of GDPR) The “Final Report of the Temporary Specification for gTLD Registration Data Phase 2 Expedited Policy Development Process” was published on July 31 - it’s a 200-page document, proposing a mechanism where ICANN would institute a function that accredited organizations with legitimate interest in non-public WHOIS data and pre-processed requests, but where decisions to reveal data (and the databases themselves) remained with the registries. The report is not uncontroversial; in particular, SSAC has issued a minority statement (SAC112), indicating that it does not agree with some of the conclusions of the report. Of note, the SSAC does not think that the financial model envisioned is either fair or sustainable. Board membership The ccNSO has appointed Patricio Poblete to take over the seat currently occupied by Chris Disspain. He will formally take his seat at the virtual AGM in October.
–End ICANN Liaison Report, Harald Alvestrand–
3.4. IANA Liaison Report
–Begin IANA Liaison Report, Michelle Cotton–
IANA Services Liaison Report – 9 September 2020 SLA Deliverables Update: - Not available for August 2020 statistics yet. Report will be ready by 15 September 2020. Other News: - None IANA Services Operator and IETF Leadership Meeting Minutes: MEETING MINUTES – BEGIN Summary of Meeting Minutes Thursday, August 6, 2020 Virtual meeting IETF-108 18:30 UTC Attendees: Jay Daley, IETF LLC Executive Director Mirja Kuehlewind, Incoming IAB Chair Alissa Cooper, IETF Chair Suzanne Woolf, IAB IANA Program Russ Housley, IAB IANA Program Ted Hardie, IAB IANA Program Harald Alvestrand, IETF liaison to ICANN Board Kim Davies, VP, IANA Services, ICANN, President, Public Technical Identifiers (PTI) Michelle Cotton, Protocol Parameters Engagement Sr. Manager Sabrina Tanamal, Senior IANA Services Specialist 1. Introductions and Welcome 2. Review of Action Items from previous meetings Action Item: Reach out to Glenn and give updates if there's any pushback re "IANA" usage Status: M. Cotton will start discussions after licensing topic is finished with Jay and the trust Action Item: Draft document to remove .int names that are no longer needed Status: In progress Action Item: .arpa draft to send to the wider group is in progress. Status: Updates later in agenda Action Item: Follow up on .arpa whois information Status: M. Cotton had some internal discussion over the last few months and will follow-up by email. 3. IANA Services Activity/Performance Four months of between-meeting cumulative stats are in plenary report: https://www.ietf.org/about/administration/reports/ No impact to IANA service levels due to COVID-19. IANA staff are working remotely and requests are being processed as normal. Discussion: H. Alvestrand: Thank you! 4. Update on Supplemental Agreement Deliverables Draft 2021 Supplemental Agreement Discussion: M. Cotton: 2021 Supplemental Agreement is currently being drafted. The only major change is the update to the delivery dates for the Annual Review of Protocol Parameters. We're just moving the dates a month forward so that it works better with for internal timing. R. Housley: Does that mean that the next audit will cover 11 months? M. Cotton: No, the audit period doesn't change, the only thing that changes is the delivery date of the report. Annual Review of Protocol Parameter work Annual Audit currently underway (evidence collection in progress) Request to change the delivery date for the Annual Review of Protocol Parameters work Discussion: M.Cotton: Confirmed with ICANN legal and IETF LLC Executive Director that a letter signed by both parties to acknowledge the change would be acceptable. The letter is currently being drafted, just waiting for the link to the minutes from the last IAB business meeting call so it can be added to the letter. M. Cotton to send the letter to Jay and Sam Eisner (ICANN legal) in the next few weeks. 5. Update on Operational Activities Customer Service Feedback post-ticket surveys (satisfied/unsatisfied - HDWD), general feedback HDWD (April 2020-June 2020): Satisfaction Rate: 100% (Apr), 86.70% (May), 100%(Jun) Response Rate: 56.5% (Apr), 69.6% (May), 36.4% (Jun) Discussion: M. Cotton: May number was low because we received two negative responses due to timing issues and the other one we did not get a response when asking for more details. M. Cotton: We did receive feedback regarding adding links from the main media types page to the provisional registry and a few other places which was completed. Feedback from previous months regarding expert taking too long. Improvements in process or already implemented for port number requests. We plan to apply the same changes to the media-types requests next. Media-types is where we see long turnaround time. .ARPA Management There was a 00 document version posted: https://datatracker.ietf.org/doc/draft-iana-arpa-authoritative-servers/ Discussion: K. Davies: All the feedback we received has been integrated into the GitHub repository where we're managing the contents of the draft, it's ready to go to -01. T. Hardie: The next step is to take it to DNSOP and the remaining groups for feedback, S. Woolf do you expect any particular pushbacks? S. Woolf: It hasn't come to them, but not anticipating any problems. I'm not sure if anybody is asking DNSOP to adopt this draft. T. Hardie: The intent is not to adopt it but just to review. If you can assist Kim and Jari in sending the message to DNSOP and responding to questions. K. Davies: Updated the Root Zone Evolution Committee as part of ICANN, they concur that this is out of their scope. Decision: Next step is for K. Davies and J. Arkko will send to the DNS groups for feedback. Quality Assurance Review Process Reviews continued for data from March 2020-June 2020. Continue to review/revise/add questions monthly Improvements to ticket processing and record keeping has already resulted from these reviews Discussion: M. Cotton: Hopefully at the next meeting, we'll have a larger overview update as to what our experience was to the last six months and what our plans are for the future. TZ Database Secondary Expert Tim Parenti was officially approved by the IESG. Discussion: M. Cotton: Still looking at some general time zone database process development improvements and bringing the repository under IANA supervision. K. Davies: We've been reviewing the operational practices and try to tidy it up. One of the obvious failing things from my perspective is that the bulk of the work that is being done in the time zone community that happens on the mailing list that's hosted by IANA is facilitated through a 3rd party git repository that is hosted by Paul Eggert in his role as the TZ Coordinator. I've been discussing with Paul about rehoming that development repository within IANA. It would still be on GitHub. With respect to the mailing list, it would be appropriate that if we administer the git repository and provide access to it in line with the IESG appointments. Paul doesn't believe that it's appropriate that IANA should have any administrative function of that development repository. So wanted to see if this is something that I should continue to pursue with Paul or just let it be. But I think Paul has many years of experience well before IANA has any role and we don't want to get in the way for the good work that he's been doing, but at the same time, we have this general concern that it should be administered appropriately. R. Housley: ...make Paul the responsible party? Is that what you're proposing? K. Davies: We actually have an IANA dashboard organization, and we're looking at other IETF-related registries who use GitHub as a location, I think Link Relations is the other registry. But our intention is not to micromanage but to give admin rights to those IESG appointed experts role and just monitor it for access. R. Housley: I would say that makes complete sense to me because we don't want to find ourselves in this situation where somebody retires, and it was all up in the air that's what we're trying to prevent by moving it to IANA, but we would prefer that it happens in a way that he is cooperating/collaborating. J. Daley: Is there a hidden political intent here to have somebody who is more flexible about such issues as Asia/Shanghai or Asia/Beijing or is that not what this is about at all? K. Davies: I don't see it related to those kinds of issues at all. It's more of the editorial decisions that are being made. A. Cooper: In general, it's better to have some kind of organization owned for these things in case he's not available. So, I think IANA is a fine place to have that. K. Davies: OK, so we'll continue to pursue this discussion and update the group if anything material happens. Updates on Other Misc. Operational Activities IETF Trust is working on the license wording topic for material in IANA protocol parameter registries. Discussion: M. Cotton: Trustees met on 21 April. Joel Halpern stopped by during the IANA office hours and mentioned that he's working on the ID. J. Daley: Summarized how this work started. Joel has drafted an ID and now finishing the conversation with the Trustees, whether it can come out to the community. M. Cotton: So Jay, after this is finished, we'll have a document that we can send people to review if they ask about the rights of the information of the IANA registries? J. Daley: Yes. A. Cooper: My issue with this is this text doesn't say what Jay said; it says something else. I think that the way that it's phrased here is it's going to raise challenging conversation that doesn't need to be had. It says here that the Trustees are waiving these rights...but they never had any rights. So if the real problem is there are other people asserting rights that don't exist, then that's what it should say. J. Daley: The problem is in some jurisdictions; they do have those rights. H. Alvestrand: We've been through all of this with the RFC series before. There are rights you can't waive at least in the European, so the language should focus that the Trust grants permission and the rights it has. R. Housley: The difference with that and this, I think that with the RFC Editor, you give a copy to the Trust where here you have all the information in the registries that is available to anybody who wants it. H. Alvestrand: The biggest difference with the RFC situation, we had a number of people who wanted something else. CCO is fine but it's a license and not a waive. A. Cooper: I don't know what the right answer is, but I think it should just say what the intent is. J. Daley: It's about what the law is in certain jurisdictions. CCO is a waiver, not a license. It's very different that other Creative Commons. Both CCO and what the Trust are going to write is very clearly worded to say if any rights are granted to us in any jurisdiction, then we waive them. A. Cooper: What are those, though? That's my question. Is there a list of them somewhere? J. Daley: No, this is the reason for this is to be the catch all because the IETF Trust doesn't believe that it has those rights and doesn't want those rights. A. Cooper: It's super vague. I'm going to stay out of it. M. Cotton: Jay, what's the plans for this document as far as publication? Is it planned on becoming an RFC? J. Daley: I believe they're planning on it becoming a statement that goes on their website. M. Cotton: OK, as far as going to the community for feedback, is that just something the Trust would announce, or would it be some type of Last Call? J. Daley: I don't know. The Trust is still discussing. M. Cotton: OK, we'll see what happens there. 6. Other Topics for Discussion Registry Workflow System Discussion: M. Cotton: We're still working on our internal registry workflow system. We still plan to start with PEN as the first phase. We had some shifting resource allocation for working on this, so we're still actively working on it. K. Davies: Just reinforcing, we have limited resources at the moment, and COVID makes it difficult to get project work done as opposed to operation. The resources are focused on PEN, and we'll add other registries. Decommissioning Inactive Request Process Email sent to mailing list with information about why we no longer will be using this process. Discussion: M. Cotton: Sent an email about decommissioning the inactive process. R. Housley: Ted and I both responded to that email. K. Davies: In the last months, we've discussed with our legal team and we're not prohibited from advising applicants the reason we're no longer able to proceed, so we should be transparent in that regard. R. Housley: Originally there was an issue with letting the requester know you can't proceed M. Cotton: Did that answer Ted's question as well? T. Hardie: No, we wanted to have some time to look at any requests that came in to see if it's important enough to request an OFAC license in order to process it. With this new process, how does that review take place? I would suggest formally including in your policy some mechanism by which a question is asked does this deserve an OFAC license being sought? K. Davies: When it comes to purpose-based registrations, where there's an emerging standard to record values in support of that, I believe we would try to pursue a license. M. Cotton: The ones where we weren't able to process before was a PEN request. Perhaps we can go back and have some discussions about what we can put into place where if we do get a response back that we can't process this request, we do the investigative work and see what kind of impact is this going to have and do we need to have legal obtain that license. T. Hardie: I really appreciated Kim's focus on interoperability here because I think that's the right marker here. M. Cotton: I agree, and we're going to take that back and discuss internally what we need to add to our processes to be able to do that. Luckily, I don't think that affects not using the inactive process if we have some type of replacement steps to make this consideration if we need to do anything further. We'll report back on what we need to do to deal with those types of situations. Decision: No issues with decommissioning the Inactive process. Process steps do need to be in place to review requests that can not be processed for interoperability issues. Open uri scheme request Discussion: M. Cotton: I wasn't sure if this needed discussion, I know that Mr. McSweeney has sent an email to the IAB now. We still have an open request with him where he's asking more questions. At this point, would it be good for us to let him know that we're not going to do anything until the IAB responds to his inquiry? Just curious if anybody has any feedback or recommendation. M. Kuehlewind: We haven't discussed this in the IAB yet. A. Cooper: He meant to appeal the IESG decision. M. Kuehlewind: It's in progress so I will send an email internally to the IAB and discuss next steps. M. Cotton: We will reply back with our understanding that it is with the IAB. NEW ACTION ITEMS: (Note: Added action item numbers to better track/identify action item tasks) 2020-03 Token: M. Cotton Send the draft letter for documenting the change in delivery date for audit report to J. Daley and S. Eisner (ICANN legal) in the next few weeks. 2020-04 Token: K. Davies/J. Arkko Send the .arpa draft to the DNS groups for review. 2020-05 Token: M. Cotton Discuss with IANA team what process steps need to be added or adjusted to review requests that can not be processed. MEETING MINUTES - END
–End IANA Liaison Report, Michelle Cotton–
3.5. RFC Series Report
–Begin Temporary RFC Series Project Manager Report, John Levine–
With the release of xml2rfc 3.0, [the Temporary RFC Series Project Manager] hopes the v3 grammar has stabilized so he can work on updating the documentation and perhaps deprecating or removing features that turned out not to be useful. Henrik Levkowetz, Peter St Andre, Robert Sparks, and he set up an informal group to review and manage updates to the XML grammar which has met and resolved some longstanding open isues. After talking to the RPC, we have a tentative proposal to restore the SLA at the same level it was before the v3 transition. A lower SLA would lead to longer publication times, and a higher SLA doesn't seem practical, at least not at this point. This proposal comes with the understanding that the increased work for v3 will continue to require more staff than before. He's asked the RPC to propose concrete numbers for the LLC to consider.
–End Temporary RFC Series Project Manager Report–
4. Alternate TLDs in the DNS tree
Wes Hardaker referred the IAB to recent proposals to create a new TLD that would house everything private-name wise under [INT]. One party suggests using ‘.internal’ while another suggests ‘.zz’. A draft about the ‘.zz’ proposal, draft-arends-private-use-tld, has been submitted to the DNSOP WG for potential adoption.
ICANN issues two-letter TLDs that follow ISO country codes. Under ISO 3166-1, .zz and .z* are reserved for private use. Wes Hardaker observed that not asking ICANN and ISO for specific permission to use these private use spaces risks them being upset with IETF, and may cause them to change their specifications in ways the IETF assumed that they would not. Wes noted that channeling conversation between the IETF, ICANN, and ISO is an IAB liaison activity.
Alissa Cooper noted that the document is an individual submission that has not yet been adopted by the DNSOP WG; it would be strange to send a liaison statement about a proposal that does not have consensus.
After a brief discussion, the IAB agreed that the DNSOP WG should review both proposals (as well as the issue in more abstract terms), and if they come to consensus, then the IAB can assist further with liaising.
Wes Hardaker reported that ICANN has an open call for feedback on the GNSO New gTLD Subsequent Procedures Draft Final Report, and asked if the IAB should provide feedback. Wes and Jari Arkko will review the draft report and propose a draft response from the IAB. The deadline to provide feedback is 2020-09-30.
5. Action item review
- 2020-06-03: Stephen Farrell and Colin Perkins to schedule a tech chat on contact tracing apps and permissionless innovation. (Note: Check back in on this at the 2020-08-26 meeting.)
- 2020-08-12: Jari Arkko to write a blog post on the COVID-19 Network Impacts Workshop.
- 2020-08-26: Cindy Morgan to post the IAB’s response to the appeal from Timothy McSweeney.
- 2020-08-26: Wes Hardaker to send the IAB’s response to Timothy McSweeney’s appeal via email.
- 2020-06-01: Stephen Farrell (with Colin Perkins and Mirja Kühlewind) to revise the proposal about refactoring IAB Programs based on the retreat discussion.
- 2020-06-05: Tommy Pauly to find a speaker and schedule a tech chat on safe browsing. (Note: Check back in on this at the 2020-9-23 meeting.)
- 2020-08-12: Jari Arkko (with Wes Hardaker) to start a re-write of draft-arkko-arch-infrastructure-centralisation and post it on Github.
- 2020-08-27: Cullen Jennings to write a blog post promoting the paper “Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web.”
- 2020-09-09: Wes Hardaker and Jari Arkko to propose a response to the public comment on the GNSO New gTLD Subsequent Procedures Draft Final Report (comments due 2020-09-30).
- 2020-09-09: All IAB to forward the COVID-19 Network Impacts Workshop Call for Papers to interested parties.
6. IAB Programs
Stephen Farrell reported that he met with Colin Perkins and Mirja Kühlewind to discuss refactoring IAB Programs. Mirja has made some edits to the current proposal, and Colin still needs to do a review. Once this happens, the group will bring the proposal to the IAB via email, and the topic will be added to a future IAB agenda for more discussion.
7. Next IAB Meeting
The next IAB meeting will be on 2020-09-23 at 1330 UTC.