draft-ietf-ippm-2680-bis-01.txt   draft-ietf-ippm-2680-bis-02.txt 
Network Working Group G. Almes Network Working Group G. Almes
Internet-Draft Texas A&M Internet-Draft Texas A&M
Obsoletes: 2680 (if approved) S. Kalidindi Obsoletes: 2680 (if approved) S. Kalidindi
Intended status: Standards Track Ixia Intended status: Standards Track Ixia
Expires: July 30, 2015 M. Zekauskas Expires: December 22, 2015 M. Zekauskas
Internet2 Internet2
A. Morton, Ed. A. Morton, Ed.
AT&T Labs AT&T Labs
January 26, 2015 June 20, 2015
A One-Way Loss Metric for IPPM A One-Way Loss Metric for IPPM
draft-ietf-ippm-2680-bis-01 draft-ietf-ippm-2680-bis-02
Abstract Abstract
This memo (RFC 2680 bis) defines a metric for one-way loss of packets This memo (RFC 2680 bis) defines a metric for one-way loss of packets
across Internet paths. It builds on notions introduced and discussed across Internet paths. It builds on notions introduced and discussed
in the IPPM Framework document, RFC 2330; the reader is assumed to be in the IPPM Framework document, RFC 2330; the reader is assumed to be
familiar with that document. familiar with that document. This memo makes RFC 2680 obsolete.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 30, 2015. This Internet-Draft will expire on December 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. General Issues Regarding Time . . . . . . . . . . . . . . 4 1.2. General Issues Regarding Time . . . . . . . . . . . . . . 4
2. A Singleton Definition for One-way Packet Loss . . . . . . . 6 2. A Singleton Definition for One-way Packet Loss . . . . . . . 6
2.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 6 2.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 6
2.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 7 2.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 7
2.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 8 2.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 8
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3. A Definition for Samples of One-way Packet Loss . . . . . . . 10 3. A Definition for Samples of One-way Packet Loss . . . . . . . 10
3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 11 3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 11
3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 13 3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 13
3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 13 3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 13
3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 13 3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 13
4. Some Statistics Definitions for One-way Packet Loss . . . . . 14 4. Some Statistics Definitions for One-way Packet Loss . . . . . 14
4.1. Type-P-One-way-Packet Loss-Average . . . . . . . . . . . 14 4.1. Type-P-One-way-Packet Loss-Ratio . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7. RFC 2680 bis . . . . . . . . . . . . . . . . . . . . . . . . 16 7. RFC 2680 bis . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This memo defines a metric for one-way packet loss across Internet This memo defines a metric for one-way packet loss across Internet
paths. It builds on notions introduced and discussed in the IPPM paths. It builds on notions introduced and discussed in the IPPM
Framework document, [RFC2330]; the reader is assumed to be familiar Framework document, [RFC2330]; the reader is assumed to be familiar
with that document, and its recent update [RFC7312]. with that document, and its recent update [RFC7312].
This memo is intended to be parallel in structure to a companion This memo is intended to be parallel in structure to a companion
skipping to change at page 10, line 42 skipping to change at page 10, line 42
includes the record route (or loose-source route) option in the IP includes the record route (or loose-source route) option in the IP
header, and the path is short enough, and all routers* on the path header, and the path is short enough, and all routers* on the path
support record (or loose-source) route, then the path will be support record (or loose-source) route, then the path will be
precisely recorded. This is impractical because the route must be precisely recorded. This is impractical because the route must be
short enough, many routers do not support (or are not configured for) short enough, many routers do not support (or are not configured for)
record route, and use of this feature would often artificially worsen record route, and use of this feature would often artificially worsen
the performance observed by removing the packet from common-case the performance observed by removing the packet from common-case
processing. However, partial information is still valuable context. processing. However, partial information is still valuable context.
For example, if a host can choose between two links* (and hence two For example, if a host can choose between two links* (and hence two
separate routes from Src to Dst), then the initial link used is separate routes from Src to Dst), then the initial link used is
valuable context. {Comment: For example, with Merit's NetNow setup, a valuable context. {Comment: Backbone path selection services come and
Src on one NAP can reach a Dst on another NAP by either of several go. A historical example was Merit's NetNow setup, where a Src on
different backbone networks.} one NAP can reach a Dst on another NAP by either of several different
backbone networks.}
3. A Definition for Samples of One-way Packet Loss 3. A Definition for Samples of One-way Packet Loss
Given the singleton metric Type-P-One-way-Packet-Loss, we now define Given the singleton metric Type-P-One-way-Packet-Loss, we now define
one particular sample of such singletons. The idea of the sample is one particular sample of such singletons. The idea of the sample is
to select a particular binding of the parameters Src, Dst, and Type- to select a particular binding of the parameters Src, Dst, and Type-
P, then define a sample of values of parameter T. The means for P, then define a sample of values of parameter T. The means for
defining the values of T is to select a beginning time T0, a final defining the values of T is to select a beginning time T0, a final
time Tf, and an average rate lambda, then define a pseudo-random time Tf, and an average rate lambda, then define a pseudo-random
Poisson process of rate lambda, whose values fall between T0 and Tf. Poisson process of rate lambda, whose values fall between T0 and Tf.
skipping to change at page 12, line 46 skipping to change at page 12, line 46
effects of self-synchronization and also capture a sample that is effects of self-synchronization and also capture a sample that is
statistically as unbiased as possible. The Poisson process is used statistically as unbiased as possible. The Poisson process is used
to schedule the loss measurements. The test packets will generally to schedule the loss measurements. The test packets will generally
not arrive at Dst according to a Poisson distribution, since they are not arrive at Dst according to a Poisson distribution, since they are
influenced by the network. Time-slotted links described in [RFC7312] influenced by the network. Time-slotted links described in [RFC7312]
can greatly modify the sample characteristics. can greatly modify the sample characteristics.
{Comment: there is, of course, no claim that real Internet traffic {Comment: there is, of course, no claim that real Internet traffic
arrives according to a Poisson arrival process. arrives according to a Poisson arrival process.
It is important to note that, in contrast to this metric, loss rates It is important to note that, in contrast to this metric, loss ratios
observed by transport connections do not reflect unbiased samples. observed by transport connections do not reflect unbiased samples.
For example, TCP transmissions both (1) occur in bursts, which can For example, TCP transmissions both (1) occur in bursts, which can
induce loss due to the burst volume that would not otherwise have induce loss due to the burst volume that would not otherwise have
been observed, and (2) adapt their transmission rate in an attempt to been observed, and (2) adapt their transmission rate in an attempt to
minimize the loss rate observed by the connection.} minimize the loss ratio observed by the connection.}
All the singleton Type-P-One-way-Packet-Loss metrics in the sequence All the singleton Type-P-One-way-Packet-Loss metrics in the sequence
will have the same values of Src, Dst, and Type-P. will have the same values of Src, Dst, and Type-P.
Note also that, given one sample that runs from T0 to Tf, and given Note also that, given one sample that runs from T0 to Tf, and given
new time values T0' and Tf' such that T0 <= T0' <= Tf' <= Tf, the new time values T0' and Tf' such that T0 <= T0' <= Tf' <= Tf, the
subsequence of the given sample whose time values fall between T0' subsequence of the given sample whose time values fall between T0'
and Tf' are also a valid Type-P-One-way-Packet-Loss-Poisson-Stream and Tf' are also a valid Type-P-One-way-Packet-Loss-Poisson-Stream
sample. sample.
3.6. Methodologies: 3.6. Methodologies:
skipping to change at page 14, line 13 skipping to change at page 14, line 13
Type-P-One-way-Packet-Loss.) Type-P-One-way-Packet-Loss.)
4. Some Statistics Definitions for One-way Packet Loss 4. Some Statistics Definitions for One-way Packet Loss
Given the sample metric Type-P-One-way-Packet-Loss-Poisson-Stream, we Given the sample metric Type-P-One-way-Packet-Loss-Poisson-Stream, we
now offer several statistics of that sample. These statistics are now offer several statistics of that sample. These statistics are
offered mostly to be illustrative of what could be done. See offered mostly to be illustrative of what could be done. See
[RFC6703] for additional discussion of statistics that are relevant [RFC6703] for additional discussion of statistics that are relevant
to different audiences. to different audiences.
4.1. Type-P-One-way-Packet Loss-Average 4.1. Type-P-One-way-Packet Loss-Ratio
Given a Type-P-One-way-Packet-Loss-Poisson-Stream, the average of all Given a Type-P-One-way-Packet-Loss-Poisson-Stream, the average of all
the L values in the Stream. In addition, the Type-P-One-way-Packet- the L values in the Stream is the ratio of losses to total packets in
Loss-Average is undefined if the sample is empty. the stream. In addition, the Type-P-One-way-Packet-Loss-Ratio is
undefined if the sample is empty.
Example: suppose we take a sample and the results are: Example: suppose we take a sample and the results are:
Stream1 = < Stream1 = <
<T1, 0> <T1, 0>
<T2, 0> <T2, 0>
<T3, 1> <T3, 1>
<T4, 0> <T4, 0>
<T5, 0> <T5, 0>
> >
Then the average would be 0.2. Then the average of loss results would be 0.2, the loss ratio.
Note that, since healthy Internet paths should be operating at loss Note that, since healthy Internet paths should be operating at loss
rates below 1% (particularly if high delay-bandwidth products are to ratios below 1% (particularly if high delay-bandwidth products are to
be sustained), the sample sizes needed might be larger than one would be sustained), the sample sizes needed might be larger than one would
like. Thus, for example, if one wants to discriminate between like. Thus, for example, if one wants to discriminate between
various fractions of 1% over one-minute periods, then several hundred various fractions of 1% over one-minute periods, then several hundred
samples per minute might be needed. This would result in larger samples per minute might be needed. This would result in larger
values of lambda than one would ordinarily want. values of lambda than one would ordinarily want.
Note that although the loss threshold should be set such that any Note that although the loss threshold should be set such that any
errors in loss are not significant, if the possibility that a packet errors in loss are not significant, if the possibility that a packet
which arrived is counted as lost due to resource exhaustion is which arrived is counted as lost due to resource exhaustion is
significant compared to the loss rate of interest, Type-P-One-way- significant compared to the loss ratio of interest, Type-P-One-way-
Packet-Loss-Average will be meaningless. Packet-Loss-Ratio will be meaningless.
5. Security Considerations 5. Security Considerations
Conducting Internet measurements raises both security and privacy Conducting Internet measurements raises both security and privacy
concerns. This memo does not specify an implementation of the concerns. This memo does not specify an implementation of the
metrics, so it does not directly affect the security of the Internet metrics, so it does not directly affect the security of the Internet
nor of applications which run on the Internet. However, nor of applications which run on the Internet. However,
implementations of these metrics must be mindful of security and implementations of these metrics must be mindful of security and
privacy concerns. privacy concerns.
skipping to change at page 15, line 29 skipping to change at page 15, line 29
additional traffic into the networks they measure. If they inject additional traffic into the networks they measure. If they inject
"too much" traffic, they can skew the results of the measurement, and "too much" traffic, they can skew the results of the measurement, and
in extreme cases cause congestion and denial of service. in extreme cases cause congestion and denial of service.
The measurements themselves could be harmed by routers giving The measurements themselves could be harmed by routers giving
measurement traffic a different priority than "normal" traffic, or by measurement traffic a different priority than "normal" traffic, or by
an attacker injecting artificial measurement traffic. If routers can an attacker injecting artificial measurement traffic. If routers can
recognize measurement traffic and treat it separately, the recognize measurement traffic and treat it separately, the
measurements will not reflect actual user traffic. If an attacker measurements will not reflect actual user traffic. If an attacker
injects artificial traffic that is accepted as legitimate, the loss injects artificial traffic that is accepted as legitimate, the loss
rate will be artificially lowered. Therefore, the measurement ratio will be artificially lowered. Therefore, the measurement
methodologies SHOULD include appropriate techniques to reduce the methodologies SHOULD include appropriate techniques to reduce the
probability measurement traffic can be distinguished from "normal" probability measurement traffic can be distinguished from "normal"
traffic. Authentication techniques, such as digital signatures, may traffic. Authentication techniques, such as digital signatures, may
be used where appropriate to guard against injected traffic attacks. be used where appropriate to guard against injected traffic attacks.
The privacy concerns of network measurement are limited by the active The privacy concerns of network measurement are limited by the active
measurements described in this memo. Unlike passive measurements, measurements described in this memo. Unlike passive measurements,
there can be no release of existing user data. there can be no release of existing user data.
6. Acknowledgements 6. Acknowledgements
Thanks are due to Matt Mathis for encouraging this work and for For [RFC2680], thanks are due to Matt Mathis for encouraging this
calling attention on so many occasions to the significance of packet work and for calling attention on so many occasions to the
loss. significance of packet loss. Thanks are due also to Vern Paxson for
his valuable comments on early drafts, and to Garry Couch and Will
Leland for several useful suggestions.
Thanks are due also to Vern Paxson for his valuable comments on early For RFC 2680 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini
drafts, and to Garry Couch and Will Leland for several useful Elkins, and Barry Constantine for sharing their measurement
suggestions. experience as part of their careful reviews.
7. RFC 2680 bis 7. RFC 2680 bis
The text above constitutes RFC 2680 bis proposed for advancement on The text above constitutes RFC 2680 bis proposed for advancement on
the IETF Standards Track. the IETF Standards Track.
[RFC7290] provides the test plan and results supporting [RFC2680] [RFC7290] provides the test plan and results supporting [RFC2680]
advancement along the standards track, according to the process in advancement along the standards track, according to the process in
[RFC6576]. The conclusions of [RFC7290] list four minor [RFC6576]. The conclusions of [RFC7290] list four minor
modifications for inclusion: modifications for inclusion:
skipping to change at page 17, line 41 skipping to change at page 17, line 41
covered, but not quite in the same section names or orientation. covered, but not quite in the same section names or orientation.
Several of the Informative points are covered. Maintaining the Several of the Informative points are covered. Maintaining the
familiar outline of IPPM literature has value and minimizes familiar outline of IPPM literature has value and minimizes
unnecessary differences between this revised RFC and current/future unnecessary differences between this revised RFC and current/future
IPPM RFCs. IPPM RFCs.
8. IANA Considerations 8. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
9. Acknowledgements 9. References
For [RFC2680], special thanks are due to Vern Paxson of Lawrence
Berkeley Labs for his helpful comments on issues of clock uncertainty
and statistics. Thanks also to Garry Couch, Will Leland, Andy
Scherrer, Sean Shapira, and Roland Wittig for several useful
suggestions.
For RFC 2680 bis, thanks to Joachim Fabini, Ruediger Geib, Nalini
Elkins, and Barry Constantine for sharing their measurement
experience as part of their careful reviews.
10. References
10.1. Normative References 9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May "Framework for IP Performance Metrics", RFC 2330, May
1998. 1998.
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999. Connectivity", RFC 2678, September 1999.
skipping to change at page 18, line 43 skipping to change at page 18, line 30
37, RFC 2780, March 2000. 37, RFC 2780, March 2000.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
November 2002. November 2002.
[RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP [RFC6576] Geib, R., Morton, A., Fardid, R., and A. Steinmitz, "IP
Performance Metrics (IPPM) Standard Advancement Testing", Performance Metrics (IPPM) Standard Advancement Testing",
BCP 176, RFC 6576, March 2012. BCP 176, RFC 6576, March 2012.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View",
RFC 6703, August 2012.
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Framework for IP Performance Metrics (IPPM)", RFC 7312, Framework for IP Performance Metrics (IPPM)", RFC 7312,
August 2014. August 2014.
10.2. Informative References 9.2. Informative References
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
S., and J. Perser, "Packet Reordering Metrics", RFC 4737, S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
November 2006. November 2006.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
October 2011. October 2011.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View",
RFC 6703, August 2012.
[RFC7290] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test [RFC7290] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test
Plan and Results for Advancing RFC 2680 on the Standards Plan and Results for Advancing RFC 2680 on the Standards
Track", RFC 7290, July 2014. Track", RFC 7290, July 2014.
Authors' Addresses Authors' Addresses
Guy Almes Guy Almes
Texas A&M Texas A&M
Email: almes@acm.org Email: almes@acm.org
 End of changes. 25 change blocks. 
52 lines changed or deleted 40 lines changed or added

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