draft-ietf-nsis-ntlp-sctp-05.txt   draft-ietf-nsis-ntlp-sctp-06.txt 
Network Working Group X. Fu Network Working Group X. Fu
Internet-Draft C. Dickmann Internet-Draft C. Dickmann
Intended status: Standards Track University of Goettingen Intended status: Standards Track University of Goettingen
Expires: April 29, 2009 J. Crowcroft Expires: September 9, 2009 J. Crowcroft
University of Cambridge University of Cambridge
October 26, 2008 March 8, 2009
General Internet Signaling Transport (GIST) over SCTP General Internet Signaling Transport (GIST) over SCTP and Datagram TLS
draft-ietf-nsis-ntlp-sctp-05.txt draft-ietf-nsis-ntlp-sctp-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
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.
This Internet-Draft will expire on April 29, 2009. This Internet-Draft will expire on September 9, 2009.
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
The General Internet Signaling Transport (GIST) protocol currently The General Internet Signaling Transport (GIST) protocol currently
uses TCP or TLS over TCP for connection mode operation. This uses TCP or TLS over TCP for connection mode operation. This
document describes the usage of GIST over the Stream Control document describes the usage of GIST over the Stream Control
Transmission Protocol (SCTP). The use of SCTP can take advantage of Transmission Protocol (SCTP) and Datagram Transport Layer Security
features provided by SCTP, namely streaming-based transport, support (DTLS). The use of SCTP can take advantage of features provided by
of multiple streams to avoid head of line blocking, the support of SCTP, namely streaming-based transport, support of multiple streams
multi-homing to provide network level fault tolerance, as well as to avoid head of line blocking, the support of multi-homing to
partial reliability extension for partially reliable data provide network level fault tolerance, as well as partial reliability
transmission. Additionally, the support for datagram TLS is also extension for partially reliable data transmission. This document
discussed. also specifies how to establish GIST security over datagram transport
protocols using an extension to DTLS.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Message Association Setup . . . . . . . . . . . . . . . . 4 3.1. Message Association Setup . . . . . . . . . . . . . . . . 4
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 4 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5
3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5
3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6
3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 6 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 6
3.4.1. SendMessage . . . . . . . . . . . . . . . . . . . . . 6 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 6
3.4.2. NetworkNotification . . . . . . . . . . . . . . . . . 6 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 6
4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7
5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7
5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7
5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 8 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document describes the usage of the General Internet Signaling This document describes the usage of the General Internet Signaling
Transport (GIST) protocol [1] over the Stream Control Transmission Transport (GIST) protocol [1] over the Stream Control Transmission
Protocol (SCTP) [2]. Protocol (SCTP) [2].
GIST, in its initial specification for connection mode operation, GIST, in its initial specification for connection mode operation,
runs on top of a byte-stream oriented transport protocol providing a runs on top of a byte-stream oriented transport protocol providing a
reliable, in-sequence delivery, i.e., using the Transmission Control reliable, in-sequence delivery, i.e., using the Transmission Control
Protocol (TCP) [6] for signaling message transport. However, some Protocol (TCP) [7] for signaling message transport. However, some
NSLP context information has a definite lifetime, therefore, the GIST NSLP context information has a definite lifetime, therefore, the GIST
transport protocol could benefit from flexible retransmission, so transport protocol could benefit from flexible retransmission, so
stale NSLP messages that are held up by congestion can be dropped. stale NSLP messages that are held up by congestion can be dropped.
Together with the head-of-line blocking issue and other issues with Together with the head-of-line blocking issue and other issues with
TCP, these considerations argue that implementations of GIST should TCP, these considerations argue that implementations of GIST should
support the Stream Control Transport Protocol (SCTP)[2] as an support the Stream Control Transport Protocol (SCTP)[2] as an
optional transport protocol for GIST, especially if deployment over optional transport protocol for GIST, especially if deployment over
the public Internet is contemplated. Like TCP, SCTP supports the public Internet is contemplated. Like TCP, SCTP supports
reliability, congestion control and fragmentation. Unlike TCP, SCTP reliability, congestion control and fragmentation. Unlike TCP, SCTP
provides a number of functions that are desirable for signaling provides a number of functions that are desirable for signaling
transport, such as multiple streams and multiple IP addresses for transport, such as multiple streams and multiple IP addresses for
path failure recovery. In addition, its Partial Reliability path failure recovery. In addition, its Partial Reliability
extension (PR-SCTP) [3] supports partial retransmission based on a extension (PR-SCTP) [3] supports partial retransmission based on a
programmable retransmission timer. Furthermore, Datagram Transport programmable retransmission timer. Furthermore, Datagram Transport
Layer Security (DTLS) over SCTP [4] provides a viable solution for Layer Security (DTLS) [4] provides a viable solution for securing
securing SCTP. datagram transport protocols, e.g., by using DTLS over SCTP [5].
This document defines the use of SCTP as a transport protocol for This document defines the use of SCTP as a transport protocol and the
GIST Messaging Associations and discusses the implications on GIST use of DTLS as a security mechanism for GIST Messaging Associations
State Maintenance and API between GIST and NSLPs. Furturemore, this and discusses the implications on GIST State Maintenance and API
document shows how GIST SHOULD be used to provide the additional between GIST and NSLPs. Furthermore, this document shows how GIST
features offered by SCTP to deliver the GIST C-mode messages (which SHOULD be used to provide the additional features offered by SCTP to
can in turn carry NSIS Signaling Layer Protocol (NSLP) [7] messages deliver the GIST C-mode messages (which can in turn carry NSIS
as payload). More specifically: Signaling Layer Protocol (NSLP) [8] messages as payload). More
specifically:
o How to use the multiple streams feature of SCTP. o How to use the multiple streams feature of SCTP.
o How to use the PR-SCTP extention of SCTP. o How to use the PR-SCTP extention of SCTP.
o How to take advantage of the multi-homing support of SCTP. o How to take advantage of the multi-homing support of SCTP.
The method described in this document does not require any changes of The method described in this document does not require any changes of
GIST or SCTP. However, SCTP implementations MUST support the GIST or SCTP. However, SCTP implementations MUST support the
optional feature of fragmentation of SCTP user messages. optional feature of fragmentation of SCTP user messages.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [5]. Other document are to be interpreted as described in [6]. Other
terminologies and abbreviations used in this document are taken from terminologies and abbreviations used in this document are taken from
related specifications (e.g., [1] and [2]) as follows: related specifications (e.g., [1] and [2]) as follows:
o SCTP - Stream Control Transmission Protocol o SCTP - Stream Control Transmission Protocol
o PR-SCTP - SCTP Partial Reliability Extension o PR-SCTP - SCTP Partial Reliability Extension
o MRM - Message Routing Method o MRM - Message Routing Method
o MRI - Message Routing Information o MRI - Message Routing Information
o MRS - Message Routing State o MRS - Message Routing State
o SCD - Stack Configuration Data
o MA - A GIST Messaging Association is a single connection between o MA - A GIST Messaging Association is a single connection between
two explicitly identified GIST adjacent peers on the data path. A two explicitly identified GIST adjacent peers on the data path. A
messaging association may use a specific transport protocol and messaging association may use a specific transport protocol and
known ports. If security protection is required, it may use a known ports. If security protection is required, it may use a
specific network layer security association, or use a transport specific network layer security association, or use a transport
layer security association internally. A messaging association is layer security association internally. A messaging association is
bidirectional; signaling messages can be sent over it in either bidirectional; signaling messages can be sent over it in either
direction, and can refer to flows of either direction. direction, and can refer to flows of either direction.
o SCTP Association - A protocol relationship between SCTP endpoints, o SCTP Association - A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information. composed of the two SCTP endpoints and protocol state information.
skipping to change at page 6, line 25 skipping to change at page 6, line 29
support more flexible transport features for potential needs of support more flexible transport features for potential needs of
different NSLPs. different NSLPs.
3.4. API between GIST and NSLP 3.4. API between GIST and NSLP
GIST specification defines an abstract API between GIST and NSLPs. GIST specification defines an abstract API between GIST and NSLPs.
While this document does not change the API itself, the semantics of While this document does not change the API itself, the semantics of
some parameters have slightly different interpretation in the context some parameters have slightly different interpretation in the context
of SCTP. This section only lists those primitives and parameters, of SCTP. This section only lists those primitives and parameters,
that need special consideration when used in the context of SCTP. that need special consideration when used in the context of SCTP.
The relevant primitives are repeatet from [1] to improve readability, The relevant primitives from [1] are as follows:
but [1] remains authoritative. o The Timeout parameter in API "SendMessage": According to [1], this
parameter represents the "length of time GIST should attempt to
3.4.1. SendMessage send this message before indicating an error." When used with PR-
SCTP, this parameter is used as the timeout for the "timed
The SendMessage primitive is used by the NSLP to initiate sending of reliability" service of PR-SCTP.
messages. o "NetworkNotification": According to [1], this primitive "is passed
from GIST to a signalling application. It indicates that a
SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, network event of possible interest to the signalling application
NSLP-Id, Session-ID, MRI, occurred." Here, if SCTP detects a failure of the primary path,
SSI-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC ) GIST SHOULD also indicate this event to the NSLP by calling this
primitive with Network-Notification-Type "Routing Status Change".
The following parameter has changed semantics: This notification should be done even if SCTP was able to remain
an open connection to the peer due to its multi-homing
Timeout: According to [1] this parameter represents the "length of capabilities.
time GIST should attempt to send this message before indicating an
error". When used with SCTP, this parameter is also used as the
timeout for the "timed reliability" service of PR-SCTP.
3.4.2. NetworkNotification
The NetworkNotification primitive is passed from GIST to an NSLP. It
indicates that a network event of possible interest to the NSLP
occurred.
NetworkNotification ( MRI, Network-Notification-Type )
If SCTP detects a failure of the primary path, GIST SHOULD indicate
this event to the NSLP by calling the NetworkNotification primitive
with Network-Notification-Type "Routing Status Change". This
notification should be done even if SCTP was able to remain an open
connection to the peer due to its multi-homing capabilities.
4. Bit-Level Formats 4. Bit-Level Formats
4.1. MA-Protocol-Options 4.1. MA-Protocol-Options
This section provides the bit-level format for the MA-protocol- This section provides the bit-level format for the MA-protocol-
options field that is used for SCTP protocol in the Stack- options field that is used for SCTP protocol in the Stack-
Configuration-Data object of GIST. Configuration-Data object of GIST.
0 1 2 3 0 1 2 3
skipping to change at page 8, line 18 skipping to change at page 8, line 5
Streaming support in SCTP is advantageous for GIST. It allows better Streaming support in SCTP is advantageous for GIST. It allows better
parallel processing, in particular by avoiding head of line blocking parallel processing, in particular by avoiding head of line blocking
issue in TCP. Since a same GIST MA may be reused by multiple issue in TCP. Since a same GIST MA may be reused by multiple
sessions, using TCP as transport GIST signaling messages belonging to sessions, using TCP as transport GIST signaling messages belonging to
different sessions may be blocked if another message is dropped. In different sessions may be blocked if another message is dropped. In
the case of SCTP, this can be avoided as different sessions having the case of SCTP, this can be avoided as different sessions having
different requirements can belong to different streams, thus a different requirements can belong to different streams, thus a
message loss or reordering in a stream will only affect the delivery message loss or reordering in a stream will only affect the delivery
of messages within that particular stream, and not any other streams. of messages within that particular stream, and not any other streams.
6. Security Considerations 6. Use of DTLS with GIST
The security considerations of both [1] and [2] apply. For securing The MA-Protocol-ID for DTLS denotes a basic use of datagram transport
GIST over SCTP channel, it is recommended to use DTLS [8], to take layer channel security, initially in conjunction with SCTP. It
the advantage of all the features provided by SCTP and its provides authentication, integrity and optionally replay protection
extensions. DTLS over SCTP is specified in [4]. The usage of DTLS for control packets. The use of DTLS for securing GIST over SCTP
for GIST over SCTP is similar to TLS for GIST as specified in [1], allows GIST to take the advantage of features provided by SCTP and
where a stack-proposal containing both MA-Protocol-IDs for SCTP and its extensions. Note replay protection is not available for DTLS
DTLS during the GIST handshake phase. over SCTP [5]. The usage of DTLS for GIST over SCTP is similar to
TLS for GIST as specified in [1], where a stack-proposal containing
both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake
phase.
7. IANA Considerations GIST message associations using DTLS may carry messages with transfer
attributes requesting confidentiality or integrity protection. The
specific DTLS version will be negotiated within the DTLS layer
itself, but implementations MUST NOT negotiate to protocol versions
prior to DTLS v1.0 and MUST use the highest protocol version
supported by both peers. GIST nodes supporting DTLS MUST be able to
negotiate the DTLS NULL and block cipher ciphers and SHOULD be able
to negotiate the new cipher suites. They MAY negotiate any mutually
acceptable ciphersuite that provides authentication, integrity, and
confidentiality. The same rules for negotiating TLS cipher suites as
specified in Section 5.7.3 of [1] apply.
Two new MA-Protocol-IDs (Forwards-SCTP and Fowards-DTLS) need to be No MA-protocol-options field is required for DTLS. The configuration
assigned, with a recommended values of 3 and 4. information for the transport protocol over which DTLS is running
(e.g. SCTP port number) is provided by the MA-protocol-options for
that protocol.
8. Acknowledgments 7. Security Considerations
The security considerations of [1], [2] and [4] apply. Following
[5], replay detection of DTLS over SCTP is not supported.
The usage of DTLS [4] for securing GIST over datagram transport
protocols MUST be implemented and SHOULD be used. An implementation
of GIST over SCTP with no PR-SCTP support MAY use TLS for its channel
security, when DTLS is not available between two GIST peers.
8. IANA Considerations
This specification extends [1] by introducing two additional MA-
Protocol-IDs:
+---------------------+------------------------------------------+
| MA-Protocol-ID | Protocol |
+---------------------+------------------------------------------+
| 3 | SCTP opened in the forwards direction |
| | |
| 4 | DTLS initiated in the forwards direction |
+---------------------+------------------------------------------+
9. Acknowledgments
The authors would like to thank John Loughney, Robert Hancock, Andrew The authors would like to thank John Loughney, Robert Hancock, Andrew
McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, and Michael McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, Lauri
Tuexen for their helpful suggestions. Liuhto, and Michael Tuexen for their helpful suggestions.
9. References 10. References
9.1. Normative References 10.1. Normative References
[1] Schulzrinne, H. and R. Hancock, "GIST: General Internet [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-16 (work in Signalling Transport", draft-ietf-nsis-ntlp-17 (work in
progress), July 2008. progress), October 2008.
[2] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, [2] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
September 2007. September 2007.
[3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad,
"Stream Control Transmission Protocol (SCTP) Partial Reliability "Stream Control Transmission Protocol (SCTP) Partial Reliability
Extension", RFC 3758, May 2004. Extension", RFC 3758, May 2004.
[4] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[5] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport
Layer Security for Stream Control Transmission Protocol", Layer Security for Stream Control Transmission Protocol",
draft-ietf-tsvwg-dtls-for-sctp-00 (work in progress), draft-ietf-tsvwg-dtls-for-sctp-00 (work in progress),
October 2008. October 2008.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 10.2. Informative References
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[7] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [8] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005. June 2005.
[8] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
Authors' Addresses Authors' Addresses
Xiaoming Fu Xiaoming Fu
University of Goettingen University of Goettingen
Institute of Computer Science Institute of Computer Science
Goldschmidtstr. 7 Goldschmidtstr. 7
Goettingen 37077 Goettingen 37077
Germany Germany
Email: fu@cs.uni-goettingen.de Email: fu@cs.uni-goettingen.de
skipping to change at page 10, line 4 skipping to change at page 10, line 28
Email: fu@cs.uni-goettingen.de Email: fu@cs.uni-goettingen.de
Christian Dickmann Christian Dickmann
University of Goettingen University of Goettingen
Institute of Computer Science Institute of Computer Science
Goldschmidtstr. 7 Goldschmidtstr. 7
Goettingen 37077 Goettingen 37077
Germany Germany
Email: mail@christian-dickmann.de Email: mail@christian-dickmann.de
Jon Crowcroft Jon Crowcroft
University of Cambridge University of Cambridge
Computer Laboratory Computer Laboratory
William Gates Building William Gates Building
15 JJ Thomson Avenue 15 JJ Thomson Avenue
Cambridge CB3 0FD Cambridge CB3 0FD
UK UK
Email: jon.crowcroft@cl.cam.ac.uk Email: jon.crowcroft@cl.cam.ac.uk
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 32 change blocks. 
98 lines changed or deleted 131 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/