Loa Anderson (IAB Liaison to the IESG)
Gonzalo Camarillo
Stuart Cheshire
Russ Housley (IETF Chair)
Olaf Kolkman (IAB Chair)
Gregory Lebovitz
Barry Leiba
Kurtis Lindqvist
Danny McPherson
David Oran
Dow Street (IAB Executive Director)
Dave Thaler
Mark Townsley (for IPv6 / Firewall discussion)
Lars Eggert (IESG Liaison to the IAB)
Aaron Falk (IRTF Chair)
Sandy Ginoza (RFC Editor Liaison)
Andy Malis
Lynn St. Amour (ISOC Liaison)
Lixia Zhang
Loa reported on the recent efforts of the JWT in documenting the
current agreement between the IETF and ITU-T. All the important
information describing the agreement is captured in a set of
slides, which represent the normative reference agreed to by both
parties. However, the team has been unable to translate this
information into ASCII text suitable for submission to the RFC
Editor. As it stands there are two independent versions: a
normative PDF, and an ASCII text version that provides introductory
information, but is lacking key details of the agreement.
At present, PDF versions of RFCs cannot serve as the normative
reference. Russ asked the IAB, in its series oversight role, to be
prepared to set this new precedent. It was stated that there is no
feasible way to capture the relevant information in ASCII text,
since it was the slides themselves that constitute the agreement.
Barry expressed support for setting this precedent, and Russ agreed
that doing so might break some ground.
Dave Thaler asked why it was necessary to publish the agreement as
an RFC. Loa replied that this is a landmark agreement with another
SDO that needs to be documented in an archival fashion, and that
the ITU-T does not have its own archival format. Olaf asked which
stream the document would take, suggesting it might be best to set
the smallest precedent possible. Russ felt that it needed to be an
IETF stream document document since it establishes an agreement
between the IETF and an outside organization. Dave Thaler and Olaf
expressed additional hesitation, noting that if any other
alternatives within the existing framework are feasible, that those
would be preferred. Loa responded that they had tried hard to come
up with an alternative approach, but were unsuccessful.
There was further discussion about (a) the advantages of ASCII text
over PDF as the standard archival format, (b) non-RFC publication
options (e.g., liaison statement), and (c) how any new precedent
might be limited. Dow asked for clarification that this precedent
would make normative PDFs permissible, but not required; Russ
concurred. Loa added that the precedent could be limited to only
those situations involving two different organizations that do not
have a common file format. Russ also noted that the precedent
would not apply to protocols or standards track documents, only to
inter-organizational agreements. Barry stated that he would rather
the application not be so narrow, to which Russ suggested a
step-by-step approach toward larger changes.
Several board members expressed concern over how these ‘limits’ to
the precedent would play out if pushed against by authors who
simply prefer PDF over ASCII. Despite potential ambiguity in this
area, and acknowledging the stated concerns, the board agreed to
support the publication of a normative PDF and informational ASCII
document. Russ and Loa will work with the IESG to move the
documents forward.
The meeting then moved to the techchat topic of IPv6 and Firewalls.
This was a long technical discussion with several partially
overlapping topics, including the value proposition of firewalls,
IPv6 deployment considerations, and the role of NATs. Stuart
introduced the topic, and has been trying to coalesce IAB dialogue
in this area into one or more document outlines.
The group considered the relationship of NAT, router, and firewall
functions, and how one might describe the competing goals of
enabling and limited access and/or communication. Key to this
deconstruction seems to be the concept of an ‘authorized user’,
for whom communication is enabled, while traffic of unauthorized
users is prevented. However, there also seems to be an implicit
tussle among numerous parties that complicates the determination
of what is authorized. End users may have different goals than the
administrators of their local network, who may in turn have
different goals than their upstream provider, or even the remote
endpoints in other networks with which the local host is
communicating.
Dow raised the example of increased deployment of IPsec, which can
be used for authenticating users, but is commonly viewed by network
administrators as problematic when it obscures the activities of
local hosts. Gregory described how in their network IPsec is
permitted only if the session transits an admin-managed proxy
device. Stuart stated that Apple allows basically all traffic
*except* IPsec. Mark added that Cisco has devices that send
traffic that is in fact encrypted, but does not look like IPsec.
Dave Thaler observed that you cannot stop the arms race in code;
you have to rely on other mechanisms, such as external policy.
There was some agreement that many of the problems come down to
differing positions on what constitutes acceptable use, but that
this determination is being made implicitly and indirectly in a
manner that involves multiple parties and mechanisms. Returning to
IPv6, the current landscape threatens to erode many of the benefits
of IPv6 deployment. Stuart used the example of a mobile user who
is connected at a coffee shop and desires to print a document to
his or her home printer. It is not that such functionality is
merely unavailable today, but that users are not even generally
aware that this type of connectivity is a possibility. It has been
lost inadvertently without the user realizing what was possible.
IPv6 provides an opportunity to restore certain end-to-end
functionality, but it is quickly being eroded.
One possible path forward is to draft a taxonomy of connectivity
categories, but doing so will be tricky if a debate on network
neutrality is to be avoided. A few summary points that were made:
– end-to-end connectivity is getting worse due to NATs, security
gateways, business models, etc
– many of the issues are about more about policy tussles than
mechanisms.
– it is helpful to consider the functionality of NATs, firewalls,
routers separately, though to a degree they reside on spectrum
of functions involved in enabling or denying access.
– there is a window of opportunity with IPv6, before it becomes
encumbered in the same way as IPv4.
Stuart will attempt to draft a document outline based on today’s
discussion.