Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
RFC 6525

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Stream Control Transmission Protocol (SCTP) Stream Reconfiguration' to Proposed Standard (draft-ietf-tsvwg-sctp-strrst-13.txt)

The IESG has approved the following document:
- 'Stream Control Transmission Protocol (SCTP) Stream Reconfiguration'
  (draft-ietf-tsvwg-sctp-strrst-13.txt) as a Proposed Standard

This document is the product of the Transport Area Working Group.

The IESG contact persons are Wesley Eddy and David Harrington.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-strrst/


Technical Summary

Many applications that use SCTP want the ability to "reset" a stream.
The intention of resetting a stream is to set the numbering sequence
of the stream back to 'zero' with a corresponding notification to the
upper layer that this has been performed. The applications that want
this feature want it so that they can "re-use" streams for different
purposes but still utilize the stream sequence number so that the
application can track the message flows. Thus, without this feature,
a new use of an old stream would result in message numbers greater
than expected unless there is a protocol mechanism to "reset the
streams back to zero". This document also includes methods for
resetting the transport sequence numbers, adding additional streams
and resetting all stream sequence numbers.

Working Group Summary

Understanding that 'strong' consensus is nearly impossible in an open
area WG such as TSVWG, with 5-6 sub-groups within this WG divided
along technology focuses -- there is unwavering consensus in the WG
amongst interested parties to publish this document. It has been
reviewed by several people in the WG last call.

Document Quality

Only part of this document has been implemented to date in FreeBSD.
Other implementations are progressing, but their status is unknown at
this time.  There is interest in this document from other groups that
will use the features it provides.  The IETF IPFIX working group is one
example.

Personnel

James Polk <jmpolk@cisco.com> is the Document Shepherd, and
Wesley Eddy <wes@mti-systems.com> is the responsible AD.