Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
draft-ietf-tsvwg-sctp-strrst-13

[Ballot discuss]
The Gen-ART Review by Vijay Gurbani on 30-Nov-2011 raised one
  technical issue and a few editorial suggestions.  The technical
  issue deserves a respons.  Also, please consider the editorial
  comments.  The review can be found here:
 
  http://www.ietf.org/mail-archive/web/gen-art/current/msg06947.html

[Ballot comment]
I asked Ari Keränen to review this document, and he had a few comments:

The SSN & TSN abbreviations are never opened (with the abbreviation).


4.1.  Outgoing SSN Reset Request Parameter

      This field holds the length in bytes of the parameter; the value
      MUST be 16 + 2 * N.

Could clarify what is "N" (the number of streams, I suppose).


5.1.1.  Sender Side Procedures for the RE-CONFIG Chunk

    any request by the application for such service SHOULD be responded
    to with an appropriate error indicating the peer SCTP stack does not
    support the re-configuration extension.

Should this be made more explicit on what error to send?


8.2.  Six New Parameter Types

What is the IANA rule for making new assignments in this registry?

[Ballot comment]
This is a good document describing in clear terms a useful extension. I think it would have been valuable for authors defining protocols that run over SCTP, implementers writing code to implement such protocols and operators who deploy them to add text to the document describing the impact that this new feature has on existing protocols (like IPFIX for which SCTP is a mandatory transport) or future protocols that will use SCTP as transport.

[Ballot comment]
In Section 5.1.2:

  A1:  The sender MUST stop assigning new SSNs to new user data
        provided by the upper layer for the affected streams and queue
        it.  This is because it is not known whether the receiver of the
        request will accept or deny it and moreover, a lost request
        might cause an out-of-sequence error in a stream that the
        receiver is not yet prepared to handle.

Do the first and third instances of "it" refer to "new user data"? If so, for clarity I suggest changing them to "such data".

In Section 5.1.3:

  B2:  If the sender wants all incoming streams to be reset no Stream
        Numbers SHOULD be put into the Incoming SSN Reset Request
        Parameter.

I suggest "Stream Numbers SHOULD NOT". Also, why would an application override this SHOULD NOT?

[Ballot discuss]
The Gen-ART Review by Vijay Gurbani on 30-Nov-2011 raised one
  technical issue and a few editorial suggestions.  The technical
  issue deserves a respons.  Also, please consider the editorial
  comments.  The review can be found here:
 
  http://www.ietf.org/mail-archive/web/gen-art/current/msg06947.html

[Ballot comment]
The following phrase is used a couple of times in s4.*:

  This optional field, if included

maybe use 2119 language:

  This OPTIONAL field,

Also in s4.4:

  Either both optional fields

Maybe:

  Either both OPTIONAL fields

[Ballot comment]
- A reference for SCTP on 1st use would be better.

- section 7 typo: s/application must/applications must/ ?
(And is that a 2119 "must"?)

- I can use this to add up to 2^16 new streams? Wouldn't that be a
good DoS vector? Maybe add text that implementations might either
have a max-new-streams setting or else that they should react to
adding lots of streams?

IANA has questions.

Is section 8.2 really creating a new registry, or is it just making new
registrations in the existing Chunk Parameter Types registry? It appears
to be asking for the next available values there.

If it is creating a new registry, the IANA Considerations section needs
to specify the registration procedures, whether the registry should list
the values in decimal or hex or both, the maximum value, and whether
value 0 is reserved.

ACTION 1:

Upon approval of this document, IANA will register the following Chunk
Type at http://www.iana.org/assignments/sctp-parameters

TBD (130 suggested) Re-configuration Chunk (RE-CONFIG) [RFC-to-be]


ACTION 2:

Unclear whether request is for new registrations or new registry.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Stream Control Transmission Protocol (SCTP) Stream Reconfiguration) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'Stream Control Transmission Protocol (SCTP) Stream Reconfiguration'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-11-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-strrst/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-strrst/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

James Polk  is the Document Shepherd. I have
reviewed this version of the document, and believe this is ready to
forward to the IESG for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, key members of the WG have reviewed this document.

There are no concerns with this -12 version of this document.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No, I do not have concerns about this document progressing forward,
given the years the draft has been active.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No, there are no additional concerns. There is no IPR claims that I'm
aware of related to this document.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is WG consensus around this document, with other WG members
being silent. The nature of TSVWG is an open area WG, with now 7
primary topics of interest; very few efforts ever get 'strong' WG
consensus. That said, consensus was solidly behind this document with
no current objections or open comments to this doc.

(1.f) Has anyone threatened an appeal or otherwise indicated
extreme discontent? If so, please summarize the areas of conflict
in separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No, there was never any threat of appeal wrt this document.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

I have confidence the 2 warnings will be addressed during the
RFC-Editor process.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are split and robust.


(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

The are IANA registries clearly identified in their own well formed
section of the document.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes, I have verified there is no formal language such as XML
code, BNF rules, MIB definitions, etc. contained within this document.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

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.


James Polk is the document Shepherd. David Harrington is the
responsible Area Director.