draft-ietf-mmusic-media-loopback-07.txt   draft-ietf-mmusic-media-loopback-08.txt 
K. Hedayat K. Hedayat
Internet Draft Brix Networks Internet Draft Brix Networks
Expires: June 2008 P. Jones Expires: July 2008 P. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
A. Roychowdhury A. Roychowdhury
Hughes Hughes Systique Corp.
C. SivaChelvan C. SivaChelvan
Cisco Systems, Inc. Cisco Systems, Inc.
N. Stratton N. Stratton
BlinkMind, Inc.
November 2007 N. Venna
Brix Networks
January 2008
An Extension to the Session Description Protocol (SDP) for Media An Extension to the Session Description Protocol (SDP) for Media
Loopback Loopback
draft-ietf-mmusic-media-loopback-07 draft-ietf-mmusic-media-loopback-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 43 skipping to change at page 2, line 4
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." 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.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008).
Copyright (C) The IETF Trust (2007).
Abstract Abstract
The wide deployment of Voice over IP (VoIP), Real-time Text and The wide deployment of Voice over IP (VoIP), Real-time Text and
Video over IP services has introduced new challenges in managing Video over IP services has introduced new challenges in managing
and maintaining voice/real-time Text/video quality, reliability, and maintaining voice/real-time Text/video quality, reliability,
and overall performance. In particular, media delivery is an area and overall performance. In particular, media delivery is an area
that needs attention. One method of meeting these challenges is that needs attention. One method of meeting these challenges is
monitoring the media delivery performance by looping media back to monitoring the media delivery performance by looping media back to
the transmitter. This is typically referred to as "active the transmitter. This is typically referred to as "active
skipping to change at page 3, line 10 skipping to change at page 3, line 12
10.1 Offer for specific media loopback type..................15 10.1 Offer for specific media loopback type..................15
10.2 Offer for choice of media loopback type.................16 10.2 Offer for choice of media loopback type.................16
10.3 Offer for choice of media loopback type with 10.3 Offer for choice of media loopback type with
rtp-start-loopback...........................................17 rtp-start-loopback...........................................17
10.4 Response to INVITE request rejecting loopback media.....18 10.4 Response to INVITE request rejecting loopback media.....18
10.5 Response to INVITE request rejecting loopback media with 10.5 Response to INVITE request rejecting loopback media with
rtp-start-loopback...........................................18 rtp-start-loopback...........................................18
11. Security Considerations.....................................19 11. Security Considerations.....................................19
12. Implementation Considerations...............................20 12. Implementation Considerations...............................20
13. IANA Considerations.........................................20 13. IANA Considerations.........................................20
14. Acknowledgements............................................20 13.1 SDP Attributes..........................................20
15. Normative References........................................20 13.2 MIME Types..............................................21
14. Acknowledgements............................................31
15. Normative References........................................31
1. Introduction 1. Introduction
The overall quality, reliability, and performance of VoIP, The overall quality, reliability, and performance of VoIP,
Real-time Text and Video over IP services rely on the performance Real-time Text and Video over IP services rely on the performance
and quality of the media path. In order to assure the quality of and quality of the media path. In order to assure the quality of
the delivered media there is a need to monitor the performance of the delivered media there is a need to monitor the performance of
the media transport. One method of monitoring and managing the the media transport. One method of monitoring and managing the
overall quality of VoIP, Real-time Text and Video over IP Services overall quality of VoIP, Real-time Text and Video over IP Services
is through monitoring the quality of the media in an active is through monitoring the quality of the media in an active
skipping to change at page 5, line 7 skipping to change at page 5, line 7
Two new media attributes are defined: one indicates the type of Two new media attributes are defined: one indicates the type of
loopback and one indicates the mode of the loopback. loopback and one indicates the mode of the loopback.
5.1 Loopback Type Attribute 5.1 Loopback Type Attribute
The loopback type is a property media attribute with the following The loopback type is a property media attribute with the following
syntax: syntax:
a=loopback:<loopback-type> a=loopback:<loopback-type>
Following is the Augmented BNF [RFC2234] for loopback-type: Following is the Augmented BNF [RFC4234] for loopback-type:
loopback-type = loopback-type-choices | loopback-type-choice-3 loopback-type = loopback-type-choices | loopback-type-choice-3
loopback-choices = loopback-type-choice-1 | loopback-type-choice-2 loopback-choices = loopback-type-choice-1 | loopback-type-choice-2
| loopback-type-choice-1 1*space loopback-type-choice-2 | | loopback-type-choice-1 1*space loopback-type-choice-2 |
loopback-type-choice-2 1*space loopback-type-choice-1 loopback-type-choice-2 1*space loopback-type-choice-1
loopback-type-choice-1 = "rtp-pkt-loopback" loopback-type-choice-1 = "rtp-pkt-loopback"
loopback-type-choice-2 = "rtp-media-loopback" loopback-type-choice-2 = "rtp-media-loopback"
loopback-type-choice-3 = "rtp-start-loopback" loopback-type-choice-3 = "rtp-start-loopback"
The loopback type is used to indicate the type of loopback. The The loopback type is used to indicate the type of loopback. The
skipping to change at page 6, line 48 skipping to change at page 6, line 48
loopback-source: This attribute specifies that the sender is the loopback-source: This attribute specifies that the sender is the
media source and expects the receiver to act as a loopback-mirror. media source and expects the receiver to act as a loopback-mirror.
loopback-mirror: This attribute specifies that the receiver will loopback-mirror: This attribute specifies that the receiver will
mirror (echo) all received media back to the sender of the RTP mirror (echo) all received media back to the sender of the RTP
stream. No media is generated locally by the receiver for stream. No media is generated locally by the receiver for
transmission in the mirrored stream unless rtp-start-loopback is transmission in the mirrored stream unless rtp-start-loopback is
requested. requested.
<fmt> is a media format description. The format descrption has the <fmt> is a media format description. The format descrption has the
semantics as defined in section 5.14 of RFC 4566 [RFC2234]. When semantics as defined in section 5.14 of RFC 4566[RFC4566]. When
loopback-mode is specified as loopback-source, the media format loopback-mode is specified as loopback-source, the media format
corresponds to the RTP payload types the source is willing to send. corresponds to the RTP payload types the source is willing to send.
When loopback-mode is specified as loopback-mirror, the media When loopback-mode is specified as loopback-mirror, the media
format corresponds to the RTP payload types the mirror is willing format corresponds to the RTP payload types the mirror is willing
to receive. The payload types specified in m= line for a to receive. The payload types specified in m= line for a
loopback-source specify the payloads the source is willing to loopback-source specify the payloads the source is willing to
receive. Similarly, for the loopback-mirror these payload types receive. Similarly, for the loopback-mirror these payload types
specify the payloads it is willing to send. specify the payloads it is willing to send.
skipping to change at page 20, line 26 skipping to change at page 20, line 26
loopback-type attribute. In addition, for the loopback-mode loopback-type attribute. In addition, for the loopback-mode
attribute, all implementations of an offerer MUST at a minimum be attribute, all implementations of an offerer MUST at a minimum be
able to act as a loopback-source. All implementation MUST also at a able to act as a loopback-source. All implementation MUST also at a
minimum support the direct media loopback payload type. Remaining minimum support the direct media loopback payload type. Remaining
attribute values including rtp-media-loopback and attribute values including rtp-media-loopback and
rtp-start-loopback MAY be implemented in complete implementations rtp-start-loopback MAY be implemented in complete implementations
of this draft. of this draft.
13. IANA Considerations 13. IANA Considerations
There are no IANA considerations associated with this 13.1 SDP Attributes
specification.
This document defines three new media-level SDP attributes. IANA
has registered the following attributes:
Contact name: Kaynam Hedayat <khedayat@brixnet.com>.
Attribute name: "loopback".
Type of attribute: Media level.
Subject to charset: No.
Purpose of attribute: The 'loopback' attribute is used to
indicate the type of media loopback.
Allowed attribute values: The parameters to 'loopback' may be
one or more of "rtp-pkt-loopback,"
"rtp-media-loopback," and
"rtp-start-loopback". See section 5
of this document for syntax.
Contact name: Kaynam Hedayat <khedayat@brixnet.com>.
Attribute name: "loopback-source".
Type of attribute: Media level.
Subject to charset: No.
Purpose of attribute: The 'loopback-source' attribute
specifies that the sender is the media
source and expects the receiver to act
as a loopback-mirror.
Allowed attribute values: The parameter to 'loopback-source' is
a media format ("<fmt>") description
as defined in RFC 4566 Section 5.14.
Contact name: Kaynam Hedayat <khedayat@brixnet.com>.
Attribute name: "loopback-mirror".
Type of attribute: Media level.
Subject to charset: No.
Purpose of attribute: The 'loopback-mirror' attribute
specifies that the receiver will
mirror (echo) all received media back
to the sender of the RTP stream.
Allowed attribute values: The parameter to 'loopback-mirror' is
a media format ("<fmt>") description
as defined in RFC 4566 Section 5.14.
13.2 MIME Types
The IANA has registered the following MIME types:
13.2.1 audio/encaprtp
To: ietf-types@iana.org
Subject: Registration of MIME media type audio/encaprtp
MIME media type name: audio
MIME subtype name: encaprtp
Required parameters: none
Note that RFC 4855 [RFC4855] mandates that RTP payload
formats without a defined rate must define a rate
parameter as part of their MIME registration. The
payload format for Encapsulated RTP does not specify a
rate parameter. However, the rate for encapsulated
stream is equal to the rate of the stream being
mirrored.
Optional parameters: none
Encoding considerations: This format is only defined for
transport within the Real Time Transport protocol (RTP)
[RFC 3550]. Its transport within RTP is fully
specified in this document.
Security considerations: See Section 11 of this document.
Interoperability considerations: none
Published specification: This MIME type is described fully
within this document.
Applications which use this media type: Applications wishing
to monitor and ensure the quality of transport to the
edge of a given VoIP, Real-Time Text or Video Over IP
Service.
Additional information: none
Person & email address to contact for further information:
Kaynam Hedayat
Brix Networks
285 Mill Road
Chelmsford, MA 01824
US
EMail: khedayat@brixnet.com
Intended usage: COMMON
Author/Change controller: This registration is part of the
IETF registration tree.
RTP and SDP Issues: Usage of this format within RTP and the
Session Description Protocol (SDP) are fully specified
in this document.
13.2.2 video/encaprtp
To: ietf-types@iana.org
Subject: Registration of MIME media type video/encaprtp
MIME media type name: video
MIME subtype name: encaprtp
Required parameters: none
Note that RFC 4855 [RFC4855] mandates that RTP payload
formats without a defined rate must define a rate
parameter as part of their MIME registration. The
payload format for Encapsulated RTP does not specify a
rate parameter.
However, the rate for encapsulated stream is equal to
the rate of the stream being mirrored.
Optional parameters: none
Encoding considerations: This format is only defined for
transport within the Real Time Transport protocol (RTP)
[RFC 3550]. Its transport within RTP is fully
specified in this document.
Security considerations: See Section 11 of this document.
Interoperability considerations: none
Published specification: This MIME type is described fully
within this document.
Applications which use this media type: Applications wishing
to monitor and ensure the quality of transport to the
edge of a given VoIP, Real-Time Text or Video Over IP
Service.
Additional information: none
Person & email address to contact for further information:
Kaynam Hedayat
Brix Networks
285 Mill Road
Chelmsford, MA 01824
US
EMail: khedayat@brixnet.com
Intended usage: COMMON
Author/Change controller: This registration is part of the
IETF registration tree.
RTP and SDP Issues: Usage of this format within RTP and the
Session Description Protocol (SDP) are fully specified
in this document.
13.2.3 text/encaprtp
To: ietf-types@iana.org
Subject: Registration of MIME media type text/encaprtp
MIME media type name: text
MIME subtype name: encaprtp
Required parameters: none
Note that RFC 4855 [RFC4855] mandates that RTP payload
formats without a defined rate must define a rate
parameter as part of their MIME registration. The
payload format for Encapsulated RTP does not specify a
rate parameter. However, the rate for encapsulated
stream is equal to the rate of the stream being
mirrored.
Optional parameters: none
Encoding considerations: This format is only defined for
transport within the Real Time Transport protocol (RTP)
[RFC 3550]. Its transport within RTP is fully
specified in this document.
Security considerations: See Section 11 of this document.
Interoperability considerations: none
Published specification: This MIME type is described fully
within this document.
Applications which use this media type: Applications wishing
to monitor and ensure the quality of transport to the
edge of a given VoIP, Real-Time Text or Video Over IP
Service.
Additional information: none
Person & email address to contact for further information:
Kaynam Hedayat
Brix Networks
285 Mill Road
Chelmsford, MA 01824
US
EMail: khedayat@brixnet.com
Intended usage: COMMON
Author/Change controller: This registration is part of the
IETF registration tree.
RTP and SDP Issues: Usage of this format within RTP and the
Session Description Protocol (SDP) are fully specified
in this document.
13.2.4 application/encaprtp
To: ietf-types@iana.org
Subject: Registration of MIME media type
application/encaprtp
MIME media type name: application
MIME subtype name: encaprtp
Required parameters: none
Note that RFC 4855 [RFC4855] mandates that RTP payload
formats without a defined rate must define a rate
parameter as part of their MIME registration. The
payload format for Encapsulated RTP does not specify a
rate parameter. However, the rate for encapsulated
stream is equal to the rate of the stream being
mirrored.
Optional parameters: none
Encoding considerations: This format is only defined for
transport within the Real Time Transport protocol (RTP)
[RFC 3550]. Its transport within RTP is fully
specified in this document.
Security considerations: See Section 11 of this document.
Interoperability considerations: none
Published specification: This MIME type is described fully
within this document.
Applications which use this media type: Applications wishing
to monitor and ensure the quality of transport to the
edge of a given VoIP, Real-Time Text or Video Over IP
Service.
Additional information: none
Person & email address to contact for further information:
Kaynam Hedayat
Brix Networks
285 Mill Road
Chelmsford, MA 01824
US
EMail: khedayat@brixnet.com
Intended usage: COMMON
Author/Change controller: This registration is part of the
IETF registration tree.
RTP and SDP Issues: Usage of this format within RTP and the
Session Description Protocol (SDP) are fully specified
in this document.
13.2.5 audio/rtploopback
To: ietf-types@iana.org
Subject: Registration of MIME media type audio/rtploopback
MIME media type name: audio
MIME subtype name: rtploopback
Required parameters: none
Note that RFC 4855 [RFC4855] mandates that RTP payload
formats without a defined rate must define a rate
parameter as part of their MIME registration. The
payload format for Encapsulated RTP does not specify a
rate parameter. However, the rate for encapsulated
stream is equal to the rate of the stream being
mirrored.
Optional parameters: none
Encoding considerations: This format is only defined for
transport within the Real Time Transport protocol (RTP)
[RFC 3550]. Its transport within RTP is fully
specified in this document.
Security considerations: See Section 11 of this document.
Interoperability considerations: none
Published specification: This MIME type is described fully
within this document.
Applications which use this media type: Applications wishing
to monitor and ensure the quality of transport to the
edge of a given VoIP, Real-Time Text or Video Over IP
Service.
Additional information: none
Person & email address to contact for further information:
Kaynam Hedayat
Brix Networks
285 Mill Road
Chelmsford, MA 01824
US
EMail: khedayat@brixnet.com
Intended usage: COMMON
Author/Change controller: This registration is part of the
IETF registration tree.
RTP and SDP Issues: Usage of this format within RTP and the
Session Description Protocol (SDP) are fully specified
in this document.
13.2.6 video/rtploopback
To: ietf-types@iana.org
Subject: Registration of MIME media type video/rtploopback
MIME media type name: video
MIME subtype name: rtploopback
Required parameters: none
Note that RFC 4855 [RFC4855] mandates that RTP payload
formats without a defined rate must define a rate
parameter as part of their MIME registration. The
payload format for Encapsulated RTP does not specify a
rate parameter. However, the rate for encapsulated
stream is equal to the rate of the stream being
mirrored.
Optional parameters: none
Encoding considerations: This format is only defined for
transport within the Real Time Transport protocol (RTP)
[RFC 3550]. Its transport within RTP is fully
specified in this document.
Security considerations: See Section 11 of this document.
Interoperability considerations: none
Published specification: This MIME type is described fully
within this document.
Applications which use this media type: Applications wishing
to monitor and ensure the quality of transport to the
edge of a given VoIP, Real-Time Text or Video Over IP
Service.
Additional information: none
Person & email address to contact for further information:
Kaynam Hedayat
Brix Networks
285 Mill Road
Chelmsford, MA 01824
US
EMail: khedayat@brixnet.com
Intended usage: COMMON
Author/Change controller: This registration is part of the
IETF registration tree.
RTP and SDP Issues: Usage of this format within RTP and the
Session Description Protocol (SDP) [6] are fully
specified in this document.
13.2.7 text/rtploopback
To: ietf-types@iana.org
Subject: Registration of MIME media type text/rtploopback
MIME media type name: text
MIME subtype name: rtploopback
Required parameters: none
Note that RFC 4855 [RFC4855] mandates that RTP payload
formats without a defined rate must define a rate
parameter as part of their MIME registration. The
payload format for Encapsulated RTP does not specify a
rate parameter. However, the rate for encapsulated
stream is equal to the rate of the stream being
mirrored.
Optional parameters: none
Encoding considerations: This format is only defined for
transport within the Real Time Transport protocol (RTP)
[RFC 3550]. Its transport within RTP is fully
specified in this document.
Security considerations: See Section 11 of this document.
Interoperability considerations: none
Published specification: This MIME type is described fully
within this document.
Applications which use this media type: Applications wishing
to monitor and ensure the quality of transport to the
edge of a given VoIP, Real-Time Text or Video Over IP
Service.
Additional information: none
Person & email address to contact for further information:
Kaynam Hedayat
Brix Networks
285 Mill Road
Chelmsford, MA 01824
US
EMail: khedayat@brixnet.com
Intended usage: COMMON
Author/Change controller: This registration is part of the
IETF registration tree.
RTP and SDP Issues: Usage of this format within RTP and the
Session Description Protocol (SDP) [6] are fully
specified in this document.
13.2.8 application/rtploopback
To: ietf-types@iana.org
Subject: Registration of MIME media type
application/rtploopback
MIME media type name: application
MIME subtype name: rtploopback
Required parameters: none
Note that RFC 4855 [RFC4855] mandates that RTP payload
formats without a defined rate must define a rate
parameter as part of their MIME registration. The
payload format for Encapsulated RTP does not specify a
rate parameter. However, the rate for encapsulated
stream is equal to the rate of the stream being
mirrored.
Optional parameters: none
Encoding considerations: This format is only defined for
transport within the Real Time Transport protocol (RTP)
[RFC 3550]. Its transport within RTP is fully
specified in this document.
Security considerations: See Section 11 of this document.
Interoperability considerations: none
Published specification: This MIME type is described fully
within this document.
Applications which use this media type: Applications wishing
to monitor and ensure the quality of transport to the
edge of a given VoIP, Real-Time Text or Video Over IP
Service.
Additional information: none
Person & email address to contact for further information:
Kaynam Hedayat
Brix Networks
285 Mill Road
Chelmsford, MA 01824
US
EMail: khedayat@brixnet.com
Intended usage: COMMON
Author/Change controller: This registration is part of the
IETF registration tree.
RTP and SDP Issues: Usage of this format within RTP and the
Session Description Protocol (SDP) [6] are fully
specified in this document.
14. Acknowledgements 14. Acknowledgements
The authors wish to thank Nagarjuna Venna, Flemming Andreasen, Jeff The authors wish to thank Nagarjuna Venna, Flemming Andreasen, Jeff
Bernstein, Paul Kyzivat, and Dave Oran for their comments and Bernstein, Paul Kyzivat, and Dave Oran for their comments and
suggestions. suggestions.
15. Normative References 15. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
skipping to change at page 21, line 14 skipping to change at page 31, line 41
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R., [RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R.,
Duffield, N., Friedman, T., Hedayat, K., Sarac, K. Duffield, N., Friedman, T., Hedayat, K., Sarac, K.
and M. Westerlund, "RTP Control Protocol Extended and M. Westerlund, "RTP Control Protocol Extended
Reports (RTCP XR)", RFC 3611, November 2003. Reports (RTCP XR)", RFC 3611, November 2003.
[RFC2234] Crocker, P. Overell, "Augmented ABNF for Syntax [RFC4234] Crocker, P. Overell, "Augmented ABNF for Syntax
Specification: ABNF", RFC 2234, November 1997. Specification: ABNF", RFC 4234, October 2005.
[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.
[RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of [RFC2736] Handley, M., Perkins, C., "Guidelines for Writers of
RTP Payload Format Specifications", RFC 2736, BCP RTP Payload Format Specifications", RFC 2736, BCP
0036, December 1999. 0036, December 1999.
[RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio [RFC3551] Schulzrinne, H., Casner, S., "RTP Profile for Audio
and Video Conferences with Minimial Control", STD 65, and Video Conferences with Minimial Control", STD 65,
RFC 3551, July 2003. RFC 3551, July 2003.
[RFC4566] Handley, M., Jacobson, V., Perkins, C., "SDP: Session [RFC4566] Handley, M., Jacobson, V., Perkins, C., "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
Authors' Addresses Authors' Addresses
Kaynam Hedayat Kaynam Hedayat
Brix Networks Brix Networks
285 Mill Road 285 Mill Road
Chelmsford, MA 01824 Chelmsford, MA 01824
US US
Phone: +1 978 367 5611 Phone: +1 978 367 5611
EMail: khedayat@brixnet.com EMail: khedayat@brixnet.com
skipping to change at page 22, line 31 skipping to change at page 33, line 24
Cisco Systems, Inc. Cisco Systems, Inc.
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, TX 75082 Richardson, TX 75082
US US
Phone: +1 972 813 5224 Phone: +1 972 813 5224
EMail: chelliah@cisco.com EMail: chelliah@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
Nathan Stratton Nathan Stratton
BlinkMind, Inc.
2027 Briarchester Dr.
Katy, TX 77450
663 Salem St. Phone: +1 832 330 3810
Lynnfield, MA 01940
Phone: +1 410 908 7587
EMail: nathan@robotics.net EMail: nathan@robotics.net
URI: http://www.robotics.net/ URI: http://www.robotics.net/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
 End of changes. 14 change blocks. 
20 lines changed or deleted 542 lines changed or added

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