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

New Work in Seoul

seoul_at_night

A month before the meeting our steering group collects proposals for new working groups. We decide which ones are ready enough for the community to discuss the proposals in the meeting. We did this last week, and I wanted to report what new meetings will be held.

There are also a number of new working groups that have had their community consideration earlier, and are being considered to be created, or were recently created. I will also mention some of these working groups.

Here are the new meetings:

  • 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, 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 the IETF’s first standardized always-encrypted transport protocol, so careful consideration of applicability and operational capabilities will be key for success.
  • DNSBUNDLED will be having a non-WG forming BOF in Seoul. The responsible AD is Terry Manderson, with Andrew Sullivan as the IAB Shepherd. DNSBUNDLED is concerned with a problem statement of mapping and maintaining one DNS domain and all of its underlying name structure into another domain. The following related use cases have been proposed: 1) map across TLDs such as example.com to example.net; 2) map different label within a TLD, i.e example1.com to example2.com; 3) map different labels across different TLDs, for instance example1.com to eaxmple2.net, and lastly 4) where multiple domains map to one domain such as example.com, example.net, example.org all map to example.gTLD. The mailing list for this BOF is here and one of the Internet Drafts on this topic is here.
  • BANdwidth Aggregation for interNet Access (BANANA) will be having a non-WG forming BOF in Seoul. 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 mailing list is here.
  • IPWAVE is a new working group, focusing on communications in vehicular networks. Vehicles are increasingly connected to the Internet. Comfort-enhancing entertainment applications, road safety applications using bidirectional data flows, and connected automated driving are some of the few new features expected in this area. This group will work on use-cases where IP is well-suited as a networking technology and will develop an IPv6 based solution to establish direct and secure connectivity between a vehicle and other vehicles or stationary systems.
  • LPWAN is a new working group that is focused on running internet protocols on a Low Power Wide Area Networks. There are several very diverse LPWA lower layer technologies such as NB-IoT, SIGFOX, LoRa, and WI-SUN. and The goal of this working group is to converge these radio technologies towards a common hour glass model, with a highly compressed form of IPv6 and CoAP between the end-device and the network gateway. This will enable the creation of common mechanisms for management of the gateway and for providing secure, Internet-based services to the applications.
  • L2SM is a proposed working group, currently under consideration. It is intended as a short-lived WG, tasked to create a YANG data model that describes a L2VPN service (a L2VPN service model) that can be used for communication between customers and network operators, and to provide input to automated control and configuration applications. The working group will attempt to derive a single data model that includes support for point-to-point Virtual Private Wire Services (VPWS) and multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624.
  • SECEVENT is a new working group. The group works on a mechanism to convey messages between systems in order to prevent or mitigate security risks, or to provide out-of-band information as necessary.
  • SIDROPS is another new working group currently under consideration to be created. This group discusses operational experiences around the global deployment of RPKI, Origin Validation of BGP announcements and BGPSEC, collectively called SIDR. This technology helps protect the Internet routing infrastructure against various kinds of attacks.

Join our meeting to discuss these and many other interesting topics! If you haven’t registered yet, you can do so on the IETF-97 web page.

Jari Arkko, IETF Chair

Photo credits: By travel oriented – Flickr, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=41839161

IANA Stewardship Transition Goes Ahead

wordle14

Today marks the execution of the contracts and arrangements relating to the IANA stewardship transition. The US government has ended their role in this matter. I am happy about the transition, and happy that it is happening as specified by the IETF and other communities. For me, the key issue is that the communities are in charge.

A large number of people have worked hard in the communities to make this day possible. Thank you for your efforts!

This is a good day — but also in many ways just like previous days. It is what we are already doing. The Internet will continue to work as it has before. The communities continue to work with the IANA system to make sure it responds to the needs of the users, as we have. Networks and people co-operate, voluntarily, so that they can connect over the Internet. Just like what the world has been doing since the dawn of the Internet.

chairs600

green600

I asked Andrew Sullivan, IAB Chair, what he thinks. He said: “Like many things on the Internet, this is the result of many incremental steps by many people. It is incremental change that brings us the stability of the Internet.”

And I also asked Alissa Cooper, Chair of the IANA stewardship transition Coordination Group (ICG). She said: “We rarely get the opportunity to witness a global consensus as broad and diverse as the one in favor of this transition. Hundreds of people and organizations from across sectors and across the world had the courage and endurance to see this process through, and as a result the Internet is running as smoothly today as it did yesterday.”

I agree with them. This is business as usual: we will continue to be a part of the IANA system, and feel responsible for ensuring that it stays healthy and responds to community needs.

Jari Arkko, IETF Chair

Photo and graphics credits: www.wordle.net and Alain Durand

BOFs for IETF-97

Downtown skyline of Seoul, South Korea with Seoul Tower.

I wanted to remind you that we are soliciting proposals for new work at the IETF. If you have an idea, this would be a good time to bring it up!

The cut-off date for new working group proposals — we call them “Birds of a Feather” or BOFs — is September 30, in two weeks.

Please talk to your Area Directors about your ideas!

If you are considering submitting a new idea, please read RFC 5434: Considerations for Having a Successful Birds-of-a-Feather Session and BOF Procedures.

All the IETF-97-related dates and deadlines can be found here. You can register at the meeting here.

Jari Arkko, IETF Chair

Working with the IEEE 802

mtg

Standards organisations have their areas of work, but for many topics efforts affect multiple organisations, or even span across multiple organisations. Take the IETF and the IEEE for instance, as our efforts often interact. From the IETF perspective, the most relevant IEEE standards group is the IEEE 802 LAN/MAN Standards Committee. It develops and maintains networking standards and recommended practices for local, metropolitan, and other area networks.

IETF and IEEE 802 leadership and liaison managers are in contact regularly, and every couple of years we also meet in person to better understand what work is happening on the other side, and make sure we stay coordinated. Last week, we held our fourth such meeting, continuing our tradition of meeting in outskirts of large airports in nondescript hotels :-) this time outside Charles-de-Gaulle airport in Paris.

But the surroundings don’t matter as much as the substance. Also, both organisations are very clear that the best way to collaborate is to make sure that there are joint participants who work through topics that are important for them, in both organisations. This collaboration cannot be done through the management chain, people actually doing the standards and implementing them have to be the ones in the driver’s seat.

However, light coordination is useful to understand what things are coming down the pipeline, understand the official situation on some topic, and so on. For this purpose, we’ve defined ways of working together in RFC 7241, we’ve set up a team for the coordination, have a mailing list (https://www.ietf.org/mailman/listinfo/ieee-ietf-coord), and hold monthly conference calls and meet at the IETFs. We also have official liaisons in place, as part of inter-organisation coordination being an official activity of the IAB. If you have any topic that needs the attention of the coordination team, please contact Dan and Pat for further information.

In our meeting last week, we talked about a number of interesting topics:

  • Internet of Things standardisation efforts. iot There are many joint or connected efforts here, for instance those relating to various 802.15.4 needs, such as the IETF 6TISCH WG. It was also interesting to learn that IEEE 802 is working on a couple of projects that deal with the local administration of MAC addresses, and has developed new cabling and Ethernet standards for low-speed, low cost/energy consumption markets. One example of these projects is the 10Mbit/s specification for Ethernet over a single twisted pair cable. More information IOT-related projects at IEEE can be found here.
  • Both organisations are pursuing better privacy in the Internet and networks connected to it. For instance, IEEE has worked on MAC privacy, which was also tested in IETF meeting networks, and both organisations are keen on continuing with further improvements.
  • Ongoing efforts in both the IETF and IEEE 802 to develop “deterministic” networking standards. For more information, see the related activities in IEEE 802 and the IETF DETNET WG.
  • We also noted upcoming work on future technologies, such as 5G, and discussed the role of IEEE and IETF in these efforts. We agreed to collaborate when any joint work would be needed.

The minutes of the Paris meeting are available here.

Jari Arkko, Chair, IETF
Dan Romascanu, IETF liaison to IEEE SA
Pat Thaler, Vice Chair, IEEE 802
Suresh Krishnan, Internet Area Director, IETF

CodeSprints, Hackathons, and Interops in Seoul

sprint

The essence of the IETF is not that we write specs for some other people to implement. It is that we are a place for people who write code to write specs as well. With that in mind, a big part of our work is allowing 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 these events also at IETF-97 which will take place in Seoul, South Korea, November 12-18, 2016. More specifically:

  • The CodeSprint runs on Saturday, November 12, and more information is available from the wiki. You can sign up here. The CodeSprint is open to all who want to help.
  • hack The IETF Hackathon runs from Saturday, November 12 to Sunday, November 13. Read more about it here, follow the mailing list, and sign up here. The Hackathon is free to attend and open to the public.
  • The IETF Bits-n-Bites event, Thursday November 17, will let people demonstrate what they are working on. See more here, and sign up to sponsor a demo table! The whole IETF community in Seoul will be joining you to eat, drink, socialise, and see your demos.

And remember that what you do at these events is up to you. You decide. You decide what is the coolest tech thing that you need to implement. You decide what IETF data tracker feature you need for your work. bnb

So don’t be afraid to add your own project, gather a team, and come join us and take your ideas further!

I would also like to offer IETF-97 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. Sometimes that testing is just informal, something you do in the hallways or around the terminal room table. In other cases it is more organised.

etsi Let us know if you are planning to do some testing. In some cases we can also help with rooms, network support, and help publicise your event to other participants. In any case, testing is immensely helpful for the Internet, and we’d be happy for you to work on that!

Jari Arkko, IETF Chair