draft-ietf-mboned-maccnt-req-08.txt   draft-ietf-mboned-maccnt-req-09.txt 
mboned T. Hayashi mboned T. Hayashi,
Internet-Draft NTT Network Innovation Internet-Draft H. Satou,
Intended status: Informational Laboratories Intended status: Informational H. Ohta
Expires: January 14, 2010 H. He Expires: September 6, 2010 NTT
H.He
Nortel Nortel
H. Satou
H. Ohta
NTT Network Service Systems
Laboratories
S. Vaidya S. Vaidya
Cisco Systems, Inc. Cisco Systems, Inc.
July 13, 2009 March 5, 2010
Requirements for Multicast AAA coordinated between Content Provider(s) Requirements for Multicast AAA coordinated between Content Provider(s)
and Network Service Provider(s) and Network Service Provider(s)
draft-ietf-mboned-maccnt-req-08 draft-ietf-mboned-maccnt-req-09
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This memo presents requirements in the area of accounting and access This memo presents requirements in the area of accounting and access
control for IP multicasting. The scope of the requirements is control for IP multicasting. The scope of the requirements is
limited to cases where Authentication, Accounting and Authorization limited to cases where Authentication, Authorization and Accounting
(AAA) functions are coordinated between Content Provider(s) and (AAA) functions are coordinated between Content Provider(s) and
Network Service Provider(s). Network Service Provider(s).
In order to describe the new requirements of a multi-entity Content In order to describe the new requirements of a multi-entity Content
Deliver System(CDS) using multicast, the memo presents three basic Delivery Service(CDS) using multicast, the memo presents three basic
business models: 1) the Content Provider and the Network Provider are business models: 1) the Content Provider and the Network Provider are
the same entity, 2) the Content Provider(s) and the Network the same entity, 2) the Content Provider(s) and the Network
Provider(s) are separate entities and users are not directly billed, Provider(s) are separate entities and users are not directly billed,
and 3) the Content Provider(s) and the Network Provider(s) are and 3) the Content Provider(s) and the Network Provider(s) are
separate entities and users are billed based on content consumption separate entities and users are billed based on content consumption
or subscriptions. The requirements of these three models are listed or subscriptions. The requirements of these three models are listed
and evaluated as to which aspects are already supported by existing and evaluated as to which aspects are already supported by existing
technologies and which aspects are not. technologies and which aspects are not.
General requirements for accounting and admission control General requirements for accounting and admission control
capabilities including quality-of-service (QoS) related issues are capabilities including quality-of-service (QoS) related issues are
listed and the constituent logical functional components are listed and the constituent logical functional components are
presented. presented.
This memo assumes that the capabilities can be realized by This memo assumes that the capabilities can be realized by
integrating AAA functionalities with a multicast CDS system, with integrating AAA functionalities with a multicast CDS system, with
IGMP/MLD at the edge of the network. IGMP/MLD at the edge of the network.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2010.
1. Introduction 1. Introduction
Broadband access networks such as ADSL (Asymmetric Digital Subscriber Broadband access networks such as ADSL (Asymmetric Digital Subscriber
Line) or FTTH (Fiber to the Home) have been deployed widely in recent Line) or FTTH (Fiber to the Home) have been deployed widely in recent
years. Content Delivery Service (CDS) is expected to be a major years. Content Delivery Service (CDS) is expected to be a major
application provided through broadband access networks. Because many application provided through broadband access networks. Because many
services such as television broadcasting require huge bandwidth services such as television broadcasting require huge bandwidth
(e.g., 6Mbit/s) and processing power at the content server(s), IP (e.g., 6Mbit/s) and processing power at the content server(s), IP
multicast is used as an efficient delivery mechanism for CDS. multicast is used as an efficient delivery mechanism for CDS.
skipping to change at page 4, line 33 skipping to change at page 4, line 15
User: In this document user refers to a requester and a recipient User: In this document user refers to a requester and a recipient
of multicast data, termed a viewer in CDS. of multicast data, termed a viewer in CDS.
User-based accounting: actions for grasping each user's behavior, User-based accounting: actions for grasping each user's behavior,
when she/he starts/stops to receive a channel, which channel when she/he starts/stops to receive a channel, which channel
she/he receives, etc. she/he receives, etc.
2.2. Abbreviations 2.2. Abbreviations
AAA: Authentication, Accounting and Authorization AAA: Authentication, Authorization and Accounting
ASM: Any-Source Multicast ASM: Any-Source Multicast
CDS: Content Delivery Service CDS: Content Delivery Service
CP: Content Provider CP: Content Provider
IGMP: Internet Group Management Protocol IGMP: Internet Group Management Protocol
MLD: Multicast Listener Discovery MLD: Multicast Listener Discovery
skipping to change at page 6, line 41 skipping to change at page 6, line 33
A more complex version of this business model is conceivable in which A more complex version of this business model is conceivable in which
a CP may require a user to enter into a subscription contract, even a CP may require a user to enter into a subscription contract, even
when the user does not get billed for content consumption. For when the user does not get billed for content consumption. For
example, a CP may value individual data because it allows it to example, a CP may value individual data because it allows it to
supply the advertisers with rich, user-segmented data and charge a supply the advertisers with rich, user-segmented data and charge a
higher premium. In that case the requirements of the next section higher premium. In that case the requirements of the next section
"CDS with direct billing of the end user" are generally applicable "CDS with direct billing of the end user" are generally applicable
because of the need to link the user data which the CP has to the because of the need to link the user data which the CP has to the
actual viewing (or stream downloading) data that the NSP has. actual viewing (or stream downloading) data that the NSP has.
4. Proposed Model: Multity-entity CDS with direct billing of the end 4. Proposed Model: Multity-entity CDS
user
In this model the networks for CDS contain three different types of In this model the networks for CDS contain three different types of
entities: Content Provider (CP), Network Service Provider (NSP), and entities: Content Provider (CP), Network Service Provider (NSP), and
user clients. An NSP owns the network resources (infrastructure). user clients. An NSP owns the network resources (infrastructure).
It accommodates content providers on one side and accommodates user It accommodates content providers on one side and accommodates user
clients on the other side. NSP provides the network for CDS to two clients on the other side. NSP provides the network for CDS to two
entities (i.e., CPs and user clients). A CP provides content to each entities (i.e., CPs and user clients). A CP provides content to each
user through the network of NSPs and charges users for content. NSPs user through the network of NSPs and charges users for content. NSPs
are responsible for delivering the content to user clients, and for are responsible for delivering the content to user clients, and for
controlling the network resources. A NSP charges a user or a CP for controlling the network resources. A NSP charges a user or a CP for
skipping to change at page 10, line 12 skipping to change at page 10, line 7
accepted if delivery of the requested stream would push the consumed accepted if delivery of the requested stream would push the consumed
bandwidth over the NSP policy-defined limit. bandwidth over the NSP policy-defined limit.
The network may need to control the combined bandwidth for all The network may need to control the combined bandwidth for all
channels at the physical port of the edge router or switch so that channels at the physical port of the edge router or switch so that
these given physical entities are not overflowed with traffic. This these given physical entities are not overflowed with traffic. This
entails being able to control the number of channels delivered, the entails being able to control the number of channels delivered, the
bandwidth for each channel and the combined bandwidth for all bandwidth for each channel and the combined bandwidth for all
channels. channels.
6. Performance requirements 6. Reauthorization and deauthorization requirements
A mechanism for periodic reauthorization of users who have already
joined a channel stream should be supported. The reauthorization
could be an authorization check based on the NSP's eligibility
requirements and/or could involve the NSP querying the CP for
reauthorization of a user.
A mechanism for deauthorization should be supported for cases in
which a user is deemed ineligible by the NSP and/or CP at the time of
a reauthorization check. If a NSP revokes authorization for the
network for a user it should force a leave, and record details of the
leave (including the time and reason for the forced leave.) If a CP
revokes authorization to content for a user the CP signals to the NSP
to cease streaming to that user. An example usage case for
deauthorizing a user is one where a user has a subscription or has
paid for a certain amount of content and has reached that limit. In
some models, it is conceivable that a CP could communicate the
parameters for de-authorization to the NSP at the time of the
original join's authorization so as to make NSP to CP reauthorization
requests unnecessary.
7. Performance requirements
Channel Join Latency and Leave Latency Channel Join Latency and Leave Latency
Commercial implementations of IP multicasting are likely to have Commercial implementations of IP multicasting are likely to have
strict requirements in terms of user experience. Join latency is the strict requirements in terms of user experience. Join latency is the
time between when a user sends a "join" request and when the time between when a user sends a "join" request and when the
requested data streaming first reaches the user. Leave latency is requested data streaming first reaches the user. Leave latency is
the time between when a user sends a "leave" signal and when the the time between when a user sends a "leave" signal and when the
network stops streaming to the user. Leave and Join latencies impact network stops streaming to the user. Leave and Join latencies impact
the acceptable user experience for fast channel surfing. In an IP-TV the acceptable user experience for fast channel surfing. In an IP-TV
skipping to change at page 10, line 37 skipping to change at page 11, line 8
Furthermore, leave affects resource consumption: with a low "leave Furthermore, leave affects resource consumption: with a low "leave
latency" network providers could minimize streaming content when latency" network providers could minimize streaming content when
there are no audiences. It is important that any overhead for there are no audiences. It is important that any overhead for
authentication, authorization, and access-control be minimized at the authentication, authorization, and access-control be minimized at the
times of joining and leaving multicast channels so as to achieve join times of joining and leaving multicast channels so as to achieve join
and leave latencies acceptable in terms of user experience. For and leave latencies acceptable in terms of user experience. For
example this is important in an IP-TV application, because users are example this is important in an IP-TV application, because users are
not going to be receptive to a slow response time when changing not going to be receptive to a slow response time when changing
channels. channels.
7. Concomitant requirements 8. Concomitant requirements
Scalability Scalability
Solutions that are used for AAA and QoS enabled IP multicasting Solutions that are used for AAA and QoS enabled IP multicasting
should scale enough to support the needs of content providers and should scale enough to support the needs of content providers and
network operators. NSP's multicast access and QoS policies should be network operators. NSP's multicast access and QoS policies should be
manageable for large scale users. (e.g. millions of users, thousands manageable for large scale users. (e.g. millions of users, thousands
of edge-routers) of edge-routers)
Service and Terminal Portability: Service and Terminal Portability:
skipping to change at page 11, line 19 skipping to change at page 11, line 37
unicasting when the "on-demand" nature of unicasting is not required. unicasting when the "on-demand" nature of unicasting is not required.
Therefore interfaces to multicasting should allow for easy Therefore interfaces to multicasting should allow for easy
integration into CDS systems that support unicasting. Especially integration into CDS systems that support unicasting. Especially
equivalent interfaces for authorization, access control and equivalent interfaces for authorization, access control and
accounting capabilities should be provided. accounting capabilities should be provided.
Support of ASM and SSM Support of ASM and SSM
Both ASM (G), and SSM (S,G) should be supported as multicast models. Both ASM (G), and SSM (S,G) should be supported as multicast models.
Support for Tunneled Multicast
The AAA requirements specified in this document should apply to both
end-to-end native multicast and to tunnel-enabled multicast, such as
AMT multicast: [I-D.ietf-mboned-auto-multicast]
Small Impact on the Existing Products Small Impact on the Existing Products
Impact on the existing products (e.g., protocols, software, etc.) Impact on the existing products (e.g., protocols, software, etc.)
should be as minimal as possible. Ideally the NSP should be able to should be as minimal as possible. Ideally the NSP should be able to
use the same infrastructure (such as access control) to support use the same infrastructure (such as access control) to support
commercial multicast services for the so called "triple play" commercial multicast services for the so called "triple play"
services: voice (VoIP), video, and broadband Internet access services: voice (VoIP), video, and broadband Internet access
services. When a CP requires the NSP to provide a level of QoS services. When a CP requires the NSP to provide a level of QoS
surpassing "best effort" delivery or to provide special services surpassing "best effort" delivery or to provide special services
(e.g., to limited users with specific attributes), certain parameters (e.g., to limited users with specific attributes), certain parameters
skipping to change at page 11, line 44 skipping to change at page 12, line 21
AAA features. NSPs may offer tiered services, with higher QOS, AAA features. NSPs may offer tiered services, with higher QOS,
accounting, authentication, etc., depending on contractual relation accounting, authentication, etc., depending on contractual relation
with the CPs. It is therefore important that Multicast AAA and QoS with the CPs. It is therefore important that Multicast AAA and QoS
functions be as modular and flexible as possible. functions be as modular and flexible as possible.
Multicast Replication Multicast Replication
The above requirements should also apply if multicast replication is The above requirements should also apply if multicast replication is
being done on an access-node (e.g. DSLAMs or OLTs). being done on an access-node (e.g. DSLAMs or OLTs).
8. Constituent Logical Functional Components 9. Constituent Logical Functional Components
Below is a diagram of a AAA enabled multicasting network, including Below is a diagram of a AAA enabled multicasting network, including
the logical components within the various entities. the logical components within the various entities.
+-------------------------------+ +-------------------------------+
| user | | user |
|+- - - - - - - - - - - - - - -+| |+- - - - - - - - - - - - - - -+|
|| CPE || || CPE ||
|| || || ||
|+- - - - - | - - - - - - - - -+| |+- - - - - | - - - - - - - - -+|
skipping to change at page 13, line 47 skipping to change at page 14, line 47
management (e.g. QoS management), as described in section 5, management (e.g. QoS management), as described in section 5,
"Admission Control for Multicasting". Resource management and "Admission Control for Multicasting". Resource management and
admission control is provided by MACF (Multicast Admission Control admission control is provided by MACF (Multicast Admission Control
Function). This means that, before replying to the user's multicast Function). This means that, before replying to the user's multicast
request, the mAAA queries the MACF for a network resource access request, the mAAA queries the MACF for a network resource access
decision over the interface IFd. The MACF is responsible for decision over the interface IFd. The MACF is responsible for
allocating network resources for forwarding multicast traffic. MACF allocating network resources for forwarding multicast traffic. MACF
also receives Leave information from NAS so that MACF releases also receives Leave information from NAS so that MACF releases
corresponding reserved resources. corresponding reserved resources.
9. Acknowledgments 10. Acknowledgments
The authors of this draft would like to express their appreciation to The authors of this draft would like to express their appreciation to
Christian Jacquenet of France Telecom whose contributions to the "AAA Christian Jacquenet of France Telecom whose contributions to the "AAA
Framework for Multicasting" [draft-ietf-mboned-multiaaa-framework] Framework for Multicasting" [draft-ietf-mboned-multiaaa-framework]
largely influenced this draft, Pekka Savola of Netcore Ltd., Daniel largely influenced this draft; Pekka Savola of Netcore Ltd.; Daniel
Alvarez, and Toerless Eckert of Cisco Systems, Sam Sambasivan of Alvarez, and Toerless Eckert of Cisco Systems; Sam Sambasivan of
AT&T, Sanjay Wadhwa, Greg Shepherd, and Leonard Giuliano of Juniper, AT&T; Sanjay Wadhwa, Greg Shepherd, and Leonard Giuliano of Juniper;
Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of Tom Anschutz and Steven Wright of BellSouth; Nicolai Leymann of
T-Systems, Bill Atwood of Concordia University, Carlos Garcia Braschi T-Systems; Bill Atwood of Concordia University; Carlos Garcia Braschi
of Telefonica Empresas, Marshall Eubanks in his role as mboned WG of Telefonica Empresas; Mark Altom, Andy Huang, Tom Imburgia, Han
chair, Ron Bonica in his role as Director as the Operations and Nguyen, Doug Nortz of ATT Labs; Marshall Eubanks in his role as
Management Area, Stephen Rife of NTT and David Meyer in his former mboned WG chair; Ron Bonica in his role as Director as the Operations
role as mboned WG chair, as well as their thanks to the participants and Management Area; Stephen Rife of Digital Garage and David Meyer
of the MBONED WG in general. in his former role as mboned WG chair as well as their thanks to the
participants of the MBONED WG in general.
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
10. IANA Considerations 11. IANA Considerations
This memo does not raise any IANA consideration issues. This memo does not raise any IANA consideration issues.
11. Security Considerations 12. Security Considerations
Accounting capabilities can be used to enhance the security of Accounting capabilities can be used to enhance the security of
multicast networks by excluding ineligible clients from the networks. multicast networks by excluding ineligible clients from the networks.
These requirements are not meant to address encryption issues. Any These requirements are not meant to address encryption issues. Any
solution meeting these requirements should allow for the solution meeting these requirements should allow for the
implementation of encryption such as MSEC on the multicast data. implementation of encryption such as MSEC on the multicast data.
12. Privacy considerations 13. Privacy considerations
Any solution which meets these requirements should weigh the benefits Any solution which meets these requirements should weigh the benefits
of user-based accounting with the privacy considerations of the user. of user-based accounting with the privacy considerations of the user.
For example solutions are encouraged when applicable to consider For example solutions are encouraged when applicable to consider
encryption of the content data between the content provider and the encryption of the content data between the content provider and the
user in such a way that the Network Provider does not know the user in such a way that the Network Provider does not know the
contents of the channel. contents of the channel.
13. Conclusion 14. Conclusion
This memo describes general requirements for providing AAA and QoS This memo describes general requirements for providing AAA and QoS
enabled IP multicasting services in multi-entity models. A few enabled IP multicasting services in multi-entity models. A few
models are evaluated with regard to their support by current models are evaluated with regard to their support by current
technologies. The "multi-entity CDS with direct billing of the end technologies. The "multi-entity CDS with direct billing of the end
user" model is presented and requirements for information sharing user" model is presented and requirements for information sharing
between entities and requirements for admission control to enable between entities and requirements for admission control to enable
guaranteeing of QoS are derived. Performance requirements and guaranteeing of QoS are derived. Performance requirements and
concomitant requirements are also presented. concomitant requirements are also presented.
14. Normative References 15. References
15.1. Normative References
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000. Accounting Management", RFC 2975, October 2000.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
15.2. Informative References
[I-D.ietf-mboned-auto-multicast]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
Pusateri, "Automatic IP Multicast Without Explicit Tunnels
(AMT)", draft-ietf-mboned-auto-multicast-09 (work in
progress), June 2008.
Authors' Addresses Authors' Addresses
Tsunemasa Hayashi Tsunemasa Hayashi
NTT Network Innovation Laboratories Nippon Telegraph and Telephone Corporation
1-1 Hikarino'oka 1-1 Hikarino'oka
Yokosuka-shi, Kanagawa 239-0847 Yokosuka-shi, Kanagawa 239-0847
Japan Japan
Phone: +81 46 859 8790 Phone: +81 46 859 8790
Email: hayashi.tsunemasa@lab.ntt.co.jp Email: hayashi.tsunemasa@lab.ntt.co.jp
Haixiang He
Nortel
600 Technology Park Drive
Billerica, MA 01801
USA
Phone: +1 978 288 7482
Email: haixiang@nortel.com
Hiroaki Satou Hiroaki Satou
NTT Network Service Systems Laboratories Nippon Telegraph and Telephone Corporation
3-9-11 Midoricho 3-9-11 Midoricho
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Phone: +81 422 59 4683 Phone: +81 422 59 4683
Email: satou.hiroaki@lab.ntt.co.jp Email: satou.hiroaki@lab.ntt.co.jp
Hiroshi Ohta Hiroshi Ohta
NTT Network Service Systems Laboratories Nippon Telegraph and Telephone Corporation
3-9-11 Midoricho 3-9-11 Midoricho
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Phone: +81 422 59 3617 Phone: +81 422 59 3617
Email: ohta.hiroshi@lab.ntt.co.jp Email: ohta.hiroshi@lab.ntt.co.jp
Haixiang He
Nortel
600 Technology Park Drive
Billerica, MA 01801
USA
Phone: +1 978 288 7482
Email: haixiang@nortel.com
Susheela Vaidya Susheela Vaidya
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 525 1952 Phone: +1 408 525 1952
Email: svaidya@cisco.com Email: svaidya@cisco.com
Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
 End of changes. 27 change blocks. 
90 lines changed or deleted 103 lines changed or added

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