BFCPBIS Working Group                                  Ram.
Internet Engineering Task Force (IETF)                   R. Ravindranath
Internet-Draft
Request for Comments: 8124                                  G. Salgueiro
Intended status:
Category: Standards Track                                          Cisco
Expires: August 10, 2017                                February 6,
ISSN: 2070-1721                                               March 2017

                 The Session Description Protocol (SDP)
                   WebSocket Connection URI Attribute
                    draft-ietf-bfcpbis-sdp-ws-uri-09

Abstract

   The WebSocket protocol enables bidirectional real-time communication
   between clients and servers in web-based applications.  This document
   specifies extensions to Session Description Protocol (SDP) for
   application protocols using WebSocket as a transport.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 10, 2017.
   http://www.rfc-editor.org/info/rfc8124.

Copyright Notice

   Copyright (c) 2017 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.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2 ....................................................2
   2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3 .....................................................3
   3. SDP Considerations  . . . . . . . . . . . . . . . . . . . . .   3 ..............................................3
      3.1. General . . . . . . . . . . . . . . . . . . . . . . . . .   3 ....................................................3
      3.2.  websocket-uri "websocket-uri" SDP Attribute . . . . . . . . . . . . . . .   3 ..............................4
      3.3.  websocket-uri "websocket-uri" Multiplexing Considerations . . . . . . . .   4 ................4
   4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . .   4 .....................................5
      4.1. General . . . . . . . . . . . . . . . . . . . . . . . . .   4 ....................................................5
      4.2. Generating the Initial Offer  . . . . . . . . . . . . . .   5 ...............................5
      4.3. Generating the Answer . . . . . . . . . . . . . . . . . .   5 ......................................6
      4.4. Offerer Processing of the Answer  . . . . . . . . . . . .   6 ...........................7
      4.5. Modifying the Session . . . . . . . . . . . . . . . . . .   6 ......................................7
      4.6. Offerless INVITE Scenarios  . . . . . . . . . . . . . . .   7 .................................8
   5. Procedures at WebSocket Client  . . . . . . . . . . . . . . .   7 ..................................8
   6. Security Considerations . . . . . . . . . . . . . . . . . . .   7 .........................................9
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8 .............................................9
      7.1. Registration of the 'websocket-uri' "websocket-uri" SDP Media Attribute .   8 ....9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1. .....................................................10
      8.1. Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2. ......................................10
      8.2. Informative References  . . . . . . . . . . . . . . . . .   9 ....................................10
   Acknowledgements ..................................................12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10 ................................................12

1.  Introduction

   The WebSocket protocol [RFC6455] enables bidirectional message
   exchange between clients and servers on top of a persistent TCP
   connection (optionally secured with Transport Layer Security (TLS)
   [RFC5246]).  The initial protocol handshake makes use of Hypertext
   Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket
   protocol to reuse existing HTTP infrastructure.

   Modern web browsers include a WebSocket client stack compliant with
   the WebSocket API [WS-API] as specified by the W3C.  It is expected
   that other client applications (e.g., those running on personal
   computers, mobile devices, etc.) will also make a WebSocket client
   stack available.  Several specifications have been written that
   define how different applications can use a WebSocket subprotocol as
   a reliable transport mechanism.

   For example, [RFC7118] defines a WebSocket subprotocol as a reliable
   transport mechanism between Session Initiation Protocol
   (SIP)[RFC3261] entities to enable use of SIP in web-oriented
   deployments.  Additionally, [RFC7977] defines a new WebSocket sub-
   protocol
   subprotocol as a reliable transport mechanism between Message Session
   Relay Protocol (MSRP) clients and relays.  [RFC7395] defines a
   WebSocket subprotocol for the Extensible Messaging and Presence
   Protocol (XMPP).  Similarly, [I-D.ietf-bfcpbis-bfcp-websocket] [BFCP-WEBSOCKET] defines a WebSocket sub-protocol
   subprotocol as a reliable transport mechanism between Binary Floor
   Control Protocol (BFCP)
   [I-D.ietf-bfcpbis-rfc4582bis] [BFCP] entities to enable usage of BFCP in
   new scenarios.

   When a WebSocket sub-protocol subprotocol is used as a transport mechanism between
   a server and client, there needs to be a way to indicate the
   connection URI from the Server server to the WebSocket Client. client.  For
   applications that use Session Description Protocol (SDP) [RFC4566] to
   negotiate, the connection URI can be indicated by means of an SDP
   attribute.  This specification defines new SDP attributes to indicate
   the connection URI for the WebSocket client.  Applications that use
   SDP for negotiation and WebSocket as a transport protocol can use
   this specification to advertise the WebSocket client connection URI.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

3.  SDP Considerations

3.1.  General

   Applications that use the SDP Offer/Answer mechanism [RFC3264] for
   negotiating media and also use WebSocket or secure WebSocket as a
   transport protocol MAY indicate the connection URI for the WebSocket
   Client
   client via a new SDP a= "a=" media-level attribute defined in
   Section 3.2.

3.2.  websocket-uri  "websocket-uri" SDP Attribute

   This section defines a new SDP media-level attribute, "websocket-uri" "websocket-
   uri", which can appear in any of the media sections.

   Example:

      a=websocket-uri:wss://example.com/chat

   Where "wss://example.com/chat" is the ws-URI defined in Section 3 of
   [RFC6455].

   When the "websocket-uri" attribute is present in the media section of
   the SDP, the IP address in 'c= ' "c=" line SHALL be ignored and the full
   URI SHALL be used instead to open the WebSocket connection.  The
   clients MUST ensure that they use the URI to open the webSocket WebSocket
   connection and ignore the IP address in 'c=' the "c=" line and the port in m=
   the "m=" line.

3.3.  websocket-uri  "websocket-uri" Multiplexing Considerations

   Multiplexing characteristics of SDP attributes are described in
   [I-D.ietf-mmusic-sdp-mux-attributes].
   [SDP-MUX].  Various SDP attribute multiplexing categories are
   introduced there.

   o  The multiplexing category of the "a=websocket-uri:" "a=websocket-uri" attribute is
      CAUTION.

   There are no multiplexing rules specified for the "websocket-uri" SDP
   media-level attribute.  Additionally, the specification of
   multiplexing rules for the 'websocket-uri'attribute "websocket-uri" attribute is outside the
   scope of this document.

   While it is technically possible to bundle WebSocket, there are a
   variety of reasons that make it impractical and impractical; thus, it is thus considered
   unlikely to be used in practice.  Therefore, the "websocket-uri" SDP
   media-level attribute defined in Section 3.2 for using WebSocket as a
   transport protocol is not likely to be used with SDP bundle and is
   consequently categorized as CAUTION for multiplexing.

   If future extensions define how to bundle WebSocket WebSocket, then
   multiplexing rules for the "a=websocket-uri:" "a=websocket-uri" attribute need to be
   defined as well, for instance instance, in an extension of this SDP based
   WebSocket negotiation specification.

4.  SDP Offer/Answer Procedures

4.1.  General

   An endpoint (i.e., both the offerer and the answerer) that wishes to
   negotiate WebSocket as transport protocol MUST indicate that it
   wishes to use WebSocket or secure WebSocket in the "proto" field of
   the "m=" line.  Furthermore, the server side, which could be either
   the offerer or answerer, MUST add an "a=websocket-uri" attribute in
   the media section whose value can be either "ws-URI" or "wss-URI" "wss-URI", as
   defined in Section 3 [RFC6455] of [RFC6455], depending on whether it wishes to
   use WebSocket or secure WebSocket.  This new attribute MUST follow
   the syntax defined in Section 3.  The procedures in this section
   apply to an "m=" line associated with any media stream that uses
   WebSocket or secure WebSocket as transport.

   Both offerer or answerer can initiate a webSocket WebSocket connection.  It is
   expected that that, based on the topology (for example, if the client is
   behind NAT and server is on global IP address) address), the offerer and
   answers
   answerer applications decides decide on who will initiate the webSocket WebSocket
   connection and appropriately set the "setup" attribute in SDP
   following the procedures of [RFC4145].

4.2.  Generating the Initial Offer

   An SDP offerer in

   In order to negotiate WebSocket as a transport transport, an SDP offerer MUST
   indicate the same that it wishes to use it in the "proto" field of the "m="
   line.  For example, to negotiate BFCP-over-WebSocket BFCP-over-WebSocket, the "proto"
   value in the "m=" line is TCP/WSS/BFCP if WebSocket is over TLS, else TLS;
   else, it is
   TCP/WS/BFCP TCP/WS/BFCP, as specified in [I-D.ietf-bfcpbis-bfcp-websocket]. [BFCP-WEBSOCKET].

   The offerer SHOULD assign the SDP "setup" attribute with a value of
   "active" (the offerer will be the initiator of the outgoing TCP
   connection) or "passive" if the offerer wishes to be a receiver of an
   incoming connection.  The offerer MUST NOT assign an SDP "setup"
   attribute with a "holdconn" value.  The offerer MUST follow the
   procedures described in [RFC4145]  while using the "setup" attribute.
   If the "setup" attribute has a value "passive" of "passive", it MUST have a URI
   in the "a=websocket-uri" attribute.

   The following is an example of an "m=" line for a BFCP connection:

   Offer (browser):
   m=application 9 TCP/WSS/BFCP *
   a=setup:active
   a=connection:new
   a=floorctrl:c-only
   m=audio 55000 RTP/AVP 0
   m=video 55002 RTP/AVP 31

   In the above example, the client is intending to setup set up the TLS /TCP
   connection and hence TLS/TCP
   connection; hence, the port is set to a value of 9, which is the
   discard port.

4.3.  Generating the Answer

   If the answerer accepts the offered WebSocket transport connection,
   in the associated SDP answer, the answerer MUST assign an SDP "setup"
   attribute with a value of either "active" or "passive", according to
   the procedures in [RFC4145].  The answerer MUST NOT assign an SDP
   "setup" attribute with a value of "holdconn".

   If the answerer assigns an SDP "setup" attribute with a value of
   "active", the answerer MUST initiate the WebSocket connection
   handshake by acting as client on the negotiated media stream, towards
   the URI specified in the "a=websocket-uri" SDP attribute using the
   procedures described in Section 4 of [RFC6455].

   If the answers answerer assigns an SDP "setup" attribute with a value of
   "passive", then it MUST have a value of "ws-URI" or "wss-URI" "wss-URI", as
   defined in Section 3 of [RFC6455] in an "a=websocket-uri" SDP attribute
   attribute, depending on whether the application uses WebSocket or secureWebSocket.
   secure WebSocket.  This attribute MUST follow the syntax defined in
   Section 3.

   The following example shows a case where the server responds with a
   BFCP media stream over a WebSocket connection running TLS.  It shows
   an answer "m=" line for the BFCP connection.  In this example example, since
   WebSockets
   WebSocket is running over TLS, the server answers back with an
   "a=websocket-uri" attribute in the media section of SDP having a
   "wss-URI" connection URI:

   Answer (server):
   m=application 50000 TCP/WSS/BFCP *
   a=setup:passive
   a=connection:new
   a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312
   a=floorctrl:s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 m-stream:10
   a=floorid:2 m-stream:11
   m=audio 50002 RTP/AVP 0
   a=label:10
   m=video 50004 RTP/AVP 31
   a=label:11

4.4.  Offerer Processing of the Answer

   When the offerer receives an SDP answer, if the offerer ends up being
   active
   initiating the TCP connection, then it MUST follow the procedures in
   Section 5.

4.5.  Modifying the Session

   Once an offer/answer exchange has been completed, either endpoint MAY
   send a new offer in order to modify the session.  The endpoints can
   reuse the existing WebSocket connection by adding an
   "a=connection:existing" attribute in the media section of the SDP
   following the rules mentioned in [RFC4145] [RFC4145], if the "websocket-uri"
   SDP value and the transport parameters indicated by each endpoint are
   unchanged.  Otherwise, following the rules for the initial offer/
   answer exchange, the endpoints can negotiate and create a new
   WebSocket connection on top of TLS/TCP or TCP.

4.6.  Offerless INVITE Scenarios

   In some scenarios scenarios, an endpoint (e.g., a browser) originating the call
   (UAC)
   (a User Agent Client or UAC) can send an offerless INVITE to the
   server.  The server will generate an offer in response to the INVITE.
   In such cases cases, the server MUST send an offer with setup the "setup"
   attribute as with a value of "passive" so as to accept incoming
   connection and MUST include an "a=websocket-uri" attribute in the
   media section whose value MUST be either "ws-URI" or
   "wss-URI" "wss-URI",
   depending on whether the server wishes to use WebSocket or secure
   WebSocket.  The SDP offer sent by the server will look like the
   example in Section 4.3.

5.  Procedures at WebSocket Client

   The webSocket WebSocket client MUST always initiate the outgoing TCP connection
   and hence
   connection; hence, the SDP a=setup "setup" attribute MUST be always be "active"
   for the WebSocket client in its SDP offer/answer.  In the below example, example
   below, the WebSocket client is the offerer and hence offerer; hence, it assigns a
   "setup" attribute with a value of "active".

   The WebSocket server is a server on the Internet and hence Internet; hence, it MUST
   always assign an SDP "setup" attribute with a value of "passive".
   This also avoids the need to use ICE Interactive Connectivity
   Establishment (ICE) between WebSocket Client client and WebSocket Server server, as
   the connection model here would be a typical
   client to server client-to-server web
   connection.

   Once the offer/answer is complete complete, the client MUST initiate the
   WebSocket connection handshake by sending a GET message on the
   negotiated media stream, towards the URI specified in "a=websocket-
   uri" an
   "a=websocket-uri" attribute, as per the procedures described in
   [RFC6455].  When no port is passed in the "a=websocket-uri"
   attribute, the default port (80 or 443) is used depending on whether
   the value has was "ws-URI" or "wss-
   URI". "wss-URI".

6.  Security Considerations

   An attacker may attempt to add, modify, or remove "a=websocket-uri" an "a=websocket-
   uri" attribute from a session description.  This could result in an
   application behaving undesirably.  Consequently, it is RECOMMENDED
   that integrity protection be applied to the SDP session descriptions.
   For session descriptions carried in SIP [RFC3261], S/MIME is
   available to provide such end-to-end integrity protection.

   As described in Section 10 of [RFC6455], application signalling
   traffic being transported over WebSocket MUST support secure
   WebSocket and SHOULD employ it when communicating with their peers.

   The WebSocket clients have to initiate the TCP connection to the
   WebSocket server identified by the FQDN Fully Qualified Domain Name (FQDN)
   in a=websocket-uri.  Further an "a=websocket-uri" attribute.  Further, as with any other web
   connection, the clients will verify the servers server's certificate.  The
   WebSocket client MUST follow the procedures in [RFC7525] (including hostname
   host name verification as per section Section 6.1 in [RFC7525]) while setting
   up a TLS connection with webSocket a WebSocket server.

7.  IANA Considerations

7.1.  Registration of the 'websocket-uri' "websocket-uri" SDP Media Attribute

   NOTE to RFC Editor: Please replace "XXXX" with the number of this
   RFC.

   This document defines a new SDP media-level attribute "websocket-uri"
   in Section 3.2 and requests that 3.2; IANA to register has registered the following SDP att-field under
   the Session "Session Description Protocol (SDP) Parameters Parameters" registry as
   follows:

   +---------------------+---------------------------------------------+
   | Attribute name:     | websocket-uri                               |
   | Long-form attribute | Websocket WebSocket Connection URI                    |
   | name:               |                                             |
   | Type of attribute:  | media                                       |
   | Mux category:       | CAUTION                                     |
   | Charset Dependent:  | No                                          |
   | Purpose:            | The 'websocket-uri' "websocket-uri" attribute is intended   |
   |                     | to be used as a connection URI for opening  |
   |                     | the WebSocket connection.                   |
   | Appropriate values: | A ws-URI  or wss-URI wss-URI, as defined in Section |
   |                     | 3 of [RFC6455]                              |
   | Contact name:       | Gonzalo Salgueiro                           |
   | Contact e-mail: email:      | gsalguei@cisco.com                          |
   | Reference:          | RFCXXXX RFC 8124                                    |
   +---------------------+---------------------------------------------+

8.  Acknowledgements

   Thanks to Christer Holmberg for raising the need for a BFCP-
   independent SDP attribute for WebSocket Connection URI.

   The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar,
   Christer Holmberg, Charles Eckel, Dan Wing, Alissa Cooper and Joel
   Halpern for their invaluable suggestions and review comments.

   Thanks to Mirja Kuehlewind, Alexey Melnikov, Ben Campbell and
   Kathleen Moriarty for their comments and feedback during IESG
   reviews.

9.  References

9.1.

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              DOI 10.17487/RFC4145, September 2005,
              <http://www.rfc-editor.org/info/rfc4145>.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, DOI 10.17487/RFC6455, December 2011,
              <http://www.rfc-editor.org/info/rfc6455>.

9.2.

8.2.  Informative References

   [I-D.ietf-bfcpbis-bfcp-websocket]

   [BFCP]     Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C.
              Eckel, "The Binary Floor Control Protocol (BFCP)", Work in
              Progress, draft-ietf-bfcpbis-rfc4582bis-16, November 2015.

   [BFCP-WEBSOCKET]
              Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., R, R., and S. Murillo, R.
              R, "The WebSocket Protocol as a Transport for the Binary
              Floor Control Protocol (BFCP)", draft-ietf-
              bfcpbis-bfcp-websocket-14 (work Work in progress), January Progress,
              draft-ietf-bfcpbis-bfcp-websocket-15, February 2017.

   [I-D.ietf-bfcpbis-rfc4582bis]
              Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C.
              Eckel, "The Binary Floor Control Protocol (BFCP)", draft-
              ietf-bfcpbis-rfc4582bis-16 (work in progress), November
              2015.

   [I-D.ietf-mmusic-sdp-mux-attributes]
              Nandakumar, S., "A Framework for SDP Attributes when
              Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16
              (work in progress), December 2016.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              DOI 10.17487/RFC3264, June 2002,
              <http://www.rfc-editor.org/info/rfc3264>.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
              July 2006, <http://www.rfc-editor.org/info/rfc4566>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC7118]  Baz Castillo, I., Millan Villegas, J., and V. Pascual,
              "The WebSocket Protocol as a Transport for the Session
              Initiation Protocol (SIP)", RFC 7118,
              DOI 10.17487/RFC7118, January 2014,
              <http://www.rfc-editor.org/info/rfc7118>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7395]  Stout, L., Ed., Moffitt, J., and E. Cestari, "An
              Extensible Messaging and Presence Protocol (XMPP)
              Subprotocol for WebSocket", RFC 7395,
              DOI 10.17487/RFC7395, October 2014,
              <http://www.rfc-editor.org/info/rfc7395>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC7977]  Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G.,
              and R. Ravindranath, "The WebSocket Protocol as a
              Transport for the Message Session Relay Protocol (MSRP)",
              RFC 7977, DOI 10.17487/RFC7977, September 2016,
              <http://www.rfc-editor.org/info/rfc7977>.

   [SDP-MUX]  Nandakumar, S., "A Framework for SDP Attributes when
              Multiplexing", Work in Progress, draft-ietf-mmusic-sdp-
              mux-attributes-16, December 2016.

   [WS-API]   W3C and I.   Hickson, I., Ed., "The WebSocket API", May 2012. W3C
              Candidate Recommendation, September 2012,
              <https://www.w3.org/TR/2012/CR-websockets-20120920/>.

Acknowledgements

   Thanks to Christer Holmberg for raising the need for a BFCP-
   independent SDP attribute for WebSocket Connection URI.

   The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar,
   Christer Holmberg, Charles Eckel, Dan Wing, Alissa Cooper, and Joel
   Halpern for their invaluable suggestions and review comments.

   Thanks to Mirja Kuehlewind, Alexey Melnikov, Ben Campbell, and
   Kathleen Moriarty for their comments and feedback during IESG
   reviews.

Authors' Addresses

   Ram Mohan Ravindranath
   Cisco Systems, Inc.
   Cessna Business Park,
   Kadabeesanahalli Village, Varthur Hobli,
   Sarjapur-Marathahalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: rmohanr@cisco.com

   Gonzalo Salgueiro
   Cisco Systems, Inc.
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   US
   United States of America

   Email: gsalguei@cisco.com