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 email@example.com.
(*) 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.
Rechartered: IPSECME and SACM.
Proposed WGs, BOFs, or otherwise under consideration (outcomes undecided before community has had sufficient discussion, of course): DNSBUNDLED and BANANA.
Closed: IANAPLAN, LAGER, ABFAB, and JOSE.
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 artis 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 firstname.lastname@example.org.
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.