draft-iab-considerations-01.txt   draft-iab-considerations-02.txt 
skipping to change at page 1, line 30 skipping to change at page 1, line 30
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document suggests general architectural and policy questions to This document suggests general architectural and policy questions
be addressed in our work in the IETF. We note that this document that the IETF community has to address when working on new standards
contains questions to be addressed, as opposed to guidelines or and protocols. We note that this document contains questions to be
architectural principles to be followed. addressed, as opposed to guidelines or architectural principles to be
followed.
Changes from draft-iab-considerations-01.txt:
* Added a discussion on overloading.
* Added a discussion on complexity, robustness, and fragility.
* Added a section on Internationalization.
1. Introduction 1. Introduction
This document suggests general architectural and policy questions to This document suggests general architectural and policy questions to
be addressed in our work in the IETF. This document contains be addressed in our work in the IETF. This document contains
questions to be addressed, as opposed to guidelines or architectural questions to be addressed, as opposed to guidelines or architectural
principles to be followed. These questions are somewhat similar to principles to be followed. These questions are somewhat similar to
the "Security Considerations" currently required in IETF documents the "Security Considerations" currently required in IETF documents
[RFC2316]. [RFC2316].
This document is motivated in part by concerns of a growing lack of This document is motivated in part by concerns about a growing lack
coherence in the overall Internet architecture. We have moved from a of coherence in the overall Internet architecture. We have moved
world of a single, coherent architecture designed by a small group of from a world of a single, coherent architecture designed by a small
people, to a world of a complex, intricate architecture to address a group of people, to a world of a complex, intricate architecture to
wide-spread and heterogeneous environment. Because individual pieces address a wide-spread and heterogeneous environment. Because
of the architecture are often designed by sub-communities, with each individual pieces of the architecture are often designed by sub-
sub-community having its own set of interests, it is necessary to pay communities, with each sub-community having its own set of interests,
increasing attention to how each piece fits into the larger picture, it is necessary to pay increasing attention to how each piece fits
and to consider how each piece is chosen. For example, it is into the larger picture, and to consider how each piece is chosen.
unavoidable that each of us is inclined to solve a problem at the For example, it is unavoidable that each of us is inclined to solve a
layer of the protocol stack and using the tools that we understand problem at the layer of the protocol stack and using the tools that
the best; that does not necessarily mean that this is the most we understand the best; that does not necessarily mean that this is
appropriate layer or set of tools for solving this problem in the the most appropriate layer or set of tools for solving this problem
long-term. in the long-term.
2. Relationship to "Architectural Principles of the Internet" 2. Relationship to "Architectural Principles of the Internet"
RFC 1958 [RFC1958] outlines some architectural principles of the RFC 1958 [RFC1958] outlines some architectural principles of the
Internet, as "guidelines that have been found useful in the past, and Internet, as "guidelines that have been found useful in the past, and
that may be useful to those designing new protocols or evaluating that may be useful to those designing new protocols or evaluating
such designs." An example guideline is that "it is also generally such designs." An example guideline is that "it is also generally
felt that end-to-end functions can best be realized by end-to-end felt that end-to-end functions can best be realized by end-to-end
protocols." Similarly, an example design issue from [RFC1958] is that protocols." Similarly, an example design issue from [RFC1958] is that
"heterogeneity is inevitable and must be supported by design." "heterogeneity is inevitable and must be supported by design."
skipping to change at page 4, line 11 skipping to change at page 4, line 18
to be considered? to be considered?
Protecting Competing Interests: Protecting Competing Interests:
* Does the protocol protect the interests of competing parties (e.g., * Does the protocol protect the interests of competing parties (e.g.,
not only end-users, but also ISPs, router vendors, software vendors, not only end-users, but also ISPs, router vendors, software vendors,
or other parties)? Is the design modularized to allow competing or other parties)? Is the design modularized to allow competing
interests to play out, while also isolating "tussles" and preventing interests to play out, while also isolating "tussles" and preventing
them from spilling out into unrelated areas? them from spilling out into unrelated areas?
Designing for Choice vs. Avoiding Unnecessary Complexity:
* Is the protocol designed for choice, to allow different players to
express their preferences where appropriate? At the same time, does
the protocol avoid the "kitchen sink" approach of providing too many
options and too much choice?
Weighing Benefits against Costs: Weighing Benefits against Costs:
* How do the architectural benefits of a proposed new protocol * How do the architectural benefits of a proposed new protocol
compare against the architectural costs, if any? Have the compare against the architectural costs, if any? Have the
architectural costs been carefully considered? architectural costs been carefully considered?
* When adding features, have the potential costs of feature-creep and
the N-way interactions among options been considered, as well as the
potential benefits offered by each option?
The Whole Picture vs. Building Blocks: The Whole Picture vs. Building Blocks:
* Have you considered the larger context, while appropriately * Have you considered the larger context, while appropriately
restricting your own design efforts to one part of the whole? restricting your own design efforts to one part of the whole?
* Are there parts of the overall solution that will have to be * Are there parts of the overall solution that will have to be
provided by other IETF Working Groups or by other standards bodies? provided by other IETF Working Groups or by other standards bodies?
Designing for Choice vs. Avoiding Unnecessary Complexity:
* Is the protocol designed for choice, to allow different players to
express their preferences where appropriate? At the same time, does
the protocol avoid the "kitchen sink" approach of providing too many
options and too much choice?
Preserving Evolvability? Preserving Evolvability?
* Does the protocol protect the interests of the future, by * Does the protocol protect the interests of the future, by
preserving the evolvability of the Internet? Does the protocol preserving the evolvability of the Internet? Does the protocol
enable future developments? enable future developments?
* If an old protocol is overloaded with new functionality, or reused
for new purposes, have the possible complexities introduced been
taken carefully into account?
* For a protocol that introduces new complexity to the Internet
architecture, how does the protocol add robustness and preserve
evolvability, and how does it also introduce new fragilities to the
system?
Internationalization:
* Where protocols require elements in text format, have the possibly
conflicting requirements of global comprehensibility and the ability
to represent local text content been properly weighed against each
other?
Each of these questions is discussed in more depth in the rest of Each of these questions is discussed in more depth in the rest of
this paper. this paper.
4. Justifying the Solution. 4. Justifying the Solution.
Question: Why are you proposing this solution, instead of proposing Question: Why are you proposing this solution, instead of proposing
something else? something else?
4.1. Case study: Integrated and Differentiated Services. 4.1. Case study: Integrated and Differentiated Services.
A good part of the work of developing integrated and differentiated A good part of the work of developing integrated and differentiated
services has been to understand the problem to be solved, and to come services has been to understand the problem to be solved, and to come
to agreement on the architectural framework of the solution, and on to agreement on the architectural framework of the solution, and on
the nature of specific services. Thus, when integrated services was the nature of specific services. Thus, when integrated services was
being developed, the specification of the Controlled Load [RFC2211] being developed, the specification of the Controlled Load [RFC2211]
and Guaranteed [RFC2212] services each required justification of the and Guaranteed [RFC2212] services each required justification of the
need for that particular service, of low loss and bounded delay need for that particular service, of low loss and bounded delay
respectively. respectively.
Later, RFC 2475 on "An Architecture for Differentiated Services" Later, when RFC 2475 on "An Architecture for Differentiated Services"
proposed a scalable, service differentiation architecture that proposed a scalable, service differentiation architecture that
differs from the previously-defined architecture for integrated differs from the previously-defined architecture for integrated
services, the document also had to clearly justify the requirements services, the document also had to clearly justify the requirements
for this new architecture, and compare the proposed architecture to for this new architecture, and compare the proposed architecture to
other possible approaches [RFC2475]. Similarly, when the Assured other possible approaches [RFC2475]. Similarly, when the Assured
Forwarding [RFC2597] and Expedited Forwarding [RFC2598] Per-Hop Forwarding [RFC2597] and Expedited Forwarding [RFC2598] Per-Hop
Behaviors of differentiated services were proposed, each service Behaviors of differentiated services were proposed, each service
required a justification of the need for that service in the required a justification of the need for that service in the
Internet. Internet.
skipping to change at page 6, line 21 skipping to change at page 6, line 37
5.2. Discussion: The End-to-End Argument 5.2. Discussion: The End-to-End Argument
The classic 1984 paper on "End-To-End Arguments In System Design" The classic 1984 paper on "End-To-End Arguments In System Design"
[SRC84] begins a discussion of where to place functions among modules [SRC84] begins a discussion of where to place functions among modules
by suggesting that "functions placed at low levels of a system may be by suggesting that "functions placed at low levels of a system may be
redundant or of little value when compared with the cost of providing redundant or of little value when compared with the cost of providing
them at that low level. Examples discussed in the paper include bit them at that low level. Examples discussed in the paper include bit
error recovery, security using encryption, duplicate message error recovery, security using encryption, duplicate message
suppression, recovery from system crashes, and delivery suppression, recovery from system crashes, and delivery
acknowledgement. Low level mechanisms to support these functions are acknowledgement. Low level mechanisms to support these functions are
justified only as performance enhancements." We cite this not as a justified only as performance enhancements." The end-to-end
rule that cannot be violated, but as a guide to some of the issues to principle is one of the key architectural guidelines to consider in
be considered in choosing the appropriate layer for a function. choosing the appropriate layer for a function.
5.3. Case study: Layering Applications on Top of HTTP. 5.3. Case study: Layering Applications on Top of HTTP.
There has been considerable interest in layering applications on top There has been considerable interest in layering applications on top
of HTTP [RFC3205]. Reasons cited include compatibility with widely- of HTTP [RFC3205]. Reasons cited include compatibility with widely-
deployed browsers, the ability to reuse client and server libraries, deployed browsers, the ability to reuse client and server libraries,
the ability to use existing security mechanisms, and the ability to the ability to use existing security mechanisms, and the ability to
traverse firewalls. As RFC 3205 discusses, "the recent interest in traverse firewalls. As RFC 3205 discusses, "the recent interest in
layering new protocols over HTTP has raised a number of questions layering new protocols over HTTP has raised a number of questions
when such use is appropriate, and the proper way to use HTTP in when such use is appropriate, and the proper way to use HTTP in
skipping to change at page 9, line 51 skipping to change at page 10, line 23
9.1. Discussion: balancing competing interests 9.1. Discussion: balancing competing interests
[CWSB02] discusses the role that competition between competing [CWSB02] discusses the role that competition between competing
interests plays in the evolution of the Internet, and takes the interests plays in the evolution of the Internet, and takes the
position that the role of Internet protocols is to design the playing position that the role of Internet protocols is to design the playing
field in this competition, rather than to pick the outcome. The IETF field in this competition, rather than to pick the outcome. The IETF
has long taken the position that it can only design the protocols, has long taken the position that it can only design the protocols,
and that often two competing approaches will be developed, with the and that often two competing approaches will be developed, with the
marketplace left to decide between them [A02]. (It has also been marketplace left to decide between them [A02]. (It has also been
suggested that "the marketplace" left entirely to itself does not suggested that "the marketplace" left entirely to itself does not
always make the best decisions, and that adult supervision is always make the best decisions, and that working to identify and
sometimes helpful.) adopt the technically best solution is sometimes helpful.)
An example cited in [CWSB02] of modularization in support of An example cited in [CWSB02] of modularization in support of
competing interests is the decision to use codepoints in the IP competing interests is the decision to use codepoints in the IP
header to select QoS, rather than binding QoS to other properties header to select QoS, rather than binding QoS to other properties
such as port numbers. This separates the structural and economic such as port numbers. This separates the structural and economic
issues related to QoS from technical issues of protocols and port issues related to QoS from technical issues of protocols and port
numbers, and allows space for a wide range of structural and pricing numbers, and allows space for a wide range of structural and pricing
solutions to emerge. solutions to emerge.
It has also been suggested that companies in some cases have an It has also been suggested that companies in some cases have an
skipping to change at page 11, line 18 skipping to change at page 11, line 37
simplicity or robustness. [BMMWRO02] suggests that other highly simplicity or robustness. [BMMWRO02] suggests that other highly
extensible protocols developed in the IETF might also benefit from extensible protocols developed in the IETF might also benefit from
more coordination of extensions. more coordination of extensions.
11. Weighing architectural benefits against architectural costs. 11. Weighing architectural benefits against architectural costs.
Questions: How do the architectural benefits of a proposed new Questions: How do the architectural benefits of a proposed new
protocol compare against the architectural costs, if any? Have the protocol compare against the architectural costs, if any? Have the
architectural costs been carefully considered? architectural costs been carefully considered?
When adding features, have the potential costs of feature-creep and
the N-way interactions among options been considered, as well as the
potential benefits offered by each option?
11.1. Case Study: Performance-enhancing proxies (PEPs) 11.1. Case Study: Performance-enhancing proxies (PEPs)
RFC 3135 [RFC3135] considers the relative costs and benefits of RFC 3135 [RFC3135] considers the relative costs and benefits of
placing performance-enhancing proxies (PEPs) in the middle of a placing performance-enhancing proxies (PEPs) in the middle of a
network to address link-related degradations. In the case of PEPs, network to address link-related degradations. In the case of PEPs,
the potential costs include disabling the end-to-end use of IP layer the potential costs include disabling the end-to-end use of IP layer
security mechanisms; introducing a new possible point of failure that security mechanisms; introducing a new possible point of failure that
is not under the control of the end systems; adding increased is not under the control of the end systems; adding increased
difficulty in diagnosing and dealing with failures; and introducing difficulty in diagnosing and dealing with failures; and introducing
possible complications with asymmetric routing or mobile hosts. RFC possible complications with asymmetric routing or mobile hosts. RFC
skipping to change at page 13, line 40 skipping to change at page 14, line 11
applicable but only relate to the particular application of SIP being applicable but only relate to the particular application of SIP being
developed by the standardization bodies. An example is particular developed by the standardization bodies. An example is particular
interactions with accounting and billing for mobile telephony. interactions with accounting and billing for mobile telephony.
13. Preserving evolvability? 13. Preserving evolvability?
Does the protocol protect the interests of the future, by preserving Does the protocol protect the interests of the future, by preserving
the evolvability of the Internet? Does the protocol enable future the evolvability of the Internet? Does the protocol enable future
developments? developments?
If an old protocol is overloaded with new functionality, or reused
for new purposes, have the possible complexities introduced been
taken into account?
For a protocol that introduces new complexity to the Internet
architecture, does the protocol add robustness and preserve
evolvability? Does it also introduce unwanted new fragilities to the
system?
13.1. Discussion: evolvability. 13.1. Discussion: evolvability.
There is an extensive literature and an ongoing discussion about the There is an extensive literature and an ongoing discussion about the
evolvability, or lack of evolvability, of the Internet evolvability, or lack of evolvability, of the Internet
infrastructure; the web page on "Papers on the Evolvability of the infrastructure; the web page on "Papers on the Evolvability of the
Internet Infrastructure" has pointers to some of this literature Internet Infrastructure" has pointers to some of this literature
[Evolvability]. Issues range from the evolvability and overloading [Evolvability]. Issues range from the evolvability and overloading
of the DNS; the difficulties of the Internet in evolving to of the DNS; the difficulties of the Internet in evolving to
incorporate multicast, QoS, or IPv6; the difficulties of routing in incorporate multicast, QoS, or IPv6; the difficulties of routing in
meeting the demands of a changing and expanding Internet; and the meeting the demands of a changing and expanding Internet; and the
skipping to change at page 14, line 17 skipping to change at page 14, line 44
most important goal." In the beginning, the relative transparency of most important goal." In the beginning, the relative transparency of
the infrastructure in transmitting packets from one end-node to the infrastructure in transmitting packets from one end-node to
another was sufficient to ensure evolvability. However, this another was sufficient to ensure evolvability. However, this
transparency has become more murky over time, as cataloged in transparency has become more murky over time, as cataloged in
[RFC3234]. [CWSB02] also realistically suggests the following [RFC3234]. [CWSB02] also realistically suggests the following
guideline: "Failures of transparency will occur - design what happens guideline: "Failures of transparency will occur - design what happens
then." Thus, maintaining evolvability also requires mechanisms for then." Thus, maintaining evolvability also requires mechanisms for
allowing evolution in the face of a lack of transparency of the allowing evolution in the face of a lack of transparency of the
infrastructure itself. infrastructure itself.
14. Conclusions 13.2. Discussion: overloading.
There has been a strong tendency in the last few years to overload
some designs with new functionality, with resulting operational
complexities. Extensible protocols could be seen as one of the tools
for providing evolvability. However, if protocols and systems are
stretched beyond their reasonable design parameters, then scaling,
reliability, or security isssues could be introduced. Examples of
protocols that could be seen as either productively extended, or as
dangerously overloaded, include DNS [K02], MPLS, and BGP. In some
cases, overloading or extending a protocol may reduce total
complexity by avoiding the creation of a new protocol; in other cases
a new protocol might be the simpler solution.
We have a number of re-useable technologies, including component
technologies specifically designed for re-use. Examples include SASL,
BEEP and APEX. On the other hand, re-use should not go so far as to
turn a protocol into a Trojan Horse, as has happened with HTTP
[RFC3205].
13.3. Discussion: complexity, robustness, and fragility.
[WD02] gives a historical account of the evolution of the Internet as
a complex system, with particular attention to the tradeoffs between
complexity, robustness, and fragility. [WD02] describes the
robustness that follows from the simplicity of a connectionless,
layered, datagram infrastructure and a universal logical addressing
scheme, and, as case studies, describes the increasing complexity of
TCP and of BGP. The paper describes a complexity/robustness spiral
of an initially robust design and the appearance of fragilities,
followed by modifications for more robustness that themselves
introduce new fragilities. [WD02] conjectures that "the Internet is
only now beginning to experience an acceleration of this
complexity/robustness spiral and, if left unattended, can be fully
expected to experience arcane, irreconcilable, and far-reaching
robustness problems in the not-too-distant future." Citing [WD02],
[BFM02] views complexity as the primary mechanism that impedes
efficient scaling, and discusses the ways that complexity increases
capital and operational expenditures in carrier IP networks.
14. Internationalization.
Where protocols require elements in text format, have the possibly
conflicting requirements of global comprehensibility and the ability
to represent local text content been properly weighed against each
other?
14.1. Discussion: internationalization.
RFC 1958 [RFC1958] included a simple statement of the need for a
common language:
"Public (i.e. widely visible) names should be in case-independent
ASCII. Specifically, this refers to DNS names, and to protocol
elements that are transmitted in text format."
The IETF has studied character set issues in general [RFC 2130] and
made specific recommendations for the use of a standardised approach
[RFC 2277]. The situation is complicated by the fact that some uses
of text are hidden entirely in protocol elements and need only be
read by machines, while other uses are intended entirely for human
consumption. Many uses lie between these two extremes, which leads to
conflicting implementation requirements.
For the specific case of DNS, the Internationalized Domain Name
working group is considering these issues. As stated in the charter
of that working group, "A fundamental requirement in this work is to
not disturb the current use and operation of the domain name system,
and for the DNS to continue to allow any system anywhere to resolve
any domain name." This leads to some very strong requirements for
backwards compatibility with the existing ASCII-only DNS. Yet since
the DNS has come to be used as if it was a directory service, domain
names are also expected to be presented to users in local character
sets.
This document does not attempt to resolve these complex and difficult
issues, but simply states this as an issue to be addressed in our
work. The requirement that names encoded in a text format within
protocol elements be universally decodable (i.e. encoded in a
globally standard format with no intrinsic ambiguity) does not seem
likely to change. However, at some point, it is possible that this
format will no longer be case-independent ASCII.
15. Conclusions
This document, in progress, suggests general architectural and policy This document, in progress, suggests general architectural and policy
questions to be addressed in our work in the IETF. We would welcome questions to be addressed when working on new protocols and standards
feedback on this document. Feedback could be send to the editor, in the IETF.
Sally Floyd, at floyd@icir.org.
15. Acknowledgements We would welcome feedback on this document. Feedback could be send
to the editor, Sally Floyd, at floyd@icir.org.
16. Acknowledgements
This document has borrowed text freely from other IETF RFCs, and has This document has borrowed text freely from other IETF RFCs, and has
drawn on ideas from [ASSW02], [CWSB02], [M01] and elsewhere. This drawn on ideas from [ASSW02], [CWSB02], [M01] and elsewhere. This
document has developed from discussions in the IAB, and has drawn document has developed from discussions in the IAB, and has drawn
from suggestions made at IAB Plenary sessions and on the ietf general from suggestions made at IAB Plenary sessions and on the ietf general
discussion mailing list. The case study on SIP was contributed by discussion mailing list. The case study on SIP was contributed by
James Kempf, and the case study on Stresses on DNS was contributed by James Kempf, and the case study on Stresses on DNS was contributed by
Karen Sollins. We have also benefited from discussions with Noel Karen Sollins. The discussions on Internationization and on
Chiappa, Karen Sollins, John Wroclawski, and others. Overloading were based on an earlier document by Brian Carpenter and
Rob Austein. We have also benefited from discussions with Noel
Chiappa, Karen Sollins, John Wroclawski, and others, and from helpful
feedback from members of the IESG.
16. Normative References 17. Normative References
17. Informative References 18. Informative References
[A02] Harald Alvestrand, "Re: How many standards or protocols...", [A02] Harald Alvestrand, "Re: How many standards or protocols...",
email to the ietf discussion mailing list, Message-id: email to the ietf discussion mailing list, Message-id:
<598204031.1018942481@localhost>, April 16, 2002. <598204031.1018942481@localhost>, April 16, 2002.
[ASSW02] T. Anderson, S. Shenker, I. Stoica, and D. Wetherall, [ASSW02] T. Anderson, S. Shenker, I. Stoica, and D. Wetherall,
"Towards More Robust Internet Protocols", February 2002. [No public "Towards More Robust Internet Protocols", February 2002. [No public
URL yet.] URL yet.]
[BFM02] Randy Bush, Tim Griffin, and David Meyer, "Some Internet
Architectural Guidelines and Philosophy", internet draft, work in
progress, July 2002.
[BMMWRO02] S. Bradner, A. Mankin, R. Mahy, D. Willis, B. Rosen, J. [BMMWRO02] S. Bradner, A. Mankin, R. Mahy, D. Willis, B. Rosen, J.
Ott, "Change Process for the Session Initiation Protocol (SIP)", Ott, "Change Process for the Session Initiation Protocol (SIP)",
draft-tsvarea-sipchange-02.txt, internet draft, work in progress, May draft-tsvarea-sipchange-02.txt, internet draft, work in progress, May
2002. 2002.
[CDT01] Policy Concerns Raised by Proposed OPES Working Group [CDT01] Policy Concerns Raised by Proposed OPES Working Group
Efforts, email to the IESG, from the Center for Democracy & Efforts, email to the IESG, from the Center for Democracy &
Technology, August 3, 2001. URL "http://www.imc.org/ietf- Technology, August 3, 2001. URL "http://www.imc.org/ietf-
openproxy/mail-archive/msg00828.html". openproxy/mail-archive/msg00828.html".
skipping to change at page 17, line 5 skipping to change at page 19, line 23
In System Design", ACM Transactions on Computer Systems, V.2, N.4, p. In System Design", ACM Transactions on Computer Systems, V.2, N.4, p.
277-88. 1984. 277-88. 1984.
[T89] D. Tennenhouse, "Layered Multiplexing Considered Harmful", [T89] D. Tennenhouse, "Layered Multiplexing Considered Harmful",
Protocols for High-Speed Networks, 1989. Protocols for High-Speed Networks, 1989.
[UNSAF] L. Daigle, "IAB Considerations for UNilateral Self-Address [UNSAF] L. Daigle, "IAB Considerations for UNilateral Self-Address
Fixing (UNSAF)", draft-iab-unsaf-considerations-02.txt, internet- Fixing (UNSAF)", draft-iab-unsaf-considerations-02.txt, internet-
draft, work in progress, June 2002. draft, work in progress, June 2002.
18. Security Considerations [WD02] Walter Willinger and John Doyle, "Robustness and the Internet:
Design and Evolution", draft, March 2002, URL
"http://netlab.caltech.edu/internet/".
19. Security Considerations
This document does not propose any new protocols, and therefore does This document does not propose any new protocols, and therefore does
not involve any security considerations in that sense. However, not involve any security considerations in that sense. However,
throughout this document there are discussions of the privacy and throughout this document there are discussions of the privacy and
integrity issues and the architectural requirements created by those integrity issues and the architectural requirements created by those
issues. issues.
19. IANA Considerations 20. IANA Considerations
There are no IANA considerations regarding this document. There are no IANA considerations regarding this document.
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Internet Architecture Board Internet Architecture Board
EMail: iab@iab.org EMail: iab@iab.org
IAB Membership at time this document was completed: IAB Membership at time this document was completed:
 End of changes. 20 change blocks. 
50 lines changed or deleted 172 lines changed or added

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