[Chapter-delegates] Follow up "Rough Guide" to IETF75
Sabrina Wilmot
wilmot at isoc.org
Thu Oct 15 07:30:29 PDT 2009
Dear Colleagues,
Leslie Daigle and her team have produced a follow up "rough guide" to
the hot topics for the 75th IETF. Please see below.
Big thanks to Leslie and her team for producing this.
Best regards,
Sabrina Wilmot
ISOC
PS: And don't forget to download or order the latest edition of the IETF
Journal: https://www.isoc.org/isoc/reports/order/index.php
8<--------------------------------------------------->8
Here is the follow up to the meetings we had highlighted at IETF75. As
this circulates, the final preparations are underway for IETF76, in
Hiroshima, November 8-13, 2009. The draft agenda for that meeting is
already available: http://www.ietf.org/meeting/76/
Be sure to consult it to identify working group sessions that meet your
own interests. All working group sessions will support remote
participation, if you are unable to participate in person.
A Follow-Up to the Rough Guide to ISOC's IETF75 Hot Topics
==========================================================
In line with our own priorities at the Internet Society, we selected
working groups, BoFs, plenaries, and other events at IETF 75 in the
following broad categories:
- Common and Open Internet
- Global Addressing
- Security and Stability
- Trust and identity
--------------------------
Common and Open Internet
--------------------------
As P2P and VoIP technologies become more prevalent, and network usage
patterns sometimes deviate from their architects' expectations, managing
bandwidth to allow best use for customers becomes an increasingly
important topic.
alto (Application-Layer Traffic Optimization)
---------------------------------------------
The alto WG is chartered to design and specify a service that will
provide P2P applications with information to perform better-than-random
initial peer selection. This service may take different approaches at
balancing factors such as maximum bandwidth, minimum cross-domain
traffic, lowest cost to the user, and others.
Full charter: http://www.ietf.org/html.charters/alto-charter.html
Outcomes:
o Problem Statement has gone through WG Last Call
o Discussion continues on the Requirements document
o Lots of ongoing discussion on the ALTO protocol document, to
continue on the mailing list Minutes:
http://www.ietf.org/proceedings/75/minutes/alto.html
ledbat (Low Extra Delay Background Transport)
---------------------------------------------
As mentioned in previous rough guides, ledbat is chartered to produce a
congestion control algorithm that simultaneously saturates the
bottleneck link in an end-to-end path, maintains low delay, and (most
importantly) yields to standard TCP. Such a congestion control
algorithm, if used by bandwidth-intensive applications (such as P2P data
transfer applications), would enable the simultaneous use of real-time
communication applications (such as voice-over-IP) without noticeable
problems.
Full charter: http://www.ietf.org/html.charters/ledbat-charter.html
o LEDBAT protocol reached consensus (no opposition) for adoption as
a WG document. Consensus to be verified on the mailing list.
o LEDBAT Practices and Recommendations document needs an active
editor and more work. Not yet ready for adoption as a WG work item.
o Consensus to adopt LEDBAT survey document (no opposition) as a WG
work item. To be verified on the list.
Minutes: http://www.ietf.org/proceedings/75/minutes/ledbat.txt
MPTCP (Multipath TCP) BOF
-------------------------
Multipath TCP is a proposed new IETF activity to add the capability to
use multiple connection paths in a single TCP connection. The
availability of multiple connection paths and the capability to
dynamically schedule traffic between them allows more flexibility and
efficiency in Internet congestion control, in addition to other
benefits.
o Overwhelming majority in favour of forming a working group
o Second BoF expected for IETF 76.
Minutes: http://www.ietf.org/proceedings/75/minutes/mptcp.txt
--------------------------
Global Addressing
--------------------------
There is steadily increasing momentum to deploy IPv6 as the IPv4 address
pool approaches depletion. While much work is ongoing to support
interoperability in coexisting IPv4 and IPv6 network environments, there
are also interesting developments in emerging IPv6 environments.
6lowpan (IPv6 over Low power WPAN)
----------------------------------
The 6lowpan WG deals with the use of IPv6 over low powered networks
(such as sensornets). This is protocol development for devices on "the
Internet of Things". The basic concept in 6lowpan is that IP may become
a unifying layer for low powered devices for interoperability,
potentially over the Internet. 6lowpan is intensely focused on
developing the protocols to enable this to happen.
Full charter: http://www.ietf.org/html.charters/6lowpan-charter.html
- Most documents progressing
- There was discussion of doing a working group last call on routing
requirements and JP Vasseur raised the objection to mesh under routing
which he believes is more of a layer 2 technique and should be be
reserved for IEEE standardization and is not appropriate in the IETF.
Since the meeting there has been a last call on the doc and JP has
raised this objection in email.
Minutes: http://www.ietf.org/proceedings/75/minutes/6lowpan.txt
6man (IPv6 maintenance)
-----------------------
This WG is home for discussions of improvement and maintenance of the
IPv6 protocol suite.
Full charter: http://www.ietf.org/html.charters/6man-charter.html
o Lots of pushback on Broadband Forum initiated work items to
include Line Identification options in either Router Solicitation or
Neighbour Solicitation messages.
o IPv6 Address Text Representation supported for adoption as a WG
document
o IPv6 Address Selection Policy Considerations supported for
adoption as a WG document
Minutes: http://www.ietf.org/proceedings/75/minutes/6man.html
behave (Behavior Engineering for Hindrance Avoidance)
-----------------------------------------------------
While behave was chartered to create mechanisms for transiting NATs in
reliable ways, most of its activity is now focused on protocol
translation from IPv4 to IPv6 in a number of different scenarios. Of
particular interest in these scenarios is how the proposed mechanisms
deal with DNS operation across the two protocol realms (and whether it
is possible to maintain any kind of reasonable operation of secure DNS
in such a scenario).
Full charter: http://www.ietf.org/html.charters/behave-charter.html
- There is a greater sense of urgency to make progress on the 6 to 4
translation docs, especially those related to transition scenarios
involving NATs for IPv6 to IPv4; hence the working group is having
monthly webex interim meetings
- Some progress is being made on a lot of documents, most focus
seems to be on IPv6 hosts being able to reach IPv4 networks
Minutes: http://www.ietf.org/proceedings/75/minutes/behave.txt
Minutes of behave interim meeting in May:
http://www.ietf.org/proceedings/75/minutes/ibehave.txt
First Webex behave interim meeting was held in August but no minutes
have been posted.
The next Webex interim meeting will be held: Thurs Oct 21.
Information on those can be found here:
http://trac.tools.ietf.org/wg/behave/trac/wiki
softwire (Softwires)
--------------------
The softwires WG looks at discovery, control, and encapsulation methods
for connecting IPv4 networks across IPv6-only networks and IPv6 networks
across IPv4-only networks in a way that will encourage multiple,
inter-operable vendor implementations.
Full charter: http://www.ietf.org/dyn/wg/charter/softwire-charter.html
One important outcome was apparent agreement that there is a need for a
standalone document that deals with the issues raised by address
sharing. The various solution proposals in both softwires and behave WGs
could then reference that document.
Minutes:
http://www.ietf.org/mail-archive/web/softwires/current/msg00847.html
v6ops (IPv6 Operations)
-----------------------
The v6ops WG exists to discuss operational issues in deployment of IPv6.
Full charter: http://www.ietf.org/html.charters/v6ops-charter.html
- Interesting presentation on the current operation of v6 tunneling
in the network and its harmful
effects:http://tools.ietf.org/html/draft-vandevelde-v6ops-harmful-tunnels-00
- IPv6 requirements for CPE devices used the whole second session.
This is clearly gaining some momentum from an operator perspective who
need these kinds of devices to turn on subscriber IPv6 connectivity at
home for many subs.
Minutes: no minutes received
Transport Area Open Meeting
o Dan Wing's work to standardise an algorithm for doing parallel
overlapping http connections, with intelligently staggered start times
looks likely to proceed in the Transport Area.
o This should improve application behaviour as IPv6 deployment
gathers pace
Minutes: http://www.ietf.org/proceedings/75/minutes/tsvarea.txt
--------------------------
Security and Stability
--------------------------
Securing the DNS and greater assurance in routing is critical for the
ongoing expansion and evolution of the Internet in all areas of our
societies and economies.
dnsext (DNS Extensions)
-----------------------
This working group is involved in developing a wide range of functional
extensions to the DNS. dnsext also tracks the DNS implications of the
behave WG.
Full charter: http://www.ietf.org/dyn/wg/charter/dnsext-charter.html
The outcome of multi-meeting discussion of security proposals other
than DNSSEC was that the WG chairs will appoint editors for a combined
document, which might include descriptions of why some proposals are
bad ideas. Michael Graff was named as editor of a draft to revise
EDNS0 (RFC 2671) in the light of operational problems with DNSSEC
enabled for unworkable buffer sizes. Extensive discussion of new
DNSSEC algorithms and registering their identifiers led to a promise
by Paul Hoffman to submit a draft to focus discussion.
Minutes: http://www.ietf.org/proceedings/75/minutes/dnsext.txt
DNSOP (Domain Name System Operations)
-------------------------------------
The dnsop WG works on various operational aspects of the Domain Name
System.
Full charter: http://www.ietf.org/dyn/wg/charter/dnsop-charter.html
The highlights were discussions of two drafts. Wouter Wijngaards
described a trust history proposal which would enable a DNSSEC
validator that was unable to keep up with changed key-signing keys
(KSKs) to traverse enough history of previously valid KSKs to recover
valid trust anchor state. Jason Livingood described the way that DNS
redirection is now used and some recommendations to avoid the most
serious problems.
Minutes: http://www.ietf.org/proceedings/75/agenda/dnsop.txt
sidr (Secure Inter-Domain Routing)
----------------------------------
The sidr WG working group is chartered to formulate an extensible
architecture for an inter-domain routing security framework.
Full charter: http://www.ietf.org/dyn/wg/charter/sidr-charter.html
Matt Lepinski summarized changes in the ROA format and RPKI
architecture drafts based on input from the WG. Terry Manderson took
advice on a draft beginning to document use cases for RPKI. While
these and other drafts demonstrate reasonable progress on details, the
most significant contribution was Steve Kent's Local Trust Anchor
Management, which described how each relying party can import, modify
and certify ROAs reflecting different views of the address space for
itself.
Minutes: http://www.ietf.org/proceedings/75/minutes/sidr.txt
savi (Source Address Validation Improvements)
---------------------------------------------
The savi WG is chartered to design methods for IP source address
validation that complement ingress filtering with finer-grained
protection.
Full charter: http://www.ietf.org/dyn/wg/charter/savi-charter.html
Discussion of several drafts on the SAVI model and goals still leave
open whether exiting solutions are adequate. There was also discussion
of Control Plane Snooping (CPS) as a proposed approach.
Minutes: http://www.ietf.org/proceedings/75/minutes/savi.txt
--------------------------
Trust and identity
--------------------------
As public concerns increase about security of infrastructure, privacy,
trust, and identity on the Internet, these themes recur in several
working group discussions.
ogpx (Open Grid Protocol) BoF
-----------------------------
This BoF is proposing a WG to provide an application-layer wire protocol
for virtual worlds to enable interoperability between applications,
provide for access and exchange with other systems on the internet, and
allow network layers to recognize VW traffic and make routing decisions
based on its characteristics. It's of particular interest to ISOC's
Trust and Identity work because of the proposed use of TLS and OAuth for
origin authentication.
The OGPX meeting has well attended, participants were interested
in pursuing the work and those in Stockholm likes the focus of the
proposed Charter.
There was also a high degree of over-lap between the OGPX
participants and the OAuth Breakfast BoF meeting.
Since Stockholm, the Charter has had extensive discussion on the
mailing list (https://www.ietf.org/mailman/listinfo/ogpx) and the
group is considering yet another name change (Virtual Worlds Region
Agent Protocol (VWRAP)).
Minutes: http://www.ietf.org/proceedings/75/minutes/ogpx.txt
oauth (Open Authentication Protocol)
------------------------------------
OAuth allows a user to grant a third-party Web site or application
access to their resources, without necessarily revealing their
credentials, or even their identity.
Full charter: http://www.ietf.org/dyn/wg/charter/oauth-charter.html
The breakfast BoF in Stockholm covered a wide range of topics
(http://www.ietf.org/mail-archive/web/oauth/current/msg00240.html)
including the use of OAuth for delegation and authentication, non-http
uses for OAuth, channel-bindings, and WG process issues.
Current list discussion includes one topic of particular note,
"Reevaluating Assumptions", which was initiated by Eran Hammer-Lahav
(a principle author) and is still generating interest. The original
base specification document,
http://tools.ietf.org/html/draft-hammer-oauth-03 , went to Working Group
last call on October 8, 2009. This document is proposed as an
Informational RFC.
dkim (Domain Keys Identified Mail)
----------------------------------
The DKIM working group will produce standards-track specifications that
allow a domain to take responsibility, using digital signatures, for
having taken part in the transmission of an email message and to publish
"policy" information about how it applies those signatures.
Full charter: http://www.ietf.org/dyn/wg/charter/dkim-charter.html
Current list discussion is focused on a proposed re-chartering:
http://mipassoc.org/pipermail/ietf-dkim/2009q3/012526.html
and there is one active document, draft-ietf-dkim-deployment-08,
which has had only minor revisions since IETF 75.
The DKIM working group will not be meeting at IETF 76 in
Hiroshima.
Minutes:http://tools.ietf.org/wg/dkim/minutes?item=minutes75.html
Leslie Daigle
Chief Internet Technology Officer
Internet Society
daigle at isoc.org
More information about the Chapter-delegates
mailing list