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

[Randy Stewart <[e-mail]>]

Tom:

Thanks for the text..

Michael.. I think this could easily be worked into the introduction. We can
of course not get it in for the IETF.. but we will add it to our "todo" items.

If we LC this on the current version, we can just add this as a LC comment.. if 
not, we can spin out a version right after the IETF with this (and any other comments)
before LC.

Thanks for taking the time to read this Tom..

R
On Oct 26, 2010, at 3:55 AM, t.petch wrote:

> Michael,
> 
> Provide text, you say, so here is what I would have like to have read before
> getting into the nitty gritty of parameters.  I see this text as suitable for an
> introduction but if that is not the house style, then I would make it an
> Informative Appendix.
> 
> "The capabilities added by this document - reset a stream, reset SSN and TSN,
> add additional streams - are all sent as parameters of a Stream Reset Chunk.
> Four new parameters - Outgoing SSN Reset Request, Incoming SSN Reset Request,
> SSN/TSN Reset Request and Add Outgoing Streams Request convey the requests while
> Stream Reset Response provides the response.
> 
> Once a request has been made by a Stream Reset Chunk, the sender must await a
> response before sending a further request (or wait until the Stream Reset Timer
> expires).  Each Request contains a unique sequence number which is placed in the
> corresponding Response.
> 
> The Add Outgoing Streams and SSN/TSN Reset Request must be sent as the only
> parameter in the chunk whilst the Outgoing SSN Reset Request and Incoming SSN
> Reset Request may either be sent on their own, the two together, or, in the case
> of the Outgoing SSN Reset Request, in conjunction with a Stream Reset Response
> (which is responding to an Incoming SSN Reset Request).
> 
> The Incoming SSN Reset Request and Outgoing SSN Reset Request may either specify
> specific stream numbers or (by default) apply to all streams.
> 
> Where a request generates more than one parameter in response, all those
> parameters must be sent as part of the same Stream Reset Chunk."
> 
> 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, October 25, 2010 8:32 AM
> Subject: Re: I-D Action:draft-ietf-tsvwg-sctp-strrst-05.txt
> 
> 
> 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.
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 

-----
Randall Stewart
[e-mail]