IETF Chair and IESG Report, IETF-96

This report covers

• notable things about IETF 96, and our technical program
• what our professional standards of behaviour are
• how to see what the IESG does and recent changes in that
• report from the IESG May 2016 retreat
• summary of actions taken after IETF #100 discussion from the IESG perspective
• working groups created, rechartered, proposed, or closed after IETF 95
• a note on new non-WG mailing lists
• some education/mentoring changes
• pointers to ongoing discussions on general process or IESG procedure issues
• currently running (non-technical) experiments
• appeals

In addition, there are several other reports elsewhere:

• The RFC-Editor report can be found here.
• The Secretariat report can be found here.
• The IANA, NOC, and Hackathon reports can be found under the technical plenary on the meeting materials page.
• The IETF blog is frequently updated with posts from the chair and others..
• The IAB report is here.

The meeting and pre-events are running from Saturday July 16 to Friday, July 22nd. All information is available from the meeting website, but here are some of the highlights:

• IETF Hackathon is running from Saturday to Sunday, please join and work on interesting topics. See Hackathon web page. This time, however, the event will run an experiment. We plan to reserve some space in the IETF lounge throughout the week of IETF to help and encourage people to continue to collaborate with their colleagues on various hackathon projects and activities. This is not meant to compete with sessions but rather to provide an opportunity for those without packed agendas to make better use of their otherwise free time. We will see how things go in Berlin, and we welcome your thoughts and suggestions on improving the hackathon at any time. See hackathon experiment mail.


• IETF Code Sprint is running on Saturday, please join and program the IETF tools that *you* need. See Code Sprint web page.


• The Applied Networking Research Workshop (ANRW) runs on Saturday, and focuses on interesting research results. Join the workshop, details at the workshop page.


• Thursday speaker series, Thursday Lunch slot in Potsdam I: Kevin D. Walker will speak about "Advancing Cybersecurity through NGP". See the talk page.


• Female and at the IETF-96? Join the IETF Systers, contact Allison Mankin and see the blog article.

Sponsor: Our meeting host is Juniper Networks. Thank you! Other hosts include DE.CIX, Telekom, Ecix, Strato, A10 Networks, Comcast, Huawei, .berlin, and the Hackathon sponsor for 2016 is Huawei Developer Zone. Thanks, all!

But now on to our actual technical program! Here are some of the highlights:

LEDGER BOF (ART): This proposal relates to the popular topic of using cryptographic ledgers to track assets. Bitcoin does this with currency, but the technology could support other types of applications. However, moving digital assets between accounts operating on different payment networks or ledgers is not possible today in an open, inter-operable way. LEDGER wants to discuss a protocol stack for such transfers. See this internet draft as an example.

QUIC BOF (TSV): QUIC is a UDP-based transport protocol that provides multiplexed streams over an encrypted transport, originally from Google and with plenty of deployment experience. This BoF proposes a working group to standardize a new transport protocol based on experience with QUIC. Obviously, transport services underneath the web have the potential for having a big impact in Internet traffic. An early version of a charter for a possible working group is here.

As a side, this is one of the highly interesting three BOFs on the transport area this time. A few years ago there was relatively little new work on the area, but now the area's proposals seem highly topic and interesting for the Internet. A nice development!

LPWAN BOF: This BoF focuses on low-power wide-area networks. Typical LPWAN networks provide low-rate connectivity to large numbers of battery-powered devices over distances that may span tens of miles. Would these networks benefit from Internet technology, and if so, how? Currently many of these networks are not based on IP, as discussed in the gap analysis internet draft.

PLUS BOF: This group's acronym comes from "Path Layer UDP Substrate". The group's goal is to enable the deployment of new, encrypted transport protocols, while providing a transport-independent method to signal flow semantics under transport and application control. The proponents expect to implement a shim layer based on the User Datagram Protocol (UDP). This provides compatibility with existing middleboxes in the Internet as well as ubiquitous support in endpoints, and provides for userspace implementation. Note that this effort follows from the SPUD BoF in Dallas and the SPUD prototyping effort. See the list.

L4S BOF (TSV): The proponents of this BOF are working on transport mechanisms for achieving both low latency and low loss, while accommodating scalable throughput. Early tests indicated that L4S can keep average queuing delay under a millisecond for all applications, even when together they add up to a heavy load, while keeping congestion loss minimal and utilisation high. The BOF will discuss whether improvements of this nature can be achieved in the greater Internet, and if standards are needed. See the list.

ITS BOF (INT): This BoF focuses on Intelligent Transportation Systems. The goal of this group is to standardize and/or profile IP protocols for establishing direct and secure connectivity between moving networks. Draft charter can be found here.

LURK BOF (SEC): This group, Limited Use of Remote Keys (LURK) focuses on using a large-scale CDN to provide access to a web site that employs HTTPS. Ideally, such distribution should be possible without having to copy the private keys associated with the web site to too many places. The list is here.

IMTG BOF (GEN): We've had a long debate about our meeting locations next year. The MTGVENUE working group (details below) was created to discuss the requirements for our meeting sites. In addition, we've added the IMTG session in the agenda to talk about international meeting arrangements and other issues from the point of view of human rights, and to get some advice from experts outside the IETF in these topics. See the agenda.

MTGVENUE WG (GEN): This new working group will discuss criteria and policies related to the selecting of IETF meeting venues. Many initial drafts can be found from the WG page, and draft-baker-mtgvenue-iaoc-venue-selection is one of the key documents.

DISPATCH WG (ART): This working group will discuss, among other things, the Glass to Glass Internet Ecosystem (GGIE) topic that looks at video and streamed content from a system perspective. Streamed content delivery could be viewed like a composed flow combining many parts, with playback composed of one or more component streams from one or more addresses to one or more devices over one or more networks. An initial draft is draft-deen-daigle-ggie.

ICNRG (IRTF): Information Centric Networking (ICN) has been a popular research topic. Several variants exist, but the basic idea is a new type of Internet architecture based on requesting and receiving data identified by name, rather than sending to and receiving from an address. There is interest in bringing some of this work to a state where it could be more widely used and experimented with. Should the IETF produce RFCs on this topic? The ICN Research Group will be talking about the state of this work, and what parts are ready to progress further.

BABEL WG (RTG): This working group will document the Babel routing protocol. This protocol is used among other things in home networking environments.

LAMPS WG (SEC): This group plans to publish some updates to PKIX and S/MIME technologies, in cases where real deployment and real need can be identified. Currently, the group plans to look at ways to include an i18n email address as a subject alternative name and the use of authenticated encryption in S/MIME.

SIPBRANDY WG (ART): This working group's acronym comes, obviously, from SIP Best-practice Recommendations Against Network Dangers to privacY. The group focuses on end-to-end protection mechanisms for real-time communications environments, in an effort to avoid man-in-the-middle attacks and privacy violations.

Read more of these efforts in their respective mailing lists, agendas, and BOF descriptions, or from this blog post.

IETF meetings, virtual meetings, and mailing lists are intended for professional collaboration and networking (as defined in RFC 7154 and RFC 7776). If there are any concerns or deviations from this model, please talk to the Ombudsteam who are on site during IETF 96: team page.

We've also talked about a lot about proper behaviour on the ietf@ietf discussion list. There are multiple mechanisms to help the discussion on this list stay focused and appropriate. Indeed multiple, perhaps to the extent that it can be difficult to know who to contact. This brief note helps explain what one can expect the facilitators, ombudsteam, etc. to help with, and how to contact them. See the note. Feedback on the note is welcome.

The IESG formal telechat calls are open for observation, and we also post both short and narrative minutes. The minutes are available on the web, at minutes 2016.

The calendar and connection details for following the telechats are at the IESG page.

This time have also now adopted a new practice of publishing minutes from the so called "BOF coordination call". The first set of minutes can be found from June 2016 minutes.

The BOF coordination calls are held before each IETF meeting. They are where the IESG and IAB go through the set of proposed BOFs and possible other new meetings, in an effort to help the responsible ADs decide how specific proposals should go ahead.

The IESG held a retreat in May, and discussed a number of topics. Read more from the blog article.

Our administrative committee is in charge of contracting at the IETF, including making meeting site and hotel decisions. But the IESG has been working to determine what we need to do as a community to ensure that we have proper understanding and documentation of community's requirements for meetings. Our action plan includes the following:

• Charter a working group to specify an RFC for detailed meeting selection criteria.


• Specify another RFC for the official policy regarding geographic meeting distribution. Our current strategy involves rotation through the continents that have most IETF participants.


• Arrange a special session in IETF 96 in Berlin to discuss the role of human rights, visas, and other aspects of international meeting arrangements.


• Commit to a proper, informed process to identify issues that any subgroup (including but not only the LGBTQ community) has with our site selections.


• Commit to sticking better with our policies on geographic distribution, where we've failed to meet as often in Asia as we perhaps should have.


• Continue to work further towards enabling even more virtual collaboration options, in and outside meetings.

For more information about this topic, read: the summary of discussion, the IAOC's suggested way forward, and the IESG's plan on improvements.

The following changes have happened after IETF 95:

Approved: MTGVENUE, LAMPS, SIPBRANDY, BABEL, and REGEXT.

Rechartered: manet, LISP, CORE, and DISPATCH.

Proposed WGs, BOFs, or otherwise under consideration (outcomes undecided before community has had sufficient discussion, of course): QUIC, LEDGER, LPWAN, PLUS, L4S, ITS, LURK, and GGIE.

Closed: IMAPAPND, NETEXT, MIF, DRINKS, TZDIST, and EPPEXT.

New non-wg mailing lists: manycouches (a design team list to identify issues that would arise should an IETF meeting ever be held with O(1000) 'remote' participants), tls-implementers (for chatting about hands-on experience with current IETF related work for TLS), ietf-community-india, ietf-hub-boston, and ietf-hub-bangalore (the last three are local interest groups).

This IETF meeting saw some changes to offer a better experience to newcomers.

First of all the Sunday agenda has been revisited, to not only offer Speed Mentoring, Newcomers' Orientation, and other tutorials, but also to remove the past conflict of the Newcomers' Meet and Greet overlapping with the last hour of the tutorial sessions. The Newcomers' Meet and Greet has been extended to people who have been attending less than five IETF meetings.

To improve further the newcomers experience, we're now thinking to combine the EDU and increasingly important Mentoring activities: more on this later.

The IESG is considering making a statement on IPR declarations, or to be more exact, noting that our procedures do not call for the IESG or the IETF to validate any particular claims; whoever makes IPR declarations is responsible for the content of these claims. See the post.

These (non-technical) experiments are running at this time:

• The ietf main discussion list facilitator arrangements are an experiment, due to end and be re-evaluated in two months. See the experiment announcement.
• The Hackathon is this time continuing beyond the weekend. See the announcement.
• The starting time for the meetings at IETF-96 is 10am. This is an experiment, and feedback will be fed into decisions about next IETF meetings. The IESG has noted feedback received on this recently. See the mail thread.

There have been no appeals since IETF-95. The appeals list is on the web.

The IETF website is being renewed. See the blog post from Joe Hildebrand. We were originally planning to have a live version of the website in use (on a different domain name) during IETF-96, but we're not quite there yet. This should happen in a few weeks, however.

The IANA stewardship transition effort is continuing. In June, the US Department of Commerce National Telecommunications & Information Administration (NTIA) announced that the Internet community's proposal to transition the stewardship of the Internet Assigned Numbers Authority (IANA) functions meets the criteria it set out for the process. This is good news, but we need to work on implementing the transition. IETF and ICANN have written their updated SLA per plan, see the announcement. Our next task is to write and execute contracts to have the IETF Trust act as a home for the trademarks ("IANA") and domain names ("iana.org") related to IANA services, as requested by other communities. This work is proceeding, but it soon becoming on the critical path. Read more from the list post. Read more on this topic in general from this blog post.

In the midst of discussions about particular issues that trouble us with technology or something else, it can be difficult to focus on topics that have a longer timescale. A design team to look at future challenges and evolution of the IETF wrote a draft, and the IETF Chair's conclusion on four things that we should concentrate on are:

1. Make it easier for people to be involved in the IETF.

2. Be even better positioned to use online collaboration.

3. Focus on linking open standards to code, operations, and interoperability.

4. Evolve IETF sponsorship models to focus more on our work than meetings.

Read more from the evolution blog post and the internet draft.