[NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10
Lars Eggert <lars.eggert@nokia.com> Tue, 27 April 2010 10:40 UTC
Return-Path: <lars.eggert@nokia.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 3879B3A6907 for <nsis@core3.amsl.com>; Tue, 27 Apr 2010 03:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.148
X-Spam-Level:
X-Spam-Status: No, score=-5.148 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 Y3Zsw0msp2K9 for <nsis@core3.amsl.com>; Tue, 27 Apr 2010 03:40:55 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 28DA63A6452 for <nsis@ietf.org>; Tue, 27 Apr 2010 03:40:55 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3RAe7Rg030945 for <nsis@ietf.org>; Tue, 27 Apr 2010 05:40:39 -0500
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 13:40:32 +0300
Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Apr 2010 13:40:32 +0300
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3RAeWAs031500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <nsis@ietf.org>; Tue, 27 Apr 2010 13:40:32 +0300
From: Lars Eggert <lars.eggert@nokia.com>
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96 at fit.nokia.com
Content-Type: multipart/signed; boundary="Apple-Mail-52--147638238"; protocol="application/pkcs7-signature"; micalg="sha1"
Date: Tue, 27 Apr 2010 11:40:21 +0100
Message-Id: <004B9CA4-AB30-4107-80E0-E0986387A3C4@nokia.com>
To: nsis@ietf.org
Mime-Version: 1.0 (Apple Message framework v1078)
X-Mailer: Apple Mail (2.1078)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Tue, 27 Apr 2010 13:40:22 +0300 (EEST)
X-OriginalArrivalTime: 27 Apr 2010 10:40:32.0620 (UTC) FILETIME=[0FF96AC0:01CAE5F6]
X-Nokia-AV: Clean
Subject: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10
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: Tue, 27 Apr 2010 10:40:59 -0000
SUMMARY: Basically ready; some nits remain. Note: Most comments marked as "nits" below have been automatically flagged by review scripts - there may be some false positives in there. This document would benefit from being proof-read by a native speaker. INTRODUCTION, paragraph 2: > General Internet Signaling Transport (GIST) over SCTP and Datagram TLS Please expand all acronyms on first use in title, header and document body. INTRODUCTION, paragraph 11: > Copyright Notice The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? Section 1., paragraph 2: > definite lifetime, therefore, the GIST transport protocol could Nit: s/definite/limited/ Section 1., paragraph 4: > between GIST and NSLPs. Furthermore, this document descibes how GIST Nit: s/descibes/describes/ Section 1., paragraph 5: > the additional capabilties offered by SCTP to deliver GIST C-mode Nit: s/capabilties/capabilities/ Section 1., paragraph 7: > In addition, SCTP implementations MUST support the optional feature > of fragmentation of SCTP user messages. I think you mean "SCTP implementations *to transport GIST* MUST support..." Section 2., paragraph 1: > Other > terminologies and abbreviations used in this document are taken from > related specifications (e.g., [1] and [2]) as follows: The definitions below are not all identical to those in [1] and [2]. (It's also not clear how useful the inclusion of those is here, since you need to read the defs in [1] and [2] anyway, to understand terms like "transport address.") Section 3.1.1., paragraph 2: > These information are main part of the Stack Configuration Data [1]. Nit: Suggestion: This information; These informations Section 3.1.1., paragraph 3: > This document adds Forwards-SCTP as another possible protocol option. And it adds DTLS, no? Section 7. Section 3.2., paragraph 1: > functionality over TCP, this section dicusses the implications of Nit: s/dicusses/discusses/ Section 5.1., paragraph 1: > In general, the multi-homing support of SCTP can be used to improve > fault-tolerance in case of a path- or link-failure. Thus, GIST over > SCTP would be able to deliver NSLP messages between peers even if the > primary path is not working anymore. However, for the Message > Routing Methods (MRMs) defined in the basic GIST specification such a > feature is only of limited use. The default MRM is path-coupled, > which means, that if the primary path is failing for the SCTP > association, it most likely is also for the IP traffic that is > signaled for. Thus, GIST would need to perform a refresh anyway to > cope with the route change. When the endpoints of the multi-homed > paths (instead of the nodes between them) support NSIS, GIST over > SCTP provides a robust means for GIST to deliver NSLP messages even > when some paths fail but at least one path is available. DISCUSS: I don't understand this scenario. The current MRMs are path-coupled; how can SCTP multihoming be applied to them? If the path fails, GIST should not deliver any messages anymore, no? Section 7., paragraph 2: > negotiate the DTLS NULL and block cipher ciphers and SHOULD be able Nit: s/cipher ciphers/ciphers/ Section 9., paragraph 1: > This specification extends [1] by introducing two additional MA- > Protocol-IDs: It does not extend [1]. It asks that the following codepoints be assigned in a registry created by [1].
- [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10 Lars Eggert
- Re: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10 Jukka Manner
- Re: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10 Xiaoming Fu
- Re: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10 Lars Eggert
- Re: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10 Xiaoming Fu
- Re: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10 Xiaoming Fu