[NSIS] Review of GIST over SCTP and DTLS
Elwyn Davies <elwynd@dial.pipex.com> Wed, 10 February 2010 19:26 UTC
Return-Path: <elwynd@dial.pipex.com>
X-Original-To: nsis@core3.amsl.com
Delivered-To: nsis@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6774D3A7087 for <nsis@core3.amsl.com>; Wed, 10 Feb 2010 11:26:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.163
X-Spam-Level:
X-Spam-Status: No, score=-101.163 tagged_above=-999 required=5 tests=[AWL=1.436, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0pHXpMIHbaP for <nsis@core3.amsl.com>; Wed, 10 Feb 2010 11:26:31 -0800 (PST)
Received: from b.painless.aaisp.net.uk (b.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by core3.amsl.com (Postfix) with ESMTP id 2948E3A73B5 for <nsis@ietf.org>; Wed, 10 Feb 2010 11:26:31 -0800 (PST)
Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[81.187.254.247]) by b.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <elwynd@dial.pipex.com>) id 1NfIDr-0001OW-I6; Wed, 10 Feb 2010 19:27:39 +0000
Message-ID: <4B730942.3040404@dial.pipex.com>
Date: Wed, 10 Feb 2010 19:30:10 +0000
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: nsis <nsis@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Xiaoming Fu <fu@cs.uni-goettingen.de>
Subject: [NSIS] Review of GIST over SCTP and DTLS
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsis>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2010 19:26:32 -0000
Hi. Sorry this is bit late. I reviewed draft-ietf-nsis-ntlp-sctp-07. Comments: Header: I guess this has to be experimental now. Minor Issues: s2, next to last para: I don't think you can claim 'no changes to GIST'. The addition of SCTP and DTLS inevitably adds code to GIST, and some changes to the API are envisaged also. one might say: The methods of using an unchanged SCTP with GIST described in this document do not require any changes to the high level operation and structure of GIST. Addition of the new transport options require additional interface code and configuration support to allow applications to exploit the additional transport when appropriate. s3.1.2: As with other SCTP applications, part of the point of SCTP is to conceal from the higher level application that a particular connection has died. SCTP should or might be able to keep roght on running using other address pairs even if one link dies. One shoudl be clear here just what sort of error is going to be reflected back to the NSLP. I am not sure what the socket interface for SCTP does in various citcumstances as I have never has the opportunity to make use of one. s5.1: Maybe one should discuss the meaning of path coupled in the face of multipath routing! Editorial: s1, para 2: > Furthermore, this document shows how GIST > SHOULD be used to provide the additional features offered by SCTP to > deliver the GIST C-mode messages This doesn't sound quite right. As with the point (in minor issues) about s1 (next to last para), GIST *does* have to be expanded to support SCTP and DTLS. and you are documenting how to use GIST when it has SCTP/DTLS support, so Furthermore, this document descibes how GIST should be interfaced to SCTP and used by NSLPs in order to exploit the additional capabilties offered by SCTP to deliver GIST C-mode messages more effectively. s1, last para: Do we describe SCTP as a datagram transport protocol? I thought it was more sequenced packet, but I may be wrong. s2: Do we actually need to copy the definitions of MRM. MRI, MRS and SCD? s2, definition of SCTP Assocation: s/identified by the transport addresses/identified by the set of transport addresses/ s3.1.1: Maybe mention that these go into the Stack Configuration Data. s3.2, para 2: s/bi-direction/bi-directional/ s3.3, para 1: s/partial relaible messages/partially reliable messages/ s3.3, para 2: s/In a standard SCTP../With standard basic SCTP[2]../ s5.2: s/as transport GIST/as transport for GIST/ s11.2 [9] The extensibility draft file name has changed.
- [NSIS] Review of GIST over SCTP and DTLS Elwyn Davies