Call for More Tools Volunteers and Contractors

wordle

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 [1] and sign up [2].

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 [3], 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

[1] Code Sprint IETF 98 Chicago https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF98Sprint
[2] Code Sprint IETF 98 Sign-Up Page https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF98SprintSignUp
[3] RFPs for Tools Development https://iaoc.ietf.org/rfps.html

New Ideas for IETF-98?

chicagobofs-medium

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.

Jari Arkko, IETF Chair

Photo credits: WikimediamindfriezeCC BY-SA 2.0

Reflections from IETF 97

iloveseoul

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:

The Hackathon demos can be viewed in YouTube:

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:

Jari Arkko, IETF Chair

Photo credits: Tero Kivinen, Charles Eckel, Olivier Bonaventure, and unknown. Thanks!

Internet Governance Forum (IGF) 2016

dciot

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.

There are other reports from this meeting, including the official transcripts and videos, Multistakeholder Advisory Group (MAG) Chair’s summary (Lynn St. Amour became the MAG Chair in 2016) article, Constance Bommelaer de Leusse’s (ISOC) article “Reflections on a successful IGF 2016”, Samantha Dickinson’s article “Despite Renewal, the Internet Governance Forum Is Still on Life Support”, and the Geneva Internet Platform’s excellent report “Reflecting on IGF 2016”.

General

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.

larry

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.

co-operation

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.

Best regards,

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).

Seoul Reflections

Reflections on the Routing Area after IETF 97

When we pause to reflect on what happened during an IETF meeting, it’s always encouraging to realize how much got done and how many excellent discussions happened. Of course, part of that reflection is writing down all the Action Items that each of us has managed to accumulate. We’d like to share with you some of the highlights.

As the WG responsible for maintaining BGP, IDR is well-known for requiring two implementations before requesting that an internet-draft be published. That might make one think that IDR is always slow to advance work – but the recent experience with BGP Large Communities reminds us that what has drafts progress quickly is the amount of interest and work put into it. While BGP Large Communities is a small feature, it is very critical for operators who need to use 4-octet Autonomous System Numbers in their policy. This Internet-Draft went from individual on July 5 to WG adopted on Sept 23 to WG Last Call done on Nov 3; it is currently in IETF Last Call and on the Jan 5, 2017 IESG telechat. It took less than 4 months for IDR to be ready to progress it – and there was plenty of discussion!

good_jobSIDR was originally chartered to develop standards to secure inter-domain routing: origin and path validation. Origin validation is being deployed in pockets around the world, with most notable advances in the LACNIC and RIPE regions.  rpki-dashboardThe BGPsec specification for path validation is scheduled for the Jan 5 IESG Telechat.  The WG has now completed its objectives and will be closed once the publication process is completed to the outstanding work.  Because we are now in a deployment phase, the SIDROPS WG has been chartered in the OPS area.

In the last year, NVO3 has had limited technical discussion beyond discussing different encapsulations. Before IETF 97, NVO3 created a dataplane encapsulation design team with the consensus of creating a single encapsulation to progress as Standards Track. At IETF 97, Matthew Bocci, Sam Aldrin, and Alia decided to make use of the IETF 97 face time to strongly encourage smaller group discussion. Picture of people in discussion in front of projected slide of group discussion topics. With the help of three facilitators for each discussion and large pads of paper, the first NVO3 meeting broke up into 3 discussion groups – on OAM, Control Plane, and Data Plane in 3 corners of the room. Each group had around 15 people with a number actively contributing and others focusing and learning. The facilitators summarized their discussions for the second NVO3 meeting the next day; there weren’t missing viewpoints and there was additional discussion. Not only were the small group discussions useful, the energy level and interaction in the room noticeably increased in the second meeting. It really helps to know exactly which other people are extremely interested in the same detailed topic. As discussed in the WG Chairs Forum at IETF97, the IESG is encouraging WG Chairs to experiment more with making better use of face time. This was one such successful experiment.

YANG continues to be a focus in the Routing Area and many of our YANG models (BGP, OSPF, IS-IS) are nearing completion. RFC 8022, the base model for Routing Configuration, is a key dependency that is now completed. At IETF97, TEAS, MPLS, CCAMP, and PCE had another joint meeting to discuss the YANG models for RSVP-TE, Traffic-Engineering, LDP and mLDP, TE Topology, PCEP and others. This is an example of how multiple WGs can collaborate to make sure that the models reflect operators’ perspective rather than the specific protocols or IETF Working Group structure. ietf-network-dependencies I2RS has finished with the models for Network Topology and for Layer 3 Topologies and is awaiting implementations for the RIB model. RTGWG has completed WGLC on the Routing Key Chain model; RTGWG is discussing adopting draft-rtgyangdt-rtgwg-routing-types-00 to provide common types for the models.

Large Fat-Tree Topologydata-centers have interesting routing problems. RFC 7938 provides information on a way to use BGP in a CLOS data-center network. There continues to be different efforts to better handle routing in data-centers based on significant changes to existing protocols. RTGWG will have cal-jan-2017a virtual interim on January 25 to discuss the specific problems of data-center routing. We are hopeful that the discussion will help clarify reasonable paths forward and would strongly encourage those able to describe the current operational issues to participate.

During its interim, BIER reached an agreement to make a generic encapsulation based on the existing MPLS and proposed Ethernet encapsulation. BIER Encapsulation + non-MPLS HeaderThese changes were discussed during the meeting and – as often happens – the technical concerns raised led to a side-conversation that had time for the technical depth to resolve the concerns. BIER continues to discuss ideas around an IPv6 encapsulation and brought the discussion to 6man; the possible use-case of using an IPv6 encapsulation to help in IoT was also discussed. Extensions to Babel to support BIER were discussed in BIER and brought to the babel WG; extensions are a bit different for Babel and an initial implementation is being encouraged to explore the idea. It is interesting to see a possible expansion of BIER to handle the multicast requirements in homenet.

As announced on rtg-open-source@ietf.org, we had another open meeting to discuss and facilitate the interaction of Open Source projects with the IETF Routing Area. Interactions between the IETF and other organizations work well when there are overlapping participants who understand the different communities. We continue to be interested in ways to encourage interactions and mutual understanding of the different maturity levels that projects and different internet-drafts & RFCs provide. CodeStand is a recent website to connect up, among others, open source development communities and link work to standards.

Aactn-hackathont the IETF 97 Hackathon, the ACTN (Abstraction and Control of Traffic Engineered Networks) team won the best input to a Working Group Award!

CCAMP has kicked off a new design team on Transport NBI modelling. The work will coordinate with TEAS.

We all know that IETF work is constant.  As ADs, we enjoy seeing documents approved for publication and technologies progress to Internet Standard.  good_jobPALS has progressed RFC4447bis “Pseudowire Setup and Maintenance using the Label Distribution Protocol” to the RFC Editor as their first full Internet Standard!  MPLS has a revised RFC4379bis “Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures”.  PCE has been working on stateful PCE.  “Applicability of a Stateful Path Computation Element (PCE)” is the first of the related documents to reach the RFC Editor queue.  TEAS completed a “Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks” (RFC7926).

The MANET WG has reached an important milestone in the development of protocols for the rapidly changing mobile ad-hoc networks with the soon-to-be-published specification for DLEP (Dynamic Link Exchange Protocol).  The exchange of dynamic information between a router and associated modem/radio is critical to optimize routing decisions.  DLEP has applicability in both military and commercial networks.

Of course, we could easily go through all 25 WGs in the Routing Area, but these are a few of the highlights. We encourage you to check out the others and tell us what we should have mentioned!

Regards,

Alia, Alvaro & Deborah (Routing ADs)

YANG Quick Status Update Before this IETF 97

Let me start with some good news. Not only we recently approved RESTCONF (right now in the RFC editor queue), but we published the IPv4 and IPv6 base routing models in RFC 8022. We all learned a lot during the long process of specifying those routing YANG models and understand many things way better now. RFC 8022 is central for standardizing many other routing YANG models, as you can see from this picture from the brand new visual dependency tool developed by Joe Clarke this week-end during the IETF Hackathon.

capture-yang-dependency

If you are excited to explore YANG models dependencies using this tool, give it a try with the YANG modules you’re most impatient to see done.

So what are the hot topics for this IETF 97? We continue to add flexibility to support finalization of modeling work.

First the schema mount draft, which specifies a mechanism to combine YANG modules into the schema defined in other YANG modules, is an essential building block that should be standardized soon. Many YANG modules depend on this schema mount solution.

Second, the Revised Conceptual Model for YANG Datastores draft will receive a lot of attention during this week. It focuses on a revised conceptual model of datastores based on the experience gained with the current model and addresses requirements that were not well supported in the initial model. Basically, it introduces new datastores, for accessing additional views of the intended configuration, and a new ability to obtain the operational state.

Third, focusing on finishing up key YANG models, such as key chain, key store, topologies, key routing ones (OSPF, ISIS, PIM, BGP), access-list, logical network elements, etc. The routing base models follow the config and config-state branch conventions for specifying, respectively the configuration and operational data. Models being submitted for publication request should follow this same convention. We know that operators are moving to data modeling-driven management, and waiting for standard models.

As mentioned during the last IETF meeting in Berlin, it’s important to publish the IETF YANG models within a reasonable time frame, if the IETF wants to play a key role in specifying YANG models, as opposed to only standardizing the protocols (NETCONF/RESTCONF and related push mechanisms) and related encodings (JSON, XML). As I mentioned in Berlin 3 months ago, we have maximum a year to publish the majority of those IETF YANG models. It’s time to focus and deliver.

More on the Hackathon outcomes later after the IETF, but I can already tell that this Hackathon brought new tools and implementations. This is essential as your automation is as good as your tools chain.

After the IETF 97, I plan on updating this blog with the latest achievements.

Regards, Benoit (OPS Area Director)

IESG and Chair Report, IETF-97

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 iesg@ietf.org with details and we’ll get back to you.

Jari Arkko, IETF Chair

THE REPORT

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
  • appeals
  • other matters

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.

IETF 97 AND NOTABLE ACTIVITIES

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.

Thanks, all!

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 ietf@ietf.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.

PROFESSIONAL BEHAVIOUR

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 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.

RUNNING EXPERIMENTS

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!

APPEALS

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

OTHER

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 codestand-develop@ietf.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.

Welcome to IETF-97!

seoul-han-river-yeoido-bridge-01

IETF-97 is starting in a couple of days in Seoul, Korea, as well as running online for many participants connecting over the Internet. Either way, I hope to see you in the meeting! Agenda, registration, and remote attendance instruction can all be found from the IETF-97 meeting page.

There are more than a hundred meetings during the week on different topics, but I wanted to highlight a few ones that I think are significant or particularly interesting.

  • The topic erschrecklichewasserfluth of the technical plenary in the 97th IETF meeting will be “Attacks Against the Architecture”, a discussion about large-scale denial-of-service attacks involving Internet of Things devices and how the attacks leverage the Internet architecture. We will also talk about possible ways to think about solutions. Read more about this topic from the blog post.
  • The QUIC working group has just been chartered, and will meet for the first time in Seoul. This working group is taking Google’s pre-standardization QUIC protocol that has been deployed in production for several years, quicpic2 and will use it as a starting point to develop a UDP-based, stream-multiplexing, encrypted transport protocol with standardized congestion control, TLS 1.3 by default, a mapping for HTTP/2 semantics over QUIC, and multipath extensions. This is a significant development, because it changes the traditional layering from TCP, TLS, and HTTP to a more closely integrated transport functionality.
  • The TLS WG meets on Tuesday and Friday. The group has started working group last call on TLS1.3. It’ll be an extended and two part last call so we can get the WG participant feedback handled and then leave some time for the cryptographers to check that nothing bad’s happened since they last looked at a draft version. That “planned hold” has been on the cards since the start of the work. Expected end of the last call is in January and then all going well IETF last call.
  • In the Routing Area, YANG work is of high interest. A Joint YANG session among four Working Groups (CCAMP, MPLS, PCE, and TEAS) will be held on Monday to coordinate the work. Topics will include TE topology models, MPLS, PCE, Microwave Radio Link, and Transport.
  • IPWAVE is a new working group, focusing on communications in vehicular networks. For further information, bsb_04_2008_412_ets see the agenda. They are meeting on Wednesday.
  • LPWAN is a new working group that is focused on running internet protocols on a Low Power Wide Area Networks. See the agenda. They are meeting on Monday.

There are also a number of Birds-of-Feather or BOF meetings, focusing on the question of whether new work is needed on some topic:

  • DNSBUNDLED will be having a non-WG forming BOF on Wednesday. It is concerned with mapping and maintaining one DNS domain and all of its underlying name structure into another domain. For instance, being able to map the same labels across TLDs, such as example.com to example.net. The agenda for this BOF is here.
  • BANdwidth Aggregation for interNet Access (BANANA) will banana be having a non-WG forming BOF on Thursday. BANANA is concerned with providing coordinated Internet Access to a device over multiple links of different types to allow for increased bandwidth utilization, load-balancing and/or higher reliability. The goal of this BoF is to come up with a shared understanding of the problems that the IETF would like to solve in this space, complementing on and in collaboration with work ongoing in the MPTCP working group and the Broadband Forum. The group’s agenda is here.

For more information on these and other new proposals, there’s more information in the new work blog article.

Jari Arkko, IETF Chair

Photo credits: Seoul bridge Wikimedia (d’n’c – http://www.flickr.com/photos/fukagawa/195944150/), Burchardi flood Wikimedia (Contemporary picture), QUIC IETF (Jana Iyengar), road traffic controls Wikimedia (Mariordo Mario Roberto Duran Ortiz), and Multipath TCP Wikimedia (Aclarembeau).

Proposed Project: IETF Administrative Support 2.0

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.

I am 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 I am soliciting feedback on the overall plan. Would be happy to revise per feedback. 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 ietf@ietf.org.

Here are stages of the project that I see:

Stage 1: Background documentation

  • -documenting the evolution of the IASA system implementation from 2005 to 2016 (an initial version in draft-daigle-iasa-retrospective)
  • sharing this background information with the community for review & update

Stage 2: Collecting input on challenges and requirements

  • understanding the situation from the IAOC internal perspective
  • understanding the situation from the IAB and IESG perspective
  • discussion in the community about the challenges and changed requirements
  • discussion with ISOC about the challenges and changed requirements
  • discussion with the long term hosts about the challenges and changed requirements
  • discussion with contractors about the challenges and changed requirements
  • the collection effort is facilitated by a design team (it is to be determined if the same team or different teams will be used in stages 2-4)
  • setting up a new working group for the discussions is also necessary
  • IAOC/IESG/IAB assistance will also be needed in the facilitation and discussion

Stage 3: Analysis and documentation

  • collect acquired information
  • discuss in the community
  • the analysis effort is again to be facilitated by a design team

Stage 4: Proposed improvements

  • suggest improvements that would address the key challenges
  • initial proposals created with the help of a design team, the results to be discussed in the community

Stage 5: Discussion of the improvements

  • community discussion

Stage 6: Specification and execution

  • specify the changes in RFCs, agreements
  • execute the changes

I have not yet assigned timelines for the stages, but the idea is to start the project in 2016 and use the winter and spring 2017 for the discussions, main results to be put in place sometime in 2017.

Jari Arkko, IETF Chair

(*) 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.

Attacks Against the Architecture

erschrecklichewasserfluth

The scale, complexity, and potential harm of Denial-of-Service attacks involving the use of compromised or misconfigured nodes or “things” is increasing. Across multiple services and activities, the network seems to be unable to defend itself effectively against large-scale bad behavior. Why is this? Can something be done about it? Who should act?

In many cases the attacks are facilitated by very poor security practices on the devices, and improvements in that area are sorely needed. However, even with such improvement it seems important to improve the ability to defend the network against such attacks.

Enormous effort is being brought to bear on this issue, which has aspects ranging from the characteristics of specific internet protocols and services, through operations, public policy, and economics. But there are also some basic technical questions that are worth discussing: is the Internet architecture enabling compromised end nodes to wreak havoc on the network? Does it suggest anything about how to defend the network better? Is there a particular role for the IETF?

The topic of the technical plenary in the 97th IETF meeting will be “Attacks Against the Architecture”, a discussion about large-scale attacks, how they leverage the internet architecture, and possible ways to think about solutions.

Join us for the discussion in the IETF technical plenary on Wednesday, November 16, 16:40-19:10. The meeting will be held in Seoul, South Korea, but there are also remote participation tools available. To register for the meeting, click here.

Andrew Sullivan, IAB Chair
Suzanne Woolf, IAB Member
Jari Arkko, IETF Chair

Graphic: A flood that hit Germany and Denmark in 1634, source: wikipedia.