Monthly Archives: July 2017

IETF 99 Preview

Prague Main Train Station

Prague Main Train Station

IETF 99 is about to kick off in Prague, Czech Republic. There is lots of exciting work going on across more than 100 working groups, plus Birds-of-a-Feather (BoF) sessions, plenary talks, and other meetings. Here are a few sessions to keep an eye out for:

Pre-meeting events

We have close to 200 participants signed up for the Hackathon taking place Saturday and Sunday. Around two dozen teams will be collaborating on code projects spanning the breadth of IETF protocols, from security to DNS to transports to IoT and more.

Folks are invited as always to join the Code Sprint on Saturday to work on tools for the IETF community — please join!

Sunday afternoon’s tutorial sessions will include two new technical tutorials. The TEEP tutorial will explain Trusted Execution Environments (TEE) and their associated protocol needs. The IEEE 802.1 Time-Sensitive Networking (TSN) tutorial with explain the TSN group’s work on transport of data packets with bounded low latency, low delay variation and zero congestion loss, closely related to the IETF’s Deterministic Networking working group.

While not an IETF event, the Applied Networking Research Workshop, put on by ACM, the IRTF, and ISOC, is taking place on Saturday. The workshop will provide a venue for discussing emerging results in applied networking research related to measurements, transport, implementation and operational issues, and internet health metrics. (Registration required.)

Meeting events

Those interested in 5G may want to attend the NETSLICING BoF, which is looking at isolation of resources and virtual network functions to support a variety of services. There will also be a plenary lunch time panel on Tuesday about 3GPP and IETF collaboration on 5G in Congress Hall III.

Other BoFs during the week: BANANA, focused on developing solution(s) to support dynamic path selection on a per-packet basis in networks that have more than one point of attachment to the Internet; IDEAS, which is aiming to standardize a framework that provides identity-based services that can be used by any identifier-location separation protocol; and IASA 2.0 where the community discussion about administrative re-arrangements for the IETF continues. Also in the realm of new work proposals, the IPPM working group will be discussing a charter update to allow the WG to take on work related to in-situ OAM.

We continue to see high interest in ongoing work related to data modeling, QUIC, and security. Catch the OPSAWG session for some discussion about managing the development and use of YANG models and the joint CCAMP/MPLS/PCE/TEAS session focused exclusively on YANG models, among other sessions. The QUIC WG will meet jointly with the HTTPBIS working group to discuss interaction between QUIC and HTTP, in addition to two meeting slots on its own. In the security area, both the TLS and ACME working groups are close to finalizing several core deliverables, and the SAAG meeting will feature a talk on post-quantum crypto.

Thank you

We wouldn’t be able to hold IETF meetings without the support of our sponsors. Big thanks to IETF 99 hosts Comcast NBCUniversal and CZ.NIC! And to all of our sponsors for the meeting.

Comcast NBCUniversal logo

Comcast NBCUniversal

CZ.nic logo

CZ.nic

Wishing everyone a productive and enjoyable meeting!

Seeking community feedback on revamp of www.ietf.org

There has been a lot of progress on the project to revamp of the www.ietf.org website. The updated website will be the “front door” for the IETF, not only for for active IETF participants, but also provides an onramp for potential participants, and helps explain the work of the IETF to people who are not directly involved in developing Internet standards. The complete Scope of Work for the project is available here.

Based on recent feedback, including the demo table at IETF 98, the initial design and features of the website have been improved in many ways. For example, in response to the feedback provided, there is now a single page that provides links to tools and resources commonly used by active IETF participants.

The project is now entering the next phase of the website development. The goal for this phase is to gather input more broadly. While there are still a few features to be implemented and some content still needs to be fine tuned, the general organization and the look-and-feel of the website has been implemented based on the initial research and input received to date. Of course, there will be some additional significant work before the site is ready for production; for example, before the website is final, we will implement methods to ensure that well-known URLs continue to work as expected.

The site is now accessible at https://beta.ietf.org

Please take a look. We will be tracking issues that need addressing using Github

Feedback can also be emailed directly to webmaster@ietf.org.

At IETF 99 in Prague, there will be a table near meeting registration to demonstrate the beta website with “office hours” posted on a sign by the table. Please stop by if you are in Prague!

Thanks,
Russ Housley
IETF Website Revamp Project Manager

At Long Last, A Revised Patent Policy for IETF: What’s Behind BCP79bis?

Working on technical standards in the computing, communications and networking industries often involves dealing with patents. Like most standards-development organizations (SDOs), the IETF has policies that deal with patents covering IETF protocols, specifications and standards.  The IETF’s first patent policy appeared in RFC 1310 (Mar, 1992), but the basis for today’s policy approach originated with RFC 2026 (October 1996), which still defines many aspects of the Internet Standards Process.  The first major overhaul of this policy occurred a decade later in RFC 3979 (also designated as BCP 79).  Though the IETF’s policies relating to copyrights, open source code and other forms of intellectual property (IPR) evolved, particularly after the formation of the IETF Trust in December 2005, the IETF’s patent policy remained relatively stable for more than 20 years.

As stated in RFC 2026, the overall intention of these policies has been to benefit the Internet community and the public at large, while respecting the legitimate rights of others, and that remains the case today.

As originally codified in RFC 2026, the IETF patent policy states that anyone who makes a contribution to an IETF specification or standard must disclose any patents held by the contributor or his/her employer which cover or may cover the contribution and are “reasonably and personally known” to the contributor, as well as any such patents that cover contributions of others.  If an IETF participant knows of third party patents covering some aspect of an IETF document, disclosure is voluntary.  Unlike many SDOs, the IETF does not require that patent holders make any particular commitment to license their patents on fair, reasonable and non-discriminatory (FRAND) or any other terms (a discussion of the history behind this approach can be found here).  However, the IETF provides a facility (the IPR Disclosure Form) whereby patent holders can voluntarily disclose their licensing terms, and many make use of this facility to declare, for example, that they will not assert patents against implementations of IETF standards except in defensive situations.

In 2010, following a period of extensive discussion of IPR policies in the industry and at other SDOs, and with the completion of a major overhaul of the IETF copyright policy in 2008 (RFC 5378/BCP78), we began to consider updating BCP 79 to reflect current practices at the IETF, as well as the evolving roles of the RFC Editor, IETF Secretariat, IETF Executive Director, IRTF, IAB and other groups operating within IETF.

This was not a quick process.  We began work in 2010 and held a first BOF at IETF 81 in Quebec City (July 2011).  We published a -00 version of a revised policy in December 2012 and held a second BOF at IETF 87 in Berlin (July 2013). We received comments and input from a wide range of community members, legal counsel and interested parties.  The Internet-Draft went through 13 versions and was finally published as RFC 8179 in May 2017, seven years after we began to work on it.

The principal changes that RFC 8179 introduced to BCP 79 are described in Section 13 of the document.  A quick summary of the highlights is below:

What’s a Contribution to the IETF?  — Over the years, the modes in which IETF work takes place have changed.  We updated BPC 79 to reflect the reality that technical contributions are made in BOFs, and online via chat rooms and other online fora.  In addition, we have clarified the rules regarding oral contributions and when they trigger a requirement to disclose patents.

What is Participation in the IETF? – Many of the obligations imposed by BCP 79 apply to persons who “participate” in IETF standardization activities.  So what does “participate” mean?  Does it include walking into a meeting room where a discussion is taking place, sitting in the back saying nothing, or silently “lurking” on an email list? In BCP 79bis, we clarify that participation in the IETF means either making a contribution or “in any other way acting in order to influence the outcome of a discussion relating to the IETF Standards Process”.  Thus, silently rolling your eyes or giving a thumb’s down during a technical presentation could subject you to the IETF’s disclosure requirements.

What to Disclose? – In addition to information regarding a patent and the portion(s) of an IETF document that it covers, the inventor(s) must now be disclosed.

Updating Disclosures – We have added a lot of needed detail around the process for updating IPR disclosures, including when such updates are required and how they should be made.

Licensing Declarations – When a person or company makes a voluntary statement about the terms on which it will license its patents covering IETF standards, that statement is viewed as binding and irrevocable so that others may rely on it.

General Disclosures – We updated the procedures relating to voluntary disclosures that are not required by the IETF rules.  These disclosures of patents potentially covering IETF documents can be made by anyone and will be posted on the IETF IPR Disclosure page.  We also clarified that required disclosures that are deficient in some way (e.g., they omit some required information) are also posted.

Failure to Disclose – We outline some of the remedial measures that can be taken when the IETF disclosure rules are violated, including IESG actions described in RFC 6701.

Evaluating Alternative Technologies – We provide some guidelines around the consideration of patent and licensing disclosures by IETF WGs.  We also discuss some areas in which royalty-free licensing is preferred, such as security technology.

Alternate Streams – We have made it easier for other groups using the IETF RFC publication process, such as the RFC Editor, IAB and IRTF, to adopt the IETF patent policy.

As you can see, the changes are mostly clarifications; the basic patent policy remains as it was defined in 1996.  Changes in patent law or patent practice may, at some point in the future, necessitate an update to RFC 8179, but that will be someone else’s task.

– Jorge L. Contreras and Scott O. Bradner