Minutes interim-2020-iab-23 2020-09-09
minutes-interim-2020-iab-23-20200909-00
Meeting Minutes | Internet Architecture Board (iab) IETF | |
---|---|---|
Date and time | 2020-09-09 13:30 | |
Title | Minutes interim-2020-iab-23 2020-09-09 | |
State | (None) | |
Other versions | markdown | |
Last updated | 2023-06-13 |
Minutes of the 2020-09-09 IAB Teleconference
1. Administrivia
1.1. Attendance
Present:
- 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
Regrets:
- Harald Alvestrand (ICANN Liaison)
- Jared Mauch
- Tommy Pauly
- Alvaro Retana (IESG Liaison)
- Jeff Tantsura
Guests:
- Alexey Melnikov (CFRG Chair)
- Stanislav Smyshlyaev (CFRG Chair)
Observers:
- 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
Done/OBE:
- 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.
In Progress:
- 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.
New:
- 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.