But now on to our actual technical program! Here are
some of the highlights:
LEDGER BOF (ART): This proposal relates to the popular topic of using
cryptographic ledgers to track assets. Bitcoin does this with
currency, but the technology could support other types of
applications. However, moving digital assets between accounts
operating on different payment networks or ledgers is not possible
today in an open, inter-operable way. LEDGER wants to discuss a
protocol stack for such transfers. See this internet
draft as an example.
QUIC BOF (TSV): QUIC is a UDP-based transport protocol that provides
multiplexed streams over an encrypted transport, originally from
Google and with plenty of deployment experience. This BoF proposes a
working group to standardize a new transport protocol based on
experience with QUIC. Obviously, transport services underneath the web
have the potential for having a big impact in Internet traffic. An
early version of a charter for a possible working group is here.
As a side, this is one of the highly interesting three BOFs on the
transport area this time. A few years ago there was relatively little
new work on the area, but now the area's proposals seem highly
topic and interesting for the Internet. A nice development!
LPWAN BOF: This BoF focuses on low-power wide-area networks. Typical
LPWAN networks provide low-rate connectivity to large numbers of
battery-powered devices over distances that may span tens of
miles. Would these networks benefit from Internet technology, and if
so, how? Currently many of these networks are not based on IP, as
discussed in the gap
analysis internet draft.
PLUS BOF: This group's acronym comes from "Path Layer UDP Substrate". The
group's goal is to enable the deployment of new, encrypted transport
protocols, while providing a transport-independent method to signal
flow semantics under transport and application control. The proponents
expect to implement a shim layer based on the User Datagram
Protocol (UDP). This provides compatibility with existing middleboxes
in the Internet as well as ubiquitous support in endpoints, and
provides for userspace implementation. Note that this effort follows
from the SPUD BoF in Dallas and the SPUD prototyping effort. See the list.
L4S BOF (TSV): The proponents of this BOF are working on transport mechanisms for
achieving both low latency and low loss, while accommodating scalable
throughput. Early tests indicated that L4S can keep average queuing
delay under a millisecond for all applications, even when together
they add up to a heavy load, while keeping congestion loss minimal and
utilisation high. The BOF will discuss whether improvements of this
nature can be achieved in the greater Internet, and if standards are
needed. See the list.
ITS BOF (INT): This BoF focuses on Intelligent Transportation
Systems. The goal of this group is to standardize and/or profile IP
protocols for establishing direct and secure connectivity between
moving networks. Draft charter can be found here.
LURK BOF (SEC): This group, Limited Use of Remote Keys (LURK) focuses on
using a large-scale CDN to provide access to a web site that employs
HTTPS. Ideally, such distribution should be possible without having to
copy the private keys associated with the web site to too many
places. The list is here.
IMTG BOF (GEN): We've had a long debate about our meeting locations
next year. The MTGVENUE working group (details below) was created to
discuss the requirements for our meeting sites. In addition, we've
added the IMTG session in the agenda to talk about international
meeting arrangements and other issues from the point of view of human
rights, and to get some advice from experts outside the IETF in these
topics. See the agenda.
MTGVENUE WG (GEN): This new working group will discuss criteria and policies
related to the selecting of IETF meeting venues. Many initial drafts
can be found from the WG
page, and draft-baker-mtgvenue-iaoc-venue-selection is one of the key documents.
DISPATCH WG (ART): This working group will discuss, among other things,
the Glass to Glass Internet Ecosystem (GGIE) topic that looks at video
and streamed content from a system perspective. Streamed content
delivery could be viewed like a composed flow combining many parts,
with playback composed of one or more component streams from one or
more addresses to one or more devices over one or more networks. An
initial draft is draft-deen-daigle-ggie.
ICNRG (IRTF): Information Centric Networking (ICN) has been a popular
research topic. Several variants exist, but the basic idea is a new
type of Internet architecture based on requesting and receiving data
identified by name, rather than sending to and receiving from an
address. There is interest in bringing some of this work to a state
where it could be more widely used and experimented with. Should the
IETF produce RFCs on this topic? The ICN
Research Group will be talking about the state of this work, and
what parts are ready to progress further.
BABEL WG (RTG): This working
group will document the Babel routing protocol. This protocol is
used among other things in home networking environments.
LAMPS WG (SEC): This group plans to publish some updates to PKIX and S/MIME technologies, in
cases where real deployment and real need can be
identified. Currently, the group plans to look at ways to include an
i18n email address as a subject alternative name and the use of
authenticated encryption in S/MIME.
SIPBRANDY WG (ART): This working group's acronym
comes, obviously, from SIP Best-practice Recommendations Against
Network Dangers to privacY. The group focuses on end-to-end protection
mechanisms for real-time communications environments, in an effort to
avoid man-in-the-middle attacks and privacy violations.
Read more of these efforts in their respective mailing lists,
agendas, and BOF descriptions, or from this blog