draft-ietf-ippm-2679-bis-04.txt   draft-ietf-ippm-2679-bis-05.txt 
Network Working Group G. Almes Network Working Group G. Almes
Internet-Draft Texas A&M Internet-Draft Texas A&M
Obsoletes: 2679 (if approved) S. Kalidindi Obsoletes: 2679 (if approved) S. Kalidindi
Intended status: Standards Track Ixia Intended status: Standards Track Ixia
Expires: February 13, 2016 M. Zekauskas Expires: February 21, 2016 M. Zekauskas
Internet2 Internet2
A. Morton, Ed. A. Morton, Ed.
AT&T Labs AT&T Labs
August 12, 2015 August 20, 2015
A One-Way Delay Metric for IPPM A One-Way Delay Metric for IPPM
draft-ietf-ippm-2679-bis-04 draft-ietf-ippm-2679-bis-05
Abstract Abstract
This memo (RFC 2679 bis) defines a metric for one-way delay of This memo (RFC 2679 bis) defines a metric for one-way delay of
packets across Internet paths. It builds on notions introduced and packets across Internet paths. It builds on notions introduced and
discussed in the IPPM Framework document, RFC 2330; the reader is discussed in the IPPM Framework document, RFC 2330; the reader is
assumed to be familiar with that document. This memo makes RFC 2679 assumed to be familiar with that document. This memo makes RFC 2679
obsolete. obsolete.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 February 13, 2016. This Internet-Draft will expire on February 21, 2016.
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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3. A Singleton Definition for One-way Delay . . . . . . . . . . 8 3. A Singleton Definition for One-way Delay . . . . . . . . . . 8
3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 8 3.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 8
3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 10 3.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 10
3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 11 3.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 11
3.7.1. Errors or uncertainties related to Clocks . . . . . . 11 3.7.1. Errors or uncertainties related to Clocks . . . . . . 11
3.7.2. Errors or uncertainties related to Wire-time vs Host- 3.7.2. Errors or uncertainties related to Wire-time vs Host-
time . . . . . . . . . . . . . . . . . . . . . . . . 13 time . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7.3. Calibration . . . . . . . . . . . . . . . . . . . . . 13 3.7.3. Calibration . . . . . . . . . . . . . . . . . . . . . 13
3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 15 3.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 15
3.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 16 3.8.1. Type-P . . . . . . . . . . . . . . . . . . . . . . . 15
3.8.2. Loss Threshold . . . . . . . . . . . . . . . . . . . 16 3.8.2. Loss Threshold . . . . . . . . . . . . . . . . . . . 16
3.8.3. Calibration Results . . . . . . . . . . . . . . . . . 16 3.8.3. Calibration Results . . . . . . . . . . . . . . . . . 16
3.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 16 3.8.4. Path . . . . . . . . . . . . . . . . . . . . . . . . 16
4. A Definition for Samples of One-way Delay . . . . . . . . . . 17 4. A Definition for Samples of One-way Delay . . . . . . . . . . 16
4.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Metric Name: . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 17 4.2. Metric Parameters: . . . . . . . . . . . . . . . . . . . 17
4.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Metric Units: . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. Definition: . . . . . . . . . . . . . . . . . . . . . . . 18
4.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. Discussion: . . . . . . . . . . . . . . . . . . . . . . . 18
4.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 19 4.6. Methodologies: . . . . . . . . . . . . . . . . . . . . . 19
4.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 19 4.7. Errors and Uncertainties: . . . . . . . . . . . . . . . . 19
4.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 19 4.8. Reporting the metric: . . . . . . . . . . . . . . . . . . 19
5. Some Statistics Definitions for One-way Delay . . . . . . . . 19 5. Some Statistics Definitions for One-way Delay . . . . . . . . 19
5.1. Type-P-One-way-Delay-Percentile . . . . . . . . . . . . . 20 5.1. Type-P-One-way-Delay-Percentile . . . . . . . . . . . . . 20
5.2. Type-P-One-way-Delay-Median . . . . . . . . . . . . . . . 20 5.2. Type-P-One-way-Delay-Median . . . . . . . . . . . . . . . 20
5.3. Type-P-One-way-Delay-Minimum . . . . . . . . . . . . . . 21 5.3. Type-P-One-way-Delay-Minimum . . . . . . . . . . . . . . 21
5.4. Type-P-One-way-Delay-Inverse-Percentile . . . . . . . . . 21 5.4. Type-P-One-way-Delay-Inverse-Percentile . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Changes from RFC 2679 1. Changes from RFC 2679
Note: This section's placement currently preserves minimal Note: This section's placement currently preserves minimal
differencer between this memo and RFC 2679. The RFC Editor should differences between this memo and RFC 2679. The RFC Editor should
place this section in an appropriate place. place this section in an appropriate place, and remove this note.
The following text constitutes RFC 2769 bis proposed for advancement The following text constitutes RFC 2769 bis proposed for advancement
on the IETF Standards Track. This section tracks the changes from on the IETF Standards Track. This section tracks the changes from
[RFC2679]. [RFC2679].
[RFC6808] provides the test plan and results supporting [RFC2679] [RFC6808] provides the test plan and results supporting [RFC2679]
advancement along the standards track, according to the process in advancement along the standards track, according to the process in
[RFC6576]. The conclusions of [RFC6808] list four minor [RFC6576]. The conclusions of [RFC6808] list four minor
modifications: modifications:
skipping to change at page 4, line 28 skipping to change at page 4, line 28
3.5. 3.5.
5. GPS-based NTP experience replaces "to be tested" in section 3.5. 5. GPS-based NTP experience replaces "to be tested" in section 3.5.
6. Replaced "precedence" with updated terminology (DS Field) in 3.6 6. Replaced "precedence" with updated terminology (DS Field) in 3.6
and 3.8.1 (with reference). and 3.8.1 (with reference).
7. Added parenthetical guidance on minimizing interval between 7. Added parenthetical guidance on minimizing interval between
timestamp placement to send time in section 3.6. timestamp placement to send time in section 3.6.
8. Added text recognizing the impending deployment of transport 8. Section 3.7.2 notes that some current systems perform host time
layer encryption in section 3.6.
9. Section 3.7.2 notes that some current systems perform host time
stamping on the network interface hardware. stamping on the network interface hardware.
10. "instrument" replaced by the defined term "host" in sections 9. "instrument" replaced by the defined term "host" in sections
3.7.3 and 3.8.3. 3.7.3 and 3.8.3.
11. Added reference to RFC 3432 Periodic sampling alongside Poisson 10. Added reference to RFC 3432 Periodic sampling alongside Poisson
sampling in section 4, and also noting that a truncated Poisson sampling in section 4, and also noting that a truncated Poisson
distribution may be needed with modern networks as described in distribution may be needed with modern networks as described in
the IPPM Framework update, RFC7312. the IPPM Framework update, RFC7312.
12. Add reference to RFC 4737 Reordering metric in the related 11. Add reference to RFC 4737 Reordering metric in the related
discussion of section 4.6, Methodologies. discussion of section 4.6, Methodologies.
13. Formatting of Example in section 5.1 modified to match the 12. Formatting of Example in section 5.1 modified to match the
original (issue with conversion to XML in bis version). original (issue with conversion to XML in bis version).
14. Clarifying the conclusions on two related points on harm to 13. Clarifying the conclusions on two related points on harm to
measurements (recognition of measurement traffic for unexpected measurements (recognition of measurement traffic for unexpected
priority treatment and attacker traffic which emulates priority treatment and attacker traffic which emulates
measurement) in section 6, Security Considerations. measurement) in section 6, Security Considerations.
14. Expanded and updated the material on Privacy, and added cautions
on use of measurements for reconnaissance in section 6, Security
Considerations.
Section 5.4.4 of [RFC6390] suggests a common template for performance Section 5.4.4 of [RFC6390] suggests a common template for performance
metrics partially derived from previous IPPM and BMWG RFCs, but also metrics partially derived from previous IPPM and BMWG RFCs, but also
contains some new items. All of the [RFC6390] Normative points are contains some new items. All of the [RFC6390] Normative points are
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 both value and minimizes familiar outline of IPPM literature has both 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.
The publication of RFC 6921 suggested an area where this memo might The publication of RFC 6921 suggested an area where this memo might
skipping to change at page 9, line 39 skipping to change at page 9, line 39
of some GPS-based NTP servers and a conservatively designed and of some GPS-based NTP servers and a conservatively designed and
deployed set of other NTP servers should yield good results. This deployed set of other NTP servers should yield good results. This
was tested in [RFC6808], where a GPS measurement system's results was tested in [RFC6808], where a GPS measurement system's results
compared well with a GPS-based NTP synchronized system for the same compared well with a GPS-based NTP synchronized system for the same
intercontinental path. intercontinental path.
+ A given methodology will have to include a way to determine whether + A given methodology will have to include a way to determine whether
a delay value is infinite or whether it is merely very large (and the a delay value is infinite or whether it is merely very large (and the
packet is yet to arrive at Dst). As noted by Mahdavi and Paxson packet is yet to arrive at Dst). As noted by Mahdavi and Paxson
[RFC2678], simple upper bounds (such as the 255 seconds theoretical [RFC2678], simple upper bounds (such as the 255 seconds theoretical
upper bound on the lifetimes of IP packets [RFC0791]) could be used, upper bound on the lifetimes of IP packets [RFC0791]) could be used;
but good engineering, including an understanding of packet lifetimes, but good engineering, including an understanding of packet lifetimes,
will be needed in practice. {Comment: Note that, for many will be needed in practice. {Comment: Note that, for many
applications of these metrics, the harm in treating a large delay as applications of these metrics, the harm in treating a large delay as
infinite might be zero or very small. A TCP data packet, for infinite might be zero or very small. A TCP data packet, for
example, that arrives only after several multiples of the RTT may as example, that arrives only after several multiples of the RTT may as
well have been lost. See section 4.1.1 of [RFC6703] for examination well have been lost. See section 4.1.1 of [RFC6703] for examination
of unusual packet delays and application performance estimation.} of unusual packet delays and application performance estimation.}
+ If the packet is duplicated along the path (or paths) so that + If the packet is duplicated along the path (or paths) so that
multiple non-corrupt copies arrive at the destination, then the multiple non-corrupt copies arrive at the destination, then the
skipping to change at page 10, line 31 skipping to change at page 10, line 31
follows: follows:
+ Arrange that Src and Dst are synchronized; that is, that they have + Arrange that Src and Dst are synchronized; that is, that they have
clocks that are very closely synchronized with each other and each clocks that are very closely synchronized with each other and each
fairly close to the actual time. fairly close to the actual time.
+ At the Src host, select Src and Dst IP addresses, and form a test + At the Src host, select Src and Dst IP addresses, and form a test
packet of Type-P with these addresses. Any 'padding' portion of the packet of Type-P with these addresses. Any 'padding' portion of the
packet needed only to make the test packet a given size should be packet needed only to make the test packet a given size should be
filled with randomized bits to avoid a situation in which the filled with randomized bits to avoid a situation in which the
measured delay is lower than it would otherwise be due to compression measured delay is lower than it would otherwise be, due to
techniques along the path. Note that use of transport layer compression techniques along the path. Also see section 3.1.2 of
encryption will counteract the deployment of network-based analysis [RFC7312].
and may reduce the adoption of network-based payload optimizations
like compression.
+ At the Dst host, arrange to receive the packet. + At the Dst host, arrange to receive the packet.
+ At the Src host, place a timestamp in the prepared Type-P packet, + At the Src host, place a timestamp in the prepared Type-P packet,
and send it towards Dst (ideally minimizing time before sending). and send it towards Dst (ideally minimizing time before sending).
+ If the packet arrives within a reasonable period of time, take a + If the packet arrives within a reasonable period of time, take a
timestamp as soon as possible upon the receipt of the packet. By timestamp as soon as possible upon the receipt of the packet. By
subtracting the two timestamps, an estimate of one-way delay can be subtracting the two timestamps, an estimate of one-way delay can be
computed. Error analysis of a given implementation of the method computed. Error analysis of a given implementation of the method
skipping to change at page 13, line 23 skipping to change at page 13, line 17
just prior to sending the test packet and when Dst grabs a timestamp just prior to sending the test packet and when Dst grabs a timestamp
just after having received the test packet, and we refer to these two just after having received the test packet, and we refer to these two
points as "host times". points as "host times".
We note that some systems perform host time stamping on the network We note that some systems perform host time stamping on the network
interface hardware, in an attempt to minimize the difference from interface hardware, in an attempt to minimize the difference from
wire times. wire times.
To the extent that the difference between wire time and host time is To the extent that the difference between wire time and host time is
accurately known, this knowledge can be used to correct for host time accurately known, this knowledge can be used to correct for host time
measurements and the corrected value more accurately estimates the measurements, and the corrected value more accurately estimates the
desired (wire time) metric. desired (wire time) metric.
To the extent, however, that the difference between wire time and To the extent, however, that the difference between wire time and
host time is uncertain, this uncertainty must be accounted for in an host time is uncertain, this uncertainty must be accounted for in an
analysis of a given measurement method. We denote by Hsource an analysis of a given measurement method. We denote by Hsource an
upper bound on the uncertainty in the difference between wire time upper bound on the uncertainty in the difference between wire time
and host time on the Src host, and similarly define Hdest for the Dst and host time on the Src host, and similarly define Hdest for the Dst
host. We then note that these problems introduce a total uncertainty host. We then note that these problems introduce a total uncertainty
of Hsource+Hdest. This estimate of total wire-vs-host uncertainty of Hsource+Hdest. This estimate of total wire-vs-host uncertainty
should be included in the error/uncertainty analysis of any should be included in the error/uncertainty analysis of any
skipping to change at page 16, line 12 skipping to change at page 15, line 51
[RFC6703] for extensive discussion of reporting considerations for [RFC6703] for extensive discussion of reporting considerations for
different audiences). different audiences).
3.8.1. Type-P 3.8.1. Type-P
As noted in the Framework document, section 13 of [RFC2330], the As noted in the Framework document, section 13 of [RFC2330], the
value of the metric may depend on the type of IP packets used to make value of the metric may depend on the type of IP packets used to make
the measurement, or "Type-P". The value of Type-P-One-way-Delay the measurement, or "Type-P". The value of Type-P-One-way-Delay
could change if the protocol (UDP or TCP), port number, size, or could change if the protocol (UDP or TCP), port number, size, or
arrangement for special treatment (e.g., IP DS Field [RFC2780], ECN arrangement for special treatment (e.g., IP DS Field [RFC2780], ECN
[RFC3168], or RSVP) changes. Additional packet distinctions included [RFC3168], or RSVP) changes. Additional packet distinctions
in future extensions of the Type-P definition will apply. The exact identified in future extensions of the Type-P definition will apply.
Type-P used to make the measurements MUST be accurately reported. The exact Type-P used to make the measurements MUST be accurately
reported.
3.8.2. Loss Threshold 3.8.2. Loss Threshold
In addition, the threshold (or methodology to distinguish) between a In addition, the threshold (or methodology to distinguish) between a
large finite delay and loss MUST be reported. large finite delay and loss MUST be reported.
3.8.3. Calibration Results 3.8.3. Calibration Results
+ If the systematic error can be determined, it SHOULD be removed + If the systematic error can be determined, it SHOULD be removed
from the measured values. from the measured values.
skipping to change at page 22, line 31 skipping to change at page 22, line 29
measurement methodologies SHOULD include appropriate techniques to measurement methodologies SHOULD include appropriate techniques to
reduce the probability measurement traffic can be distinguished from reduce the probability measurement traffic can be distinguished from
"normal" traffic. "normal" traffic.
If an attacker injects packets emulating traffic that are accepted as If an attacker injects packets emulating traffic that are accepted as
legitimate, the loss ratio or other measured values could be legitimate, the loss ratio or other measured values could be
corrupted. Authentication techniques, such as digital signatures, corrupted. Authentication techniques, such as digital signatures,
may be used where appropriate to guard against injected traffic may be used where appropriate to guard against injected traffic
attacks. attacks.
The privacy concerns of network measurement are limited by the active When considering privacy of those involved in measurement or those
measurements described in this memo. Unlike passive measurements, whose traffic is measured, the sensitive information available to
there can be no release of existing user data. potential observers is greatly reduced when using active techniques
which are within this scope of work. Passive observations of user
traffic for measurement purposes raise many privacy issues. We refer
the reader to the privacy considerations described in the Large Scale
Measurement of Broadband Performance (LMAP) Framework
[I-D.ietf-lmap-framework], which covers active and passive
techniques.
Collecting measurements or using measurement results for
reconnaissance to assist in subsequent system attacks is quite
common. Access to measurement results, or control of the measurement
systems to perform reconnaissance should be guarded against. See
Section 7 of [I-D.ietf-lmap-framework] (security considerations of
the LMAP Framework) for system requirements that help to avoid
measurement system compromise.
7. IANA Considerations 7. IANA Considerations
This memo makes no requests of IANA. This memo makes no requests of IANA.
8. Acknowledgements 8. Acknowledgements
For [RFC2679], special thanks are due to Vern Paxson of Lawrence For [RFC2679], special thanks are due to Vern Paxson of Lawrence
Berkeley Labs for his helpful comments on issues of clock uncertainty Berkeley Labs for his helpful comments on issues of clock uncertainty
and statistics. Thanks also to Garry Couch, Will Leland, Andy and statistics. Thanks also to Garry Couch, Will Leland, Andy
skipping to change at page 24, line 12 skipping to change at page 24, line 22
Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March
2012, <http://www.rfc-editor.org/info/rfc6576>. 2012, <http://www.rfc-editor.org/info/rfc6576>.
[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,
DOI 10.17487/RFC7312, August 2014, DOI 10.17487/RFC7312, August 2014,
<http://www.rfc-editor.org/info/rfc7312>. <http://www.rfc-editor.org/info/rfc7312>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-lmap-framework]
Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A framework for Large-Scale
Measurement of Broadband Performance (LMAP)", draft-ietf-
lmap-framework-14 (work in progress), April 2015.
[I-D.morton-ippm-2330-stdform-typep] [I-D.morton-ippm-2330-stdform-typep]
Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V.
Hegde, "Updates for IPPM's Active Metric Framework: Hegde, "Updates for IPPM's Active Metric Framework:
Packets of Type-P and Standard-Formed Packets", draft- Packets of Type-P and Standard-Formed Packets", draft-
morton-ippm-2330-stdform-typep-00 (work in progress), morton-ippm-2330-stdform-typep-00 (work in progress),
August 2015. August 2015.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
 End of changes. 23 change blocks. 
33 lines changed or deleted 53 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/