The current IETF Administrative Support Activity (IASA) arrangements were created more than ten years ago when the IETF initially took charge of its own administration . The arrangements have served the IETF well, but there’s been considerable change in the necessary tasks and in the world around us since then . What administrative arrangements will best support the IETF going forward?
A series of virtual workshops have been arranged as part of an effort, dubbed the IASA 2.0 project, to gather community input as part of a review and possibly rework of IASA arrangements.
The workshops will help understand what is working well and what challenges or missed opportunities exist in the current system. We also want to understand what the IETF will need in coming years. Possible topics include:
internal IASA and IAOC organizational issues;
roles and interfaces between the IETF, the IAOC, ISOC, the IESG, and contractors;
availability of staff, contractor, and volunteer resources compared to the administrative workload;
finance and sponsorship arrangements.
The workshops will be virtual meetings where the participants can provide their experiences and suggestions. Proposed changes and solutions will be dealt with in a later phase . Meeting notes and an Internet Draft summarizing the input will be produced afterwards.
The agenda will be the same for both workshops, which are scheduled to accommodate participants in different timezones:
IASA 2.0 Workshop 1
Tuesday, 28 February 2017
11:00 UTC (6:00AM ET / 12:00 noon CET)
IASA 2.0 Workshop 2
Tuesday, 28 February 2017
16:00 UTC (11:00AM ET / 17:00 CET).
These documents will be helpful to review in advance of the workshop:
Every year, the IETF selects its leadership through the nominations committee or NomCom process. Today, the committee has announced our new steering group (IESG) members.
The new members are Alissa Cooper (Cisco), who will be new IETF Chair as I am stepping down. Warren Kumari (Google), will be our new Operations and Management Area AD. And Eric Rescorla (Mozilla) becomes the new Security Area AD. Together with the continuing ADs, this is a great team, and the IETF is in extremely capable hands!
When the new members get seated, we will be saying goodbye and thank you to two long-serving ADs: Stephen Farrell (TCD) in the Security Area and Joel Jaeggli (Fastly) in the Operations and Management Area. Their service to the community, dedication to making the Internet better, and rational approach to contentious issues have made the IESG, the IETF, and the Internet better.
Notably, with these appointments we’ll be continuing to demonstrate gender diversity in our leadership. Not only has Alissa been selected as the first female chair, but we’ll continue to have five female area directors serving in the IESG, the most we’ve had at one time. They are in these roles because they are the best people for their roles, but I think this also sets a great example for other tech organisations to follow in gender diversity I would like to challenge other standards organisations to top our results.
The Internet Engineering Task Force (IETF) is a global community of network designers, operators, vendors, and researchers that develops Internet protocols. Our focus is the evolution of the Internet architecture and the smooth operation of the Internet. We do most of our work online, largely through email and mailing lists, but we also regularly meet in-person at locations around the world. Whether online or in-person, we come together as individuals with the shared goal of making the Internet work better.
An important part of the Internet’s success is that it is all voluntary. Everyone connected to the Internet uses the same mechanisms by choice, and the Internet only works because everyone connecting uses the same mechanisms. Those mechanisms are the protocols of the Internet.
Because the Internet is voluntary, it only works if everyone wants to use the same protocols. So, our work on open standards–like that of the open source and and scientific research communities–fundamentally depends on the ability to work collaboratively across national borders.
The IETF does not make comments on political matters. But we do comment on topics that affect the IETF and the Internet. Specifically, the recent action by the United States government to bar entry by individuals from specific nations raises concerns for us—not only because upcoming IETF meetings are currently scheduled to take place in the U.S., but also because the action raises uncertainty about the ability of U.S.-based IETF participants to travel to and return from IETF meetings held outside the United States.
The situation is fluid. Legal and political processes around the imposition of barriers to travel will likely continue. We plan to track the situation closely in the US and elsewhere. We believe that Internet protocols develop best when people of many backgrounds can offer their contributions, and we are negatively impacted by policies that prevent such collaboration.
IETF meeting venues are always reviewed for potential impact on attendance by participants from different countries. Our next meeting is planned for Chicago, and we believe it is too late to change that venue. We recognize, however, that we may have to review our other planned meeting locations when the situation becomes clearer. We are already reviewing what to do as far as location for the next open North American meeting slot.
RFCs are documents designed to serve a variety of purposes. They offer information to developers engineers on how to make the Internet interoperate. They specify protocols, document registries and code points, and describe network experiments. They do all these things with an eye towards short-term relevancy, while being structured in such a way as to save this body of knowledge in perpetuity. Everything from the numbering scheme to the document style to the file format works together to balance the short-term and long-term needs. The RFC format project is pushing those boundaries quite a bit to make documents more easily consumed in the short term, while relying on the advances in technology to support that long-term archive of material. This is not, however, a post about the RFC format (though if you want to know more, feel free to read the FAQ!)
This is a post about what the RFC Editor is doing to improve the archival component of the RFC Series. Late in 2016, the RFC Editor entered into an agreement with the National Library of Sweden to properly archive RFCs, both the ones already published and new ones as they are posted via an RSS feed. The National Library of Sweden was established in 1661, and has had a digital archive since 1997. They take their archiving very seriously, storing material in a bunker 40 meters under the main building of the National Library.
Picture: The library’s system for digital preservation is called Mimer. Mimer is a figure from the old Norse mythology, a gentle giant who was the guardian of Mimers: a fountain of wisdom from which if you got a sip of that well you would become all wise and know everything that had happened before and everything that will happen in the future.
Stepping back for a moment from this very good news, let me explain a bit why archiving isn’t just about having a nice set of offsite backups. Quite a bit of this is explained in draft-iab-rfc-preservation but here is a quick high-level summary. A proper digital archive, at minimum, has that offsite backup component in storing a copy of the material. Beyond that, it also stores quite a bit of metadata about the document, such as when it was retrieved, when it was published, where it came from, who the author(s) and/or editor(s) are, the original location, title, all assigned identification numbers (such as DOI, ISSN, or other custom information, which in our case is the RFC number) and so on. A digital archive commits to storing and maintaining this information, and doing what it can to try and make sure the document can be viewed by whatever modern technology is available at the time.
The RFC Editor needs partners like the National Library of Sweden to archive the series. The resources available to the RFC Editor are necessarily prioritized towards the editing and publishing of RFCs; the archive itself is in those off-site backups and printed hard copies. Having an organization that specializes in digital archiving is a big win for preserving this rich set of material that documents the birth and evolution of the Internet. The RFC Editor will, of course, continue with proper backups, and will always consider the needs of an archive when we discuss any changes to the format and metadata around RFCs.
And with that, I want to offer many thanks to the people at the National Library of Sweden for agreeing to archive the RFC Series. Tack!
The essence of the IETF is that it is a place for people who both write code and specs. The IETF motto is “Running Code and Rough Consensus”. With that in mind, a big part of our work is helping and encouraging for that code writing to happen. This happens at many levels: the IETF Hackathon focuses on open source projects and Internet technology, the CodeSprint is about IETF’s own tools and web services, interoperability events test specific pieces of technology, and so on.
We will be hosting another IETF Hackathon at IETF-98 which will take place in Chicago at the end of March. The Chicago Hackathon will run from Saturday March 25 to Sunday March 26, but will surely have follow-ups during the rest of the week. We will also get to demonstrate some of the results in the Bits-n-Bites later in the week.
So do considering joining this event. The signup page is here. You can keep up to date by subscribing to the Hackathon mailing list.
Hackathon is free to attend and open to the public.
And remember that what you do at these events is up to you. You decide what is the coolest tech thing that you need to implement! So don’t be afraid to add your own project or team!
I’ll say that again: add your own topic to the wiki, and work on it!
See Charles Eckel’s mail and the wiki for the details.
I would also like to offer IETF-98 as a place for various interop and test events. We typically have several at every IETF. Many people travel to the IETF anyway, so it is a convenient place to spend some time testing. Let us know if you are planning to do some testing, we may in some cases also be able to help with rooms, networking, and help publicise your event to other networkers!
First, there will be a CodeSprint on Saturday March 25th just before IETF-98 in Chicago. CodeSprint is about IETF’s own tools and web services, interoperability events test specific pieces of technology, and so on. Everyone is welcome to attend! Read more from  and sign up .
And remember that what you do at these events is up to you, you decide. You decide what is the coolest or most useful feature; you decide what IETF data tracker feature you need for your work.
Secondly, we would like to draw your attention to work on tools that serve the IETF, and we would like to signal for a need to draw in further people and vendors in this effort.
Part of the work is on a volunteer basis, both in our Code Sprints and through various long-term efforts. Part of the work is run on a commercial basis, e.g., operations of the various IT systems that our Secretariat provides or the implementation of various new tools that we have decided to implement. The commercial efforts typically require some volunteer effort as well, for instance, Robert Sparks is the project manager for all datatracker related efforts and Joe Hildebrand is the project manager for the IETF web site redesign project.
Thanks to all of the volunteers for their efforts. We are VERY grateful for their work, and it is necessary work. But at the same, we are realizing that resources are spread fairly thin. We’re happy about the turnout in the IETF Code Sprints, but would love to get more people. And we would love to have individuals who care about particular tooling issues enough to adopt them as their longer term project and take them to completion. Getting involved with the volunteer tools work starts best at the Code Sprint, however. The next one will be on Saturday, March 25, just before the IETF begins in Chicago. Join us, and book your flight tickets so that you can spend the Saturday with us!
But the same issue applies even to the commercial parts , and we would like to have more companies or capable individuals bid for some of the projects. The Technology Management Committee and the IAOC have recently awarded the projects for building the tools necessary for the new RFC format, for instance, to two individuals that are very active in the IETF community, one of which was already doing quite a lot for the IETF. For the long-term sustainability of the IETF IT and tool efforts, we would desperately like to extend the set of people and companies looking at and bidding on these efforts. We know that many individuals in the IETF sphere have capabilities in this area, and we’d like to draw your attention to this opportunity as well. We welcome first time qualified bidders, and we pay competitively. If you can do the work, a contract to work on open source tools for the IETF can be rewarding.
Jari Arkko, IETF Chair
Russ Housley, Chair of the IAOC Tools Committee
Do you have an idea that you believe would be worthwhile standardising? Now would be a great time to start talking about it, in time for our meeting in Chicago in March!
New ideas can be proposed in the IETF in many ways:
Small improvements and features of ongoing work: these fit right in, just take the idea to the relevant working group. You can send that mail today!
Bigger new ideas may need a working group’s charter be extended or a new working group be created. Often these can be done directly online after discussion; talk to your WG chairs or Area Directors to get the process started. The proposals for significant new work always get discussed in the whole IETF community, on the mailing list, and approved by the steering group (IESG).
Some bigger ideas benefit from face-to-face discussion with the larger community. This is helpful particularly on complex topics, where we need some time to even get to understand the topic well. This also allows discussion of various common trade-off situations, as improvements often come with cost, for instance.
These ideas need to be discussed in a so called Birds-of-Feather (BoF) session; talk to your Area Director about your idea, and follow the RFC 5434 recommendations for setting up a successful BoF. The deadline for submitting BoF proposals for Chicago is February 10, which is one month away! But the process with new Internet-Drafts, mailing lists, and so on needs to start earlier.
I wanted to send a post summarising my thoughts of the discussions at IETF-97. We had 1042 people from 52 countries on site in Seoul, very active development on a number of fronts, and I thought a successful meeting! (Apologies for sending this post out late, other tasks, holidays, etc intervened.)
The meeting was supported by our host Huawei and co-hosts CNNIC and KISA (Korean Internet & Security Agency), and a long list of sponsors. Thank you for your support!
The topic of the meeting was of course Internet tech and its evolution. The two most active discussion topics were the increasingly serious Denial-of-Service attacks that we are seeing, and the development of a new transport protocol, QUIC, as an alternative to TCP and TLS, especially being more optimized for HTTP/2 usage.
The most recent Denial-of-Service attacks involved a number of compromised Internet of Things devices attacking DNS infrastructure. The IAB had organised a discussion of these attacks as an example of a more general concern: the addition of millions of new hosts has the capability to overwhelm the Internet infrastructure when those hosts misbehave. There are ways to mitigate the attacks, but not without impacts in other ways — such as finding it necessary to deploy your services on large providers.
At the very least, I think it would be beneficial for the IETF community to continue to call attention to folks that the minimum bar when introducing a large number of devices (or any device) to the Internet includes things like automatic software updates and avoiding default passwords. I used to think this was so obvious and it needn’t be said, but I’m not so sure anymore. Nevertheless, the area for us to have an impact is improving on defence and mitigation mechanisms.
You can watch the video from the IAB plenary discussion here:
The IETF recently chartered a working group to specify QUIC (Quick UDP Internet Connections). This new protocol combines the TCP and TLS layers, is typically implemented in user space rather than kernel space, and aims for faster connection setups using resumption, integrated security, and capabilities to evolve the protocol faster (not being in the kernel).
A previous version of the protocol is also already in relatively wide use at Google, and was taken as a starting point for discussion in the working group.
I’m quite excited about this development, and eager to see where it takes us, and it seems that I’m not alone:
Once again the IETF Hackathon was running the weekend before the IETF. I thought it was outstanding to see large student groups among the participants. A student team from SungKyunKwan University worked on the Interface to Network Security Functions (I2NSF) framework, for instance. With jackets made for the event!
There was also a second large student team – on the other side of the world! The team from Université Catholique de Louvain worked on Multipath TCP, but much of their team did their work from back home in Belgium. They won the best of show award:
All videos from the sessions, interviews, etc from the meeting are available as a YouTube playlist. The official proceedings with slides, minutes and everything else are on the IETF website. See also the blog post on routing area outcomes from IETF 97, and the blog post from Srimal Andrahennadi from his experiences in participating as an ISOC fellow at the IETF.
Besides the ISOC fellows group, there are a number of other gatherings happening during the IETF week. ISOC also runs a “Policy Fellows” program, with participants from regulators, governments, and other policy makers that do not usually attend technical conferences. Contact Konstantinos Komaitis at ISOC if you want to participate in this program! The IEPG meeting on Sundays is a discussion among network operators. And the Systers Lunch gathers the women participants. Contact Allison Mankin if you want to join!
So, what’s next? The work has already been going on in the mailing lists and virtual meetings after IETF-97, and will intensify as people come back from holidays. IETF’s official work happens on the mailing list. Our next meeting is at the end of March in Chicago, hosted by Ericsson:
The Internet Governance Forum or IGF is a discussion forum on matters relating to the administrative and policy questions surrounding the Internet. A handful of IETFers attended the yearly IGF meeting, this time happening in Guadalajara, Mexico, in December. We wanted to report what we saw and talk about why the discussions at the forum are important.
From an IETF geek perspective 2000+ people gathering to discuss policy issues in the Internet was quite amazing. The best moments are when people with very different backgrounds can connect. When the medical doctor from India explains the benefits of telemedicine just in reduced travel costs, let alone faster start of treatments. Or when you can connect the Bollywood movie director’s difficulties in getting paid for content in the sharing economy to your friends’ difficulties in your local newspaper industry. I felt we learned to understand the world better in some of these discussions.
IANA, and its transition had dominated global discussions of Internet Governance for the last couple of years. Perhaps unfairly; IANA is not the only and certainly not the most complex issue in this space.
But with the IANA transition behind us, you could feel the change from last year. There was a positive feeling about the community being able to complete this change and a even clearer support for the multistakeholder model of working together on Internet issues than in previous years. And of course, the forum was now able to concentrate more on other issues.
Role of the IGF
The IGF meeting is not all happy progress, however. First off, many of the issues are difficult and global trends run their own course. What can you or me or the Bollywood movie director do about the sharing economy, for instance?
Secondly, people really are different, ranging from the government officials to business specialists to lawyers to techies. And in many cases our ability to be multilingual, to speak both about our tech, policies, and business aspects is limited. You see the (rare) government official who just reads statements, you see people who have a difficult to understand that the world really has changed, us techies sometimes struggle to see the big picture, and all of us would benefit from even better connection to ongoing Internet practical reality.
But the value of the IGF in our view is that it offers a place for discussion, place for understanding the global challenges and opportunities better. It is not a perfect solution to get rid of your favourite Internet annoyance; but there may not be perfect solutions.
We’re also kind of fond of the IGF’s new working methods that focus on Best Practice Forums (BPFs) and Dynamic Coalitions (DCs) that operate throughout the year, and produce guidance that is voluntary but can help various parties recognise how they can deal with a particular issue.
As an example, the Dynamic Coalition on the Internet of Things (DC-IoT) has produced a document that outlines guidelines for “ethical” IOT applications, including meaningful transparency, user-control of data collected by the application, and so on.
Also, in the Geneva Internet Platform’s report, they asked IGF-longtimer Markus Kummer if he thinks the IGF being ‘just a talking-shop’ is really a weakness. I thought Markus’s answer was spot on:
This is one of the reasons why some governments don’t come here; they feel it is not serious enough, it is not some place we negotiate. But this is precisely the strength of the IGF – the absence of pressure to negotiate outcomes allows people to speak freely and also to think a bit outside the box, to do some brainstorming, and then go home and actually try to implement the ideas.
Key Topics at the 2016 IGF
Connecting the next billions of people remains as a key focus in many of the discussions. This is obviously very important, but we were also glad to see many references to more complex goals, such as ensuring the openness of the Internet; quality and not just quantity is important. And lets not forget that connecting all the people will not be the end of our efforts. Think of how much, say, agriculture or traffic would benefit of the optimisations that Internet communications can bring. This is true of both the developing and developed world.
The Internet of Things was also a key issue in many sessions, with a lot of focus on how it can be sufficiently secured. While Internet of Things as a technology in its own right, it also seen as an enabler for sustainable development, education, and helping the “global south” catch up.
Free and open source software is also considered as another enabler for the global south. Open source can help the poor use the tools they need, without having to afford additional expenses. It also allows auditing to protect people’s rights and information. A concern was raised from the floor of the meeting that big companies don’t care about open source. It’s important that the IETF continues putting our efforts into connecting with open source projects and supporting development of free and open source software (Hackathon, encouraging open-source implementations as we develop protocols, etc). And contrary to the concern perhaps, we think that is likely inline with what small and big businesses also want us to do.
The growing digital divide was referenced many times. While a lot of progress has been made in enabling more and more people to use the Internet, at the same time the divide is also growing. Think of the elderly who may be falling behind on the ability to use new technology, and are being shut out of many functions of the society that have moved online. Or the poor who cannot afford connectivity, which in turn may lead to the even worse outcomes due to more difficult access to commercial services, job markets, etc.
There was also discussion of big data, with suitable anonymisation and privacy protection, to assist governments and other actors in providing services, being aware of important trends, and the like – but data must be timely, relevant, and local.
Other topics of high interest included gender and diversity, freedom of expression, education, and legal matters.
The thinking sparked by these discussions will continue throughout the coming year at local and regional IGF gatherings. And, IGF 2017 will be held in Geneva, Switzerland on 18-21 December.
Jari Arkko, Andrew Sullivan, Ted Hardie, and Barry Leiba
Photos: The IOT Dynamic Coalition meeting with Max Senges speaking with Joe Alhadeff, Vint Cerf, Maarten Botterman and Avri Doria in the background (photo by Jari Arkko), Larry Strickling speaking at the IGF Opening Session (photo by Jari Arkko), and your IETF and IAB chairs hard at work on the in-the-meeting-compound Tequila farm (photo by Ted Hardie).
This report is sent out before IETF-97 begins, in an effort to reduce reporting at the plenary and to provide an ability to discuss topics on list beforehand and afterwards. The plan is to provide only a brief summary in the in-person presentation at the plenary.
If you have topics that you think the IESG should, or should already have, discussed, please send email to email@example.com with details and we’ll get back to you.
Jari Arkko, IETF Chair
This report covers
notable things about IETF 97, and our technical program
IANA stewardship transition
proposed IASA 2.0 project
what our professional standards of behaviour are
how to see what the IESG does
working groups created, rechartered, proposed, or closed after IETF 96
a note on new non-WG mailing lists
pointers to ongoing discussions on general process or IESG procedure issues
currently running (non-technical) experiments
In addition, there are several other reports elsewhere:
The meeting and pre-events are running from Saturday November 12 to Friday, November 18th. 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.
IETF Code Sprint is running on Saturday, please join and program the IETF tools that *you* need. See Code Sprint web page.
Thursday speaker series, Thursday Lunch slot in Park Ballroom 1: We will hear from Andrew G. Malis on “Quasi Assured Network Transport (QUANT)”. See the talk page.
Female and at the IETF-97? Join the IETF Systers, see the blog article and the invitation from Allison Mankin.
As usual, there are also a number of events around the IETF. This time I will mention two:
The IEPG discusses operational issues on their Sunday meeting.
The OPNFV meetup, taking place on Friday, November 11. But OPNF folks are also participating throughout the week, for instance in the Hackathon and the Bits-n-Bites.
Sponsor: Our meeting host is Huawei. Thank you! Other hosts and sponsors include KISA, CNNIC, Google, Nokia, OSI Hardware, ISOC Korea Chapter, NTT Communications, Comcast, ETRI, Netpia, OPNFV, Korea Tourism Organisation, Seoul Metropolitan Government, and the Hackathon sponsor for 2016 is Huawei Developer Zone. The Hackathon is also supported by Cisco DevNet.
THE TECHNICAL PROGRAM
But now on to our actual technical program! Some of the highlights have been listed in the Welcome to IETF-97 blog article and some of the proposed new work in the New Work in Seoul blog article.
Note in particular the technical plenary program which focuses on distributed denial-of-service attacks against the Internet architecture. See the article for more details.
IANA STEWARDSHIP TRANSITION
The transition was executed on September 30, 2016 as planned by the various communities. The relevant contracts have come into effect, including the new SLA between the IETF and ICANN, and the role of the IETF Trust as holding IPR related to IANA. The domain name parts of this IPR are being technically transferred and the arrangements are being setup with appropriate providers.
PROPOSED IASA 2.0 PROJECT
The arrangements relating to administrative support for the IETF (IASA, RFC 4071) were created more than ten years ago, when the IETF initially took charge of its own administration. The arrangements have served the IETF well, but there’s been considerable change in the necessary tasks, in the world around us, and our own expectations since the creation of the IASA. Looking forward, this is a good time to ask what administrative arrangements best support the IETF in the next ten years.
The IETF Chair is planning to start a project to assess those arrangements. Included in this project are the various challenges and frustrations* we’ve experienced along the way, but we also need to ask the bigger questions about how the organisations are structured. The project should assess what kind of support we need in the coming years, from the point of view of the community, IESG, IAB, IAOC, Trust, and partners (such as ISOC, long-term hosts or contractors). Areas to look at include structure, financing & sponsorship arrangements, organisation, and ways of working.
This project is to be done to serve the IETF community, hence the final determination of results and actions will rest on the community. Obviously there is a role for the IAOC & Trust in particular to provide direction in what they see is appropriate. And likewise for the the IESG and IAB in their respective roles, or ISOC for discussion of the relationship and arrangements with IETF. But I feel that the IETF chair needs to own the project and be responsible for ensuring that the community views are what finally determines the actions.
At this point, the project is a proposal, and the chair is soliciting feedback on the overall plan. We will be working to create specific mailing lists for the substantial discussion later, but for setting up the project the proper place for discussion is probably here at firstname.lastname@example.org.
(*) Some of these issues have been prominently visible in the IETF community, such as the discussions about early community involvement in making meeting site decisions. Others are internal to IASA operations, such as workload due to increasing IETF responsibilities. There are also structural question marks, such as the way that we select people to serve as board members, or the partial separation between the IAOC and the Trust.
For more information, see the proposal and participate in the discussion on the mailing list.
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 97: 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.
FINDING OUT WHAT THE IESG DOES
The IESG continues to work on increasing transparency. We’d welcome feedback on what aspects need improvement. 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. If you are interested in the upcoming agenda, it can be seen at https://datatracker.ietf.org/iesg/agenda and the invitiation is mailed out to the IETF main discussion list. The calendar and connection details can also be found at the IESG page. And of course, the best place to follow what is going on with a document is the datatracker. Of course, the relevant actions such as significant comments from the IESG continue to be automatically emailed to the relevant WG mailing list.
The IAB and IESG also hold a BOF coordination call before each IETF meeting. In this call, we go through the set of proposed BOFs and other possible new meetings, in an effort to help the responsible AD decide how the specific proposals should go ahead. Since IETF 96, the IESG and IAB have started publishing the minutes from these calls. These minutes can be found from the IESG page. The October 2016 call minutes for instance are at here.
NEW WORKING GROUPS
The following changes have happened after IETF 96:
Approved: SIDROPS, L2SM, QUIC, SECEVENT, IPWAVE, and LPWAN. Note that SIDROPS, L2SM, and SECEVENT were chartered after community e-mail discussion but no preceding BOF. Not all new efforts go or need to go through the BOF stage, and it can often be the recommended approach if the relevance of the topic and broad interest for it can be demonstrated in other ways.
New non-wg mailing lists: DLNEX hosts a discussion of reliable and deterministic latency attributes, ledger discusses interledger, originally a protocol stack for moving digital assets between accounts operating on different payment networks or ledgers, ideas has discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks, dnsoverhttp hosts a discussion of running DNS over HTTP, rtg-open-source discusses routing-related open source efforts, and art is an area-wide discussion list for the Applications and Real-Time Area.
STATEMENTS AND NOTABLE DOCUMENTS
The IESG has decided to make a small modification of the IPR-related web pages to be even clearer about the role of the statements submitted as IPR declarations. This decision was based on feedback on earlier suggestion of issuing an IESG statement on the matter. Once the modification is in place, we will inform the community of the change.
The IESG is currently working on a statement regarding the role of supporting documentation (use cases, requirements, etc.) in a working group. The IESG wants to emphasize the importance of chartering solution work immediately and reducing focus on supporting documents; represents how the IESG has been focused for a while now and is an effort to speed up WGs producing solutions that have an effect in the way that people build and test networks.
These (non-technical) experiments are running at this time:
The ietf main discussion list facilitator arrangements was an experiment, and its results are now under evaluation. See the experiment announcement. The main question is whether the facilitators (who were quite active) made a significant positive impact. Based on this the experiment should be either turned to an ongoing effort or ended. There is a mailing list thread on the IETF main discussion list about this topic.
A number of IETF Hubs are going on – in South America, in India (Bangalore) and Boston.
The IESG is encouraging WG Chairs to try and use different meeting formats than “present and listen”. The WG Chairs’ training session will be discussing this among other things in Seoul.
Several working groups are using github as a platform for specification development, markdown to write drafts.
In general, the IESG would like to encourage experimenting and trying new things. If you have ideas about potentially useful things to try, try them and tell the rest of us!
There have been no appeals since IETF-96. 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 for IETF-96, but have pushed the launch to happen before IETF-98, due to integration to the rest of the IETF system taking more time than expected. The team is also following up with more detail on exactly how the community feedback will be incorporated along the way before calling the project complete.
The website to document coding projects based on IETF specifications has been renamed to CodeStand due to conflict with other uses of an earlier name. The new site is: https://codestand.ietf.org. We’re looking for volunteers willing to create “Code Requests” for their specifications, and feedback can be sent to email@example.com.
The IESG is considering what to do about email lists policies regarding DMARC, and its effect on people’s ability to send and receive list email. Some of us will meet during the Seoul IETF meeting and try to come up with the least worst Mailman change based on previously discussed suggestions. Any suggested configuration change will be advertised on the IETF mailing list first. Please stay tuned.