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

[Michael Tüxen <[e-mail]>]

Hi Tom,

please see my comments in-line.

Best regards
Michael

On Sep 7, 2010, at 12:59 PM, t.petch wrote:

> 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.
OK, I put the  examples in an Annex and added a sentence that it is only informational.
We can also take them out...
We can also move the Socket API considerations to an Annex since it is also only
informational.
> 
> So my structure would be a new section 3 of Overview, 2-3 pages, then the
I think the introduction covers the provided functionality. Some I'm
not sure what to write about in 2-3 pages. I'm also not sure if your
comment still applies to the current version, but if it does, could you
provide text?
> 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.
All other SCTP RFC defined the packets formats before describing the procedures.
I'm happy to change the order if the WG wants it, but I personally prefer
defining objects before using them (might be related to being a mathematician).

But as I said: If the WG want a different permutation of the sections, I'll
incorporate that.
> 
> Just a thought:-)
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Michael Tüxen" <[e-mail]>
> To: "t.petch" <[e-mail]>
> Cc: <[e-mail]>; "Benoit Claise" <[e-mail]>;
> <[e-mail]>
> Sent: Monday, September 06, 2010 9:29 PM
> Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-05.txt
> 
> 
> On Sep 6, 2010, at 7:08 PM, t.petch wrote:
> 
>> ----- Original Message -----
>> From: "Gorry Fairhurst" <[e-mail]>
>> To: "Benoit Claise" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Wednesday, September 01, 2010 7:15 PM
>> 
>>> 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.
>> 
>> 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?
> Sure.
> 
> Best regards
> Michael
>> 
>> Tom Petch
>>> 
>>> 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.
>>>> 
>>> 
>> 
>> 
> 
>