Internet Architecture Board

RFC2850

IAB Minutes 2020-09-09

Home»Documents»Minutes»Minutes 2020»IAB Minutes 2020-09-09

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.