Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-05.txt

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 01 Sep 2010 18:15:59 +0100

My understanding is that we need reviewers (or reviews).

A quick read seems to suggest the current draft may benefit from some 
editorial work before starting a WGLC ... I'm happy to offer comments to 
help this, but that doesn't remove the need for other people to step up 
as reviewers.

Offers please to WG Chairs and/or authors!

Gorry

>   Dear all,
> 
> I see in the minutes:
> 
>     Four IDs approaching WGLC:
>       - SCTP Stream Reconfiguration
>       - IANA procedures for ports and services
>       - SCTP Sockets
>       - SCTP Flag Chunks
> 
> Are we still waiting for something before starting the WGLC on this draft?
> 
> Regards, Benoit.
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Area Working Group Working Group of the IETF.
>>
>>
>> 	Title           : Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
>> 	Author(s)       : R. Stewart, et al.
>> 	Filename        : draft-ietf-tsvwg-sctp-strrst-05.txt
>> 	Pages           : 30
>> 	Date            : 2010-08-23
>>
>> Many applications that desire to use SCTP have requested the ability
>> to "reset" a stream.  The intention of resetting a stream is to start
>> the numbering sequence of the stream back at 'zero' with a
>> corresponding notification to the upper layer that this act as been
>> performed.  The applications that have requested this feature
>> normally desire it so that they can "re-use" streams for different
>> purposes but still utilize the stream sequence number for the
>> application to track the message flows.  Thus, without this feature,
>> a new use on an old stream would result in message numbers larger
>> than expected without a protocol mechanism to "start the streams back
>> at zero".  This documents presents also a method for resetting the
>> transport sequence numbers, adding additional streams and resetting
>> all stream sequence numbers.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-strrst-05.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>

---

From: "t.petch" <[email-masked]>
Date: Mon, 6 Sep 2010 19:08:53 +0200

----- Original Message -----
From: "Gorry Fairhurst" <[email-masked]>
To: "Benoit Claise" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 01, 2010 7:15 PM

> help this, but that doesn't remove the need for other people to step up

I see what you mean.  The challenge is how to communicate what is potentially a
large number of minor edits without expending large amounts of man power.  Thus
I could provide text in the usual form of /old/new/ in which case the
Introduction would be

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

Would that do the job?

Tom Petch

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 6 Sep 2010 21:29:39 +0200

> resetting  all stream sequence numbers.
Sure. 

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Sep 2010 14:32:47 -0600

t.petch,

Please see my edits to your introduction below...

t.petch wrote:                              (Mon, 06 Sep 2010 19:08:53)

> I see what you mean.  The challenge is
/how/whether/
> to communicate what is
/potentially/indeed/
> a large number of
/minor edits/nitpicks/
/without/and/
/expending large amounts of manpower/losing everone's attention/.
> This I could provide text in the usual form of /old/new/ in which case
> the Introduction would be:

;)

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "t.petch" <[email-masked]>
Date: Tue, 7 Sep 2010 12:59:36 +0200

Going from minutiae to the big picture, I find it easy to suggest changes for
the minutiae but much harder to understand - or not - the big picture.

I think that the I-D needs more of an introduction as to what is on offer, as
opposed to how to do it. It is the choice of operations that makes this so.
Thus, I think that Incoming SSN Reset Request Parameter MUST be acknowledged by
Outgoing SSN Reset Request Parameter (but the I-D does not quite say that
anywhere) and that anything else, such as Add Outgoing Streams Request
Parameter, is acknowledged by Stream Reset Response Parameter [sic].

And then there is the interaction of  Stream Reset Request Sequence Number and
Stream Reset Response Sequence Number   (and timers); ok, it is the usual sort
of request/response transport affair, but there are variations within this theme
and which are you using?  Perhaps a state machine would help.

I can reverse engineer the worked examples, but I do not think that I should
have to - and I think that the examples should be a Informative appendix.  As it
stands, 5.3 would appear to be Normative.

So my structure would be a new section 3 of Overview, 2-3 pages, then the
procedures of current Section 5, then the parameters themselves as in current
Section 4 but with the rules on the combinations of parameters from Section 3 at
the end.

Just a thought:-)

Tom Petch

----- Original Message -----
From: "Michael Tüxen" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "Benoit Claise" <[email-masked]>;
<[email-masked]>
Sent: Monday, September 06, 2010 9:29 PM
Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-05.txt

Sure.

Best regards
Michael

---

From: "t.petch" <[email-masked]>
Date: Tue, 7 Sep 2010 12:57:45 +0200

Some slightly more technical issues.

1) I am unclear on the semantics of the Stream Reset Request Sequence Number.
What is the scope of it? When is it increased? What happens if the value wraps
(unlikely but should be specified IMHO)?

2) Are there any recommendations for the value of the Stream Reset Timer?

3) Are there any recommendations for the delta in 5.1.5?

4) 5.1.6 talks of 'positive acknowledgment (Success)' but this language does not
appear in Table 3. Ditto 5.2.6 H5.

5) 5.2.2 E1 is any timer running during deferred reset processing?  Can it
endure for ever?

6) When an Outgoing SSN Reset Request Parameter is used as an acknowledgement,
are there any rules about the relationship between
the stream numbers listed in the initial Request and those in the Request
that is the acknowledgement?

7) 5.2.3 F1 Outgoing Stream Reset Request Parameter is not listed as a
parameter in s4.

8) 5.2.6 H3 Outgoing Stream Reset Request is not listed as a parameter in s4.

9) 3 talks of number being in Network Byte order except where noted; are there
any such notes?  I could not see one.

10) length fields could do with an explicit mention of units - byte(octet!) I
assume

Tom Petch

----- Original Message -----
From: "Michael Tüxen" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "Benoit Claise" <[email-masked]>;
<[email-masked]>