draft-iab-itat-report-02.txt   draft-iab-itat-report-03.txt 
Network Working Group E. Lear, Ed. Network Working Group E. Lear, Ed.
Internet-Draft April 17, 2014 Internet-Draft May 19, 2014
Intended status: Informational Intended status: Informational
Expires: October 19, 2014 Expires: November 20, 2014
Report from the IAB workshop on Internet Technology Adoption and Report from the IAB workshop on Internet Technology Adoption and
Transition (ITAT) Transition (ITAT)
draft-iab-itat-report-02 draft-iab-itat-report-03
Abstract Abstract
This document provides an overview of a workshop held by the Internet This document provides an overview of a workshop held by the Internet
Architecture Board (IAB) on Internet Technology Adoption and Architecture Board (IAB) on Internet Technology Adoption and
Transition (ITAT). The workshop was hosted by the University of Transition (ITAT). The workshop was hosted by the University of
Cambridge in Cambridge on December 4th and 5th of 2013. The goal of Cambridge in Cambridge on December 4th and 5th of 2013. The goal of
the workshop was to facilitate adoption of Internet protocols, the workshop was to facilitate adoption of Internet protocols,
through examination of a variety of economic models, with particular through examination of a variety of economic models, with particular
emphasis at the waist of the hourglass. This report summarizes emphasis at the waist of the hourglass. This report summarizes
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 19, 2014. This Internet-Draft will expire on November 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Organization of This Report . . . . . . . . . . . . . . . 4 1.1. Organization of This Report . . . . . . . . . . . . . . . 4
2. Motivations and Review of Existing Work . . . . . . . . . . . 4 2. Motivations and Review of Existing Work . . . . . . . . . . . 4
3. Economics of Protocol Adoption . . . . . . . . . . . . . . . 5 3. Economics of Protocol Adoption . . . . . . . . . . . . . . . 5
3.1. When can bundling help adoption of network 3.1. When can bundling help adoption of network
technologies or services? . . . . . . . . . . . . . . . . 5 technologies or services? . . . . . . . . . . . . . . . . 5
3.2. Internet Protocol Adoption: Learning from Bitcoin . . . . 6 3.2. Internet Protocol Adoption: Learning from Bitcoin . . . . 6
3.3. Long term strategy for a successful deployment of 3.3. Long term strategy for a successful deployment of
DNSSEC - on all levels . . . . . . . . . . . . . . . . . 7 DNSSEC - on all levels . . . . . . . . . . . . . . . . . 7
3.4. Framework for analyzing feasibility of Internet 3.4. Framework for analyzing feasibility of Internet
protocols . . . . . . . . . . . . . . . . . . . . . . . . 7 protocols . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Best Effort Service as a Deployment Success Factor . . . 8 3.5. Best Effort Service as a Deployment Success Factor . . . 8
4. Innovative / Out There Models . . . . . . . . . . . . . . . . 8 4. Innovative / Out There Models . . . . . . . . . . . . . . . . 8
4.1. On the Complexity of Designed Systems (and its effect 4.1. On the Complexity of Designed Systems (and its effect
on protocol deployment) . . . . . . . . . . . . . . . . . 8 on protocol deployment) . . . . . . . . . . . . . . . . . 8
4.2. Managing Diversity to Manage Technological 4.2. Managing Diversity to Manage Technological
Transition . . . . . . . . . . . . . . . . . . . . . . . 9 Transition . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. On Economic Models of Network Technology Adoption, 4.3. On Economic Models of Network Technology Adoption,
Design, and Viability . . . . . . . . . . . . . . . . . . 9 Design, and Viability . . . . . . . . . . . . . . . . . . 9
5. Making Standards Better . . . . . . . . . . . . . . . . . . . 9 5. Making Standards Better . . . . . . . . . . . . . . . . . . . 10
5.1. Standards: A love/hate relationship with patents . . . . 10 5.1. Standards: A love/hate relationship with patents . . . . 10
5.2. Bridge Networking Research and Internet 5.2. Bridge Networking Research and Internet
Standardization: Case Study on Mobile Traffic Standardization: Case Study on Mobile Traffic
Offloading and IPv6 Transition Technologies . . . . . . . 10 Offloading and IPv6 Transition Technologies . . . . . . . 10
5.3. An Internet Architecture for the Challenged . . . . . . . 10 5.3. An Internet Architecture for the Challenged . . . . . . . 11
6. Other Challenges and Approaches . . . . . . . . . . . . . . . 11 6. Other Challenges and Approaches . . . . . . . . . . . . . . . 11
6.1. Resilience of the commons: routing security . . . . . . . 11 6.1. Resilience of the commons: routing security . . . . . . . 11
6.2. Getting to the next version of TLS . . . . . . . . . . . 11 6.2. Getting to the next version of TLS . . . . . . . . . . . 12
7. Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Work for the IAB and the IETF . . . . . . . . . . . . . . 12 7.1. Work for the IAB and the IETF . . . . . . . . . . . . . . 12
7.2. Potential for the Internet Research Task Force . . . . . 12 7.2. Potential for the Internet Research Task Force . . . . . 12
7.3. Opportunities for others . . . . . . . . . . . . . . . . 12 7.3. Opportunities for others . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Attendees . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Informative References . . . . . . . . . . . . . . . . . . . 14 11. Informative References . . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Internet is a complex ecosystem that encompasses all aspects of The Internet is a complex ecosystem that encompasses all aspects of
society. At its heart is a protocol stack with an hourglass shape, society. At its heart is a protocol stack with an hourglass shape,
and IP at its center. Recent research points to possible and IP at its center. Recent research points to possible
explanations for the success of such a design and for the significant explanations for the success of such a design and for the significant
challenges that arise when trying to evolve or change its middle challenges that arise when trying to evolve or change its middle
section, e.g., as partially evident in the difficulties encountered section, e.g., as partially evident in the difficulties encountered
skipping to change at page 4, line 12 skipping to change at page 4, line 12
foothold to ultimately realize broad adoption. Such strategies must foothold to ultimately realize broad adoption. Such strategies must
be informed by both operational considerations and economic factors. be informed by both operational considerations and economic factors.
Participants in this workshop consisted of operators, researchers Participants in this workshop consisted of operators, researchers
from the fields of computer science and economics, as well as from the fields of computer science and economics, as well as
engineers. Contributions were wide ranging. As such, this report engineers. Contributions were wide ranging. As such, this report
makes few recommendations for the IETF to consider. makes few recommendations for the IETF to consider.
1.1. Organization of This Report 1.1. Organization of This Report
This report records the participants' discussions. At the end of the This report records the participants' discussions. At the end,
workshop reviewed potential follow-up items. These will be workshop reviewed potential follow-up items. These will be
highlighted at each point during the report, and a summary is given highlighted at each point during the report, and a summary is given
at the end. at the end.
Section 2 discusses the economics of protocol adoption. Section 3 Section 2 discusses the economics of protocol adoption. Section 3
delves into an examination of recent operational challenges and some delves into an examination of recent operational challenges and some
success stories. Section 4 examines different views of success success stories. Section 4 examines different views of success
factors. Finally section 5 summarizes views of the participants, and factors. Finally section 5 summarizes views of the participants, and
identifies a few key insights. identifies a few key insights.
skipping to change at page 6, line 16 skipping to change at page 6, line 16
protocols. It is relevant to the IETF and inherent to two key protocols. It is relevant to the IETF and inherent to two key
notions: layering and "mandatory to implement". Two current examples notions: layering and "mandatory to implement". Two current examples
include DANE atop DNSSEC and WebRTC atop SCTP. The workshop reviewed include DANE atop DNSSEC and WebRTC atop SCTP. The workshop reviewed
a model [Weber13] that examines the concept that bundling of a model [Weber13] that examines the concept that bundling of
technologies can lead to several possible outcomes, which includes technologies can lead to several possible outcomes, which includes
more or less adoption of both. This will depend on a number of more or less adoption of both. This will depend on a number of
factors, including the costs, benefits, and externalities associated factors, including the costs, benefits, and externalities associated
with adopting each. (Simply put, an externality is an effect or use with adopting each. (Simply put, an externality is an effect or use
decision by one set of parties that has either a positive or negative decision by one set of parties that has either a positive or negative
impact on others who did not have a choice or whose interests were impact on others who did not have a choice or whose interests were
not taken into account). Bundling of capabilities may provide not taken into account.) Bundling of capabilities may provide
positive value when individual capabilities on their own do not on positive value when individual capabilities on their own do not on
their own provide sufficient critical mass to propel further their own provide sufficient critical mass to propel further
adoption. The workshop considered involved two independent adoption. Specifically, bundling can help when one technology does
technologies, and presents and analyze four quandrants of not provide positive value until critical mass of deployment exists,
possibilities in terms of whether the bundling of two technologies and where a second technology has low adoption cost and immediate
would propel, retard, or not change the adoption rate of both. One value and hence drives initial adoption until enough of a user base
question was what happens where one technology depends on the other. exists to allow critical mass sufficient for the first technology to
That is directly tied to "mandatory to implement" discussions within get positive value. One question was what happens where one
the IETF. That is a matter for follow-on work. IETF participants technology depends on the other. That is directly tied to "mandatory
can provide researchers anecdotal experience to help improve models to implement" discussions within the IETF. That is a matter for
in this area. follow-on work. IETF participants can provide researchers anecdotal
experience to help improve models in this area.
3.2. Internet Protocol Adoption: Learning from Bitcoin 3.2. Internet Protocol Adoption: Learning from Bitcoin
The workshop considered an examination of protocol success factors in The workshop considered an examination of protocol success factors in
the context of Bitcoin[Bohme13]. Here, there were any number of the context of Bitcoin[Boehme13]. Here, there were any number of
barriers to success, including adverse press, legal uncertainties, barriers to success, including adverse press, legal uncertainties,
glitches and breaches, previous failed attempts, and speculative glitches and breaches, previous failed attempts, and speculative
attacks, amongst others. Bitcoin has thus far overcome these attacks, amongst others. Bitcoin has thus far overcome these
barriers thanks to several key factors: barriers thanks to several key factors:
o First, there is a built-in reward system for early adopters. o First, there is a built-in reward system for early adopters.
Participants are monetarily rewarded at an exponentially declining Participants are monetarily rewarded at an exponentially declining
rate. rate.
o There exist exchanges or conversion mechanisms to directly convert o There exist exchanges or conversion mechanisms to directly convert
bitcoin to other currencies. bitcoin to other currencies.
o Finally, there is some store of value in the currency itself, e.g, o Finally, there is some store of value in the currency itself, e.g,
people find intrinsic value in it. people find intrinsic value in it.
The first two of these factors may be transferrable to other The first two of these factors may be transferrable to other
approaches. One key protocol success factor is direct benefit to the approaches. One key protocol success factor is direct benefit to the
participant. Another key protocol success factor is ability to participant. Another key protocol success factor is the ability to
interface with other systems for mutual benefit. In the context of interface with other systems for mutual benefit. In the context of
Bitcoin there has to be a way to exchange the coins for other Bitcoin there has to be a way to exchange the coins for other
currencies. The Internet Email system had simpler adaption currencies. The Internet Email system had simpler adaption
mechanisms to allow interchange with non-Internet email systems, mechanisms to allow interchange with non-Internet email systems,
facilitating its success. Another more simply stated approach is "IP facilitating its success. Another more simply stated approach is "IP
over everything". over everything".
A key message from this presentation is that if a protocol imposes A key message from this presentation is that if a protocol imposes
externalities or costs on other systems, find a means to establish externalities or costs on other systems, find a means to establish
incentives for those other players for implementation. As it happens incentives for those other players for implementation. As it happens
there is a limited example of how to do this that is directly there is a limited example of how to do this that is directly
relevant to the IETF. relevant to the IETF.
3.3. Long term strategy for a successful deployment of DNSSEC - on all 3.3. Long term strategy for a successful deployment of DNSSEC - on all
levels levels
The workshop reviewed the approach Sweden's .SE registry has taken to The workshop reviewed the approach Sweden's .SE registry has taken to
improving deployment of DNSSEC[Lowinder13]. .SE has roughly 1.5 improving deployment of DNSSEC[Lowinder13]. .SE has roughly 1.5
million domains. IIS manages the ccTLD. They made the decision to million domains. IIS manages the ccTLD. They made the decision to
encourage deployment of DNSSEC within .SE. They began by encourage deployment of DNSSEC within .SE. They began by
understanding who their stakeholders were, and examined financial, understanding what the full ecosystem looked like, who their
legal, and technical aspects to deployment. As they began their stakeholders were, and examined financial, legal, and technical
rollout, they charged extra for DNSSEC. As they put it, this didn't aspects to deployment. As they began their rollout, they charged
work very well. extra for DNSSEC. As they put it, this didn't work very well.
They went on to fund development of OpenDNSSEC to remove technical They went on to fund development of OpenDNSSEC to remove technical
barriers to deployment at end sites, noting that tooling was lacking barriers to deployment at end sites, noting that tooling was lacking
in this area. Even with this development, more tooling is necessary, in this area. Even with this development, more tooling is necessary,
as they point out a need for APIs between the signing zone and the as they point out a need for APIs between the signing zone and the
registrar. registrar.
To further encourage deployment, the government of Sweden provided To further encourage deployment, the government of Sweden provided
financial incentives to communities to see that their domains were financial incentives to communities to see that their domains were
signed. .SE further provided an incentive to registrars to see that signed. .SE further provided an incentive to registrars to see that
skipping to change at page 10, line 12 skipping to change at page 10, line 20
There were several papers that focused on how standards are produced. There were several papers that focused on how standards are produced.
5.1. Standards: A love/hate relationship with patents 5.1. Standards: A love/hate relationship with patents
One of the biggest barriers to deployment is that of the unseen One of the biggest barriers to deployment is that of the unseen
patent by the non-practicing entity (NPE).[Lear13] While this problem patent by the non-practicing entity (NPE).[Lear13] While this problem
is relatively well understood by the industry, the discussion looked is relatively well understood by the industry, the discussion looked
at patents as a means to improve interoperability. Those who hold at patents as a means to improve interoperability. Those who hold
patents have the ability to license them in such a way that a single patents have the ability to license them in such a way that a single
approach towards standardization is the result (e.g, they get to approach towards standardization is the result (e.g., they get to
decide the venue for their work). decide the venue for their work).
5.2. Bridge Networking Research and Internet Standardization: Case 5.2. Bridge Networking Research and Internet Standardization: Case
Study on Mobile Traffic Offloading and IPv6 Transition Study on Mobile Traffic Offloading and IPv6 Transition
Technologies Technologies
There was a presentation and discussion about the gap between the There was a presentation and discussion about the gap between the
research community and standards organizations. Two cases were research community and standards organizations. Two cases were
examined: mobile offloading and IPv6 transition technologies.[Ding13] examined: mobile offloading and IPv6 transition technologies.[Ding13]
In the case of mobile offloading, a mechanism was examined that In the case of mobile offloading, a mechanism was examined that
skipping to change at page 10, line 44 skipping to change at page 11, line 10
The workshop discussed whether the standards arena is the best venue The workshop discussed whether the standards arena is the best venue
or measurement of success for researchers. The IRTF is meant to or measurement of success for researchers. The IRTF is meant to
bridge academic research and the IETF. As we will discuss below, bridge academic research and the IETF. As we will discuss below,
several avenues for continued dialog are contemplated. several avenues for continued dialog are contemplated.
5.3. An Internet Architecture for the Challenged 5.3. An Internet Architecture for the Challenged
The workshop engaged in a very provocative discussion about whether The workshop engaged in a very provocative discussion about whether
the existing Internet architecture serves the broadest set of needs. the existing Internet architecture serves the broadest set of needs.
Three specific aspects were examined: geographic, technical, and Three specific aspects were examined: geographic, technical, and
socio-economic. Researchers presented an alternative hourglass or socioeconomic. Researchers presented an alternative hourglass or
protocol architecture known as Lowest Common Denominator Networking protocol architecture known as Lowest Common Denominator Networking
(LCDNet) that re-examines some of the base assumptions of the (LCDNet) that re-examines some of the base assumptions of the
existing architecture, including its "always on" existing architecture, including its "always on"
nature.[Sathiaseelan13] nature.[Sathiaseelan13]
The workshop questioned many of the baseline assumptions of the The workshop questioned many of the baseline assumptions of the
researchers. In part this may have been due to constrained researchers. In part this may have been due to constrained
discussion time on the topic, where a fuller explanation was discussion time on the topic, where a fuller explanation was
warranted. warranted.
6. Other Challenges and Approaches 6. Other Challenges and Approaches
The workshop held a number of other discussions about different The workshop held a number of other discussions about different
approaches to technology adoption. We should highlight that a number approaches to technology adoption. We should highlight that a number
of papers were submitted to the workshop on routing security, two of of papers were submitted to the workshop on routing security, two of
skipping to change at page 11, line 39 skipping to change at page 12, line 8
What was notable in discussion was that there was no magic bullet to What was notable in discussion was that there was no magic bullet to
addressing the resiliency issue, and that this was a matter of addressing the resiliency issue, and that this was a matter of
clearly identifying the key players and convincing them that their clearly identifying the key players and convincing them that their
incentives were aligned. It also involved developing approaches to incentives were aligned. It also involved developing approaches to
measure resiliency. measure resiliency.
6.2. Getting to the next version of TLS 6.2. Getting to the next version of TLS
Originally the workshop had planned to look at the question of Originally the workshop had planned to look at the question of
whether we could mandate stronger security. This evolved into a whether the IETF could mandate stronger security. This evolved into
discussion about getting to the next version of Transport Layer a discussion about getting to the next version of Transport Layer
Security (TLS), and what challenges lie ahead. It was pointed out Security (TLS), and what challenges lie ahead. It was pointed out
that there were still many old versions of TLS in existence today, that there were still many old versions of TLS in existence today,
due to many old implementations. In particular, it was pointed out due to many old implementations. In particular, it was pointed out
that a substantial amount of traffic is still encrypted using triple that a substantial amount of traffic is still encrypted using triple
DES. DES.
One concern about the next generation is that perfect could become One concern about the next generation is that perfect could become
the enemy of good. Another point that was made was that perhaps a the enemy of good. Another point that was made was that perhaps a
testing platform might help interoperability. Finally, there was testing platform might help interoperability. Finally, there was
some discussion about how new versions of TLS get promoted. some discussion about how new versions of TLS get promoted.
skipping to change at page 13, line 47 skipping to change at page 14, line 16
Richard Clayton for arranging an excellent venue for our discussions. Richard Clayton for arranging an excellent venue for our discussions.
10. Attendees 10. Attendees
The following people attended the ITAT workshop: The following people attended the ITAT workshop:
Aaron Yi Ding, Adrian Farrel, Andrei Robachevzsky, Andrew Sullivan Aaron Yi Ding, Adrian Farrel, Andrei Robachevzsky, Andrew Sullivan
Arjuna Sathiaseelan, Bjoern Zeeb, Dave Meyer, Dave Thaler, Dongting Arjuna Sathiaseelan, Bjoern Zeeb, Dave Meyer, Dave Thaler, Dongting
Yu, Eliot Lear, Elwyn Davies, Erik Nordmark, Hannes Tschofenig, Joel Yu, Eliot Lear, Elwyn Davies, Erik Nordmark, Hannes Tschofenig, Joel
Halpern, Jon Crowcroft, Lars Eggert, Martin Stiemerling, Michael Halpern, Jon Crowcroft, Lars Eggert, Martin Stiemerling, Michael
Welzl, Michiel Leenaars, Miyo Kohno, Rainer Bohme, Richard Clayton, Welzl, Michiel Leenaars, Miya Kohno, Rainer Boehme, Richard Clayton,
Roch Guerin, Ross Anderson, Russ Housley, Sam Smith, Sean Turner, Roch Guerin, Ross Anderson, Russ Housley, Sam Smith, Sean Turner,
Soumya Sen, Spencer Dawkins, Steven Weber, Tapio Levae, Toby Soumya Sen, Spencer Dawkins, Steven Weber, Tapio Levae, Toby
Moncaster, Tony Finch Moncaster, Tony Finch
11. Informative References 11. Informative References
[Bohme13] Bohme, R., "Internet Protocol Adoption: Learning from [Boehme13]
Boehme, R., "Internet Protocol Adoption: Learning from
Bitcoin", December 2013. Bitcoin", December 2013.
[Ding13] Yi Ding, A., Korhonen, J., Savolainen, T., Kojo, M., [Ding13] Yi Ding, A., Korhonen, J., Savolainen, T., Kojo, M.,
Tarkoma, S., and J. Crowcroft, "Bridge Networking Research Tarkoma, S., and J. Crowcroft, "Bridge Networking Research
and Internet Standardization: Case Study on Mobile Traffic and Internet Standardization: Case Study on Mobile Traffic
Offloading and IPv6 Transition Technologies", December Offloading and IPv6 Transition Technologies", December
2013. 2013.
[Kohno13] Kohno, M., Asaba, T., and F. Baker, "Managing Diversity to [Kohno13] Kohno, M., Asaba, T., and F. Baker, "Managing Diversity to
Manage Technological Transition", December 2013. Manage Technological Transition", December 2013.
skipping to change at page 15, line 24 skipping to change at page 15, line 41
[Sen13] Sen, S., "On Economic Models of Network Technology [Sen13] Sen, S., "On Economic Models of Network Technology
Adoption, Design, and Viability", December 2013. Adoption, Design, and Viability", December 2013.
[Weber13] Weber, S., Guerin, R., and J. C. Oliveira, "When can [Weber13] Weber, S., Guerin, R., and J. C. Oliveira, "When can
bundling help adoption of network technologies or bundling help adoption of network technologies or
services?", December 2013. services?", December 2013.
[Welzl13] Welzl, M., "The "best effort" service as a deployment [Welzl13] Welzl, M., "The "best effort" service as a deployment
success factor", December 2013. success factor", December 2013.
Appendix A. Changes
This section to be removed prior to publication.
o 00 Initial Revision.
Author's Address Author's Address
Eliot Lear (editor) Eliot Lear (editor)
Richtistrasse 7 Richtistrasse 7
Wallisellen, ZH CH-8304 Wallisellen, ZH CH-8304
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com Email: lear@cisco.com
 End of changes. 24 change blocks. 
40 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/