Subject: Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started

From: Lothar Braun <[email-masked]>
Date: Tue, 29 Mar 2011 17:52:06 +0200

Hi,

I used the last few hours to read through the discussion on sctp-strrst, and the posting from Randy Stewart (quoted at the end of the mail) seems to be a good summary of the discussion.

And I'm now wondering if there are any objections against the ADD stream feature in the draft. From my point of view, as someone who is not a transport layer export, I don't see any objections against this part of the draft after reading it.
Does someone have arguments against the add stream feature?

Considering the past discussion, there seems to be some time necessary to reach consensus on the reset feature. Am I getting this right?
I'm now wondering if anyone can estimate how long it will take to address all the open issues and reach an consensus? 

If we look at the IPFIX WG, we can see that draft-ietf-ipfix-export-per-sctp-stream-08 has been sitting on the RFC editor queue for over eight months (https://datatracker.ietf.org/wg/ipfix/). I think it shouldn't sit there much longer. 

Can there be a discussion at the WG meeting on thursday, on how to get the add stream feature into PS status if people agree that draft-ietf-tsvwg-sctp-strrst needs a lot more time in order to be finished?

If thursdays' discussion concludes that there is a significant time necessary to complete the draft due to the reset feature, can sctp-strrst be split in two parts?

1.) sctp-add-stream -> get it ready as fast as possible
2.) sctp-reset-stream -> discuss open issues, take the time that is necessary to reach the necessary rough consensus.

Best regards,
  Lothar

> Kacheong:
> 
> I see a large number of responses here... most
> from you, Michael and a few from Tom/Benoit and Brian.
> 
> How I assess statements on the list (correct me if you
> feel I have interpreted your statements on the list wrong) are
> as follows:
> 
> 1) You are definitely against anything but the add feature
>    and you are ok with the current out-of-band mechanisms.
> 
> 2) Tom wished we had reve'd the spec one more time with the
>    his previous comments, is not sure of the use case for any
>    of it but sees value in it possibly. Would like to see more
>    comments on Brian's thoughts...
> 
> 3) Beniot needs the ADD stream for IPFIX and wants it out :-)
> 
> 4) Brian likes the idea of stream reconfiguration and thinks
>    we have not gone far enough (no delete stream) and would like
>    to see the mechanism changed to do all this to be "in-band". 
> 
> 5) Michael Peter and I (not surprisingly) are in favor of the document
>    as it is.... of course I am not sure how much authors count in all
>    of this ;-)
> 
> 
> So I think, in my assessment, you are the only one speaking against
> everything (except the ADD)...
> 
> My 2Cents ;-)
> 
> R
--
Lothar Braun
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18010       Fax: +49 89 289-18033
E-mail: [email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 30 Mar 2011 12:34:53 +0800

> 2.) sctp-reset-stream ->  discuss open issues, take the time that is necessary to reach the necessary rough consensus.

I agree that the above separation is a good way to move forward.
AFAICT, no one has mentioned anything concrete that the SSN and
TSN/SSN reset are used anywhere right now and must move forward
as a PS.  There is no urgent need and I suggest that folks to
think harder before moving forward.

-- 

					K. Poon.
					[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Wed, 30 Mar 2011 02:33:37 -0400

Question for you Kacheong:

Did you get my email on the use-case draft?

I don't see it went to tsvwg for some reason (I seem to
be having some mail problems sigh)..

There is now a draft:

draft-stewart-tsvwg-reconfuse-sctp

That talks about uses.. its a bit drafty yet.. and I am
hoping my co-authors will add some more text (I whipped it together
quickly)..

Best wishes

R

-----
Randall Stewart
[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 30 Mar 2011 15:02:24 +0800

> Did you get my email on the use-case draft?

Yes.  But I have not yet checked it out.

-- 

					K. Poon.

---

From: Randy Stewart <[email-masked]>
Date: Wed, 30 Mar 2011 03:10:45 -0400

Lothar:

The problem I have with this approach is that this draft
has been around a LONG LONG time. No discussion was ever
made UNTIL we did a LC.... which is sad commentary on things.

If we separate it we will surely end up with one small piece of reconfiguration
moving forward and the rest just sitting with no comments... which seems to be the
usual situation

Right now as I count things we have:

10 different people that have commented on the list... something like the
following
                       FOR      AGAINST       DoesNotCare

ADD-STR                10          0           0
SSN-RESET               7          1           2
TSN/SSN-RESET           6          1           3

Note: FOR also includes folks that have said "we can take it out later
if no one uses it going to Draft Standard"... (Note I am counting you
as a "don't care").

Also Note: there are a couple of folks that would like both an in-band mechanism
in addition to the out-of-band mechanism... and even more I think there is
at least two that would even like to see a DELETE-STR... 

Of course the "use case" draft that was just published may or may-not change
some opinions... even though it is not complete and a bit drafty...

I see no reason that this cannot move forward... Has Tom as pointed out, if no one
uses/implements a feature when we move to Draft standard we can remove it.... I see no reason
why the draft as it sits cannot move forward..

We may need to have further discussion on in-band vs out-of-band... I am not sure on
that. For all I know Brian as a method to do ADD-Str in-band... If not I think it just
adds more work.. but thats a separate discussion.

R

-----
Randall Stewart
[email-masked]

---

From: Lothar Braun <[email-masked]>
Date: Wed, 30 Mar 2011 09:59:29 +0200

Hi Randy,

> 10 different people that have commented on the list... something like the

Please note that I'm not requesting the split of the document. I just wanted to say, that there should be a discussion on splitting *IF* we can see that moving sctp-strrst to PS will take quite some time because of the reset-feature. 
And your figures seem to indicate that there is a consensus on moving it to PS.

> if no one uses it going to Draft Standard"... (Note I am counting you

Please move me into the FOR group. I think the draft should progress into PS including the reset-feature.

Best regards,
  Lothar

---

From: Randy Stewart <[email-masked]>
Date: Wed, 30 Mar 2011 04:19:04 -0400

Lothar:

Ok thanks.. its a bit late to correct my slides for tsvwg.. but I
will note that the numbers have changed..

Thanks

R

-----
Randall Stewart
[email-masked]

---

From: "Becke, Martin" <[email-masked]>
Date: Wed, 30 Mar 2011 08:24:30 +0000

I have been reviewing the draft RFC:

   Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
                  draft-ietf-tsvwg-sctp-strrst-09.txt

I think the RFC is useful.
To make it short  (for the presentation):

ADD-STR                FOR +1
SSN-RESET             FOR +1
TSN/SSN-RESET           DoesNotCare+1

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag
> von Randy Stewart
> Gesendet: Mittwoch, 30. März 2011 09:11
> An: Lothar Braun
> Cc: [email-masked]
> Betreff: Re: wglc FOR draft-ietf-tsvwg-sctp-strrst-09 started
> 
> Lothar:
> 
> The problem I have with this approach is that this draft has been around a
> LONG LONG time. No discussion was ever made UNTIL we did a LC.... which
> is sad commentary on things.
> 
> If we separate it we will surely end up with one small piece of
> reconfiguration moving forward and the rest just sitting with no comments...
> which seems to be the usual situation
> 
> Note: FOR also includes folks that have said "we can take it out later if no
> one uses it going to Draft Standard"... (Note I am counting you as a "don't
> care").
> 
> Also Note: there are a couple of folks that would like both an in-band
> mechanism in addition to the out-of-band mechanism... and even more I
> think there is at least two that would even like to see a DELETE-STR...
> 
> Of course the "use case" draft that was just published may or may-not
> change some opinions... even though it is not complete and a bit drafty...
> 
> 
> I see no reason that this cannot move forward... Has Tom as pointed out, if
> no one uses/implements a feature when we move to Draft standard we can
> remove it.... I see no reason why the draft as it sits cannot move forward..
> 
> We may need to have further discussion on in-band vs out-of-band... I am
> not sure on that. For all I know Brian as a method to do ADD-Str in-band... If
> not I think it just adds more work.. but thats a separate discussion.
> 
> R
> 
> 
> > I used the last few hours to read through the discussion on sctp-strrst, and
> the posting from Randy Stewart (quoted at the end of the mail) seems to be
> a good summary of the discussion.
> >
> > And I'm now wondering if there are any objections against the ADD stream
> feature in the draft. From my point of view, as someone who is not a
> transport layer export, I don't see any objections against this part of the
> draft after reading it.
> > Considering the past discussion, there seems to be some time necessary to
> reach consensus on the reset feature. Am I getting this right?
> > I'm now wondering if anyone can estimate how long it will take to address
> all the open issues and reach an consensus?
> >
> > If we look at the IPFIX WG, we can see that draft-ietf-ipfix-export-per-sctp-
> stream-08 has been sitting on the RFC editor queue for over eight months
> (https://datatracker.ietf.org/wg/ipfix/). I think it shouldn't sit there much
> longer.
> >
> > Can there be a discussion at the WG meeting on thursday, on how to get
> the add stream feature into PS status if people agree that draft-ietf-tsvwg-
> sctp-strrst needs a lot more time in order to be finished?
> >
> > If thursdays' discussion concludes that there is a significant time necessary
> to complete the draft due to the reset feature, can sctp-strrst be split in two
> parts?
> >
> >> I see a large number of responses here... most from you, Michael and
> >> a few from Tom/Benoit and Brian.
> >>
> >> How I assess statements on the list (correct me if you feel I have
> >> interpreted your statements on the list wrong) are as follows:
> >>
> > Chair for Network Architectures and Services (I8) Department of
> > Informatics Technische Universität München Boltzmannstr. 3, 85748
> > Garching bei München, Germany

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 30 Mar 2011 16:29:47 +0800

> made UNTIL we did a LC.... which is sad commentary on things.

There can be many interpretations.  One is that nobody cares
about this.  So does it make sense to have a PS which nobody
cares?  And IMHO it is sad that although the draft has been
around for quite some time, it still does not contain a
substantial argument that the mechanism is needed.

> moving forward and the rest just sitting with no comments... which seems to be the

So the draft has one mechanism which is used and requested.
And some other mechanisms which are not in use and requested
are "bundled" together with that.  Because of this bundling,
which does not seem to be necessary technically, all of them
must move together. Is it the correct approach?

Suppose the two are separated and as you said and the TSN/SSN
reset mechanism just sits there without further comments.
Does this fact say something that this mechanism is not
needed after all?

Can the WG chairs comment on this?  This seems to me to be
the wrong approach in moving forward a mechanism as a PS.
And IMHO, there is really not enough discussion from the
transport level design perspective in justifying such a
mechanism.  I think it is pre-mature to have a LC on this
mechanism and move it as a PS.

-- 

					K. Poon.

---

From: "t.petch" <[email-masked]>
Date: Wed, 30 Mar 2011 13:00:55 +0200

----- Original Message -----
From: "Kacheong Poon" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 30, 2011 6:34 AM
> > I used the last few hours to read through the discussion on sctp-strrst, and
the posting from Randy Stewart (quoted at the end of the mail) seems to be a
good summary of the discussion.
> > And I'm now wondering if there are any objections against the ADD stream
feature in the draft. From my point of view, as someone who is not a transport
layer export, I don't see any objections against this part of the draft after
reading it.
> >
> > If we look at the IPFIX WG, we can see that
draft-ietf-ipfix-export-per-sctp-stream-08 has been sitting on the RFC editor
queue for over eight months (https://datatracker.ietf.org/wg/ipfix/). I think it
shouldn't sit there much longer.
> >
> > Can there be a discussion at the WG meeting on thursday, on how to get the
add stream feature into PS status if people agree that
draft-ietf-tsvwg-sctp-strrst needs a lot more time in order to be finished?
> >
> > If thursdays' discussion concludes that there is a significant time
necessary to complete the draft due to the reset feature, can sctp-strrst be
split in two parts?
> > 2.) sctp-reset-stream ->  discuss open issues, take the time that is
necessary to reach the necessary rough consensus.
> think harder before moving forward.

I have a concern about the amount of work carving out a subset of
an existing I-D and producing a coherent result.

Perhaps you would consider producing a
draft-poon-tsvwg-sctp-changestream-00
in line with your proposal.

Tom Petch