Subject: [Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-strrst-12

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 30 Nov 2011 11:25:29 -0600

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-tsvwg-sctp-strrst-12
Reviewer: Vijay K. Gurbani
Review Date: Nov-30-2011
IETF LC End Date: Unknown
IESG Telechat date: Dec-01-2011

Summary: This draft is ready as an Proposed Standard.

Major issues: 0
Minor issues: 1
Nits/editorial comments: 2

Minor issue:
- S5, second paragraph --- "The procedures outlined in this section are
  designed so that the incoming side will always reset their stream
  sequence number first before the outgoing side which means the re-
  configuration request must always originate from the outgoing side."

  Here, I am not sure what "incoming" and "outgoing" side mean.  Both
  SCTP server and client will have an "incoming" side and "outgoing"
  side. So, which peer's outgoing side are we talking about?

Nits:
- Abstract (and same text is repeated in S1: Introduction):
  s/to the upper layer that this has been/
  to the application layer that the reset has been/

- Abstract:
  s/The applications that want this/Applications requiring this/

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 30 Nov 2011 21:19:55 +0100

> configuration request must always originate from the outgoing side."
A stream is unidirectional. So it is outgoing for one side, incoming
for the other. The outgoing side has to request the reset, the incoming
side will perform it and acknowledge that the reset has been performed and
then the outgoing side will also do the reset.
> side. So, which peer's outgoing side are we talking about?
It is not related to client or server. It is related to the unidirectional
stream. You could all the outgoing side the sender, the incoming side the receiver...
However, on for the unidirectional stream...
> to the application layer that the reset has been/
OK. Will be in the next rev.
> s/The applications that want this/Applications requiring this/
OK. Will be in the next rev.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 30 Nov 2011 15:10:17 -0600

> then the outgoing side will also do the reset.

OK, so let's see ... assume two hosts A and B with two unidrectional
streams open between them:

     --------- a' -------->
  A                         B
     <-------- b' ---------

a' is outgoing stream for A and incoming stream for B.
b' is outgoing stream for B and incoming stream for A.

What you are saying is that either A has to request a reset on a'
or B has to request a reset on b'.  In the worst possible case,
both A and B can request a reset on their respective streams
(A on a' and B on b') without leading to deadlock or a violation
of the protocol.  Yes?

If so, then this discussion at least makes it clear to me.  However,
I will leave it to you on whether or not to clarify this further
in the draft.  When I read the draft initially, I certainly had
enough doubts that resulted in this email exchange.

Thanks,

- vijay

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 30 Nov 2011 22:51:14 +0100

> b' is outgoing stream for B and incoming stream for A.
Correct.
> or B has to request a reset on b'.  In the worst possible case,
Correct.
> (A on a' and B on b') without leading to deadlock or a violation
Correct.
> enough doubts that resulted in this email exchange.
I understand. When rereading the sentence because of your mail,
I also think it is suboptimal, but could not come up with an improved
version right now. Let me see if I can improve it...

Best regards
Michael