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

"Vijay K. Gurbani" <vkg@bell-labs.com> Fri, 02 December 2011 20:34 UTC

Return-Path: <vkg@bell-labs.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFAA11E8083 for <gen-art@ietfa.amsl.com>; Fri, 2 Dec 2011 12:34:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.302
X-Spam-Level:
X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGYaQROlNHbo for <gen-art@ietfa.amsl.com>; Fri, 2 Dec 2011 12:34:23 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2E711E80E5 for <gen-art@ietf.org>; Fri, 2 Dec 2011 12:34:22 -0800 (PST)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pB2KXc5Z015418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Dec 2011 14:33:39 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pB2KXbYb025137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Dec 2011 14:33:37 -0600
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pB2KXXxf018727; Fri, 2 Dec 2011 14:33:34 -0600 (CST)
Message-ID: <4ED936E9.9040402@bell-labs.com>
Date: Fri, 02 Dec 2011 14:36:57 -0600
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Michael Tuexen <tuexen@fh-muenster.de>
References: <4ED66709.50304@bell-labs.com> <22C7D48E-485B-4333-B29A-DB16BCCD3626@fh-muenster.de> <4ED69BB9.4030001@bell-labs.com> <4369045C-3B5C-4310-BF67-D141A34498BB@fh-muenster.de>
In-Reply-To: <4369045C-3B5C-4310-BF67-D141A34498BB@fh-muenster.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Cc: gorry@erg.abdn.ac.uk, Wesley Eddy <wes@mti-systems.com>, draft-ietf-tsvwg-sctp-strrst@tools.ietf.org, "James M. Polk" <jmpolk@cisco.com>, General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-sctp-strrst-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2011 20:34:24 -0000

On 12/02/2011 02:11 AM, Michael Tuexen wrote:
> What about:
>
> <t>One important thing to remember about SCTP streams is that they
> are uni-directional. The endpoint for which a stream is an outgoing
> stream is called the outgoing side, the endpoint for which the
> stream is an incoming stream is called the incoming side.

Michael: I would reword the above as "The endpoint that originates
the SCTP connection (resulting the the associated stream) is the
outgoing side and the recipient of that SCTP connection becomes the
incoming side."

The rest of what you write below is fine.

> 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. These two issues have
> important ramifications upon how an SCTP endpoint might request that
> its incoming streams be reset. In effect it must ask the peer to
> start an outgoing reset procedure and once that request is
> acknowledged let the peer actually control the reset operation.</t>

Whether or not to include issue of glare, I will leave up to you.

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} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/