Re: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10
Jukka Manner <jukka.manner@tkk.fi> Wed, 28 April 2010 18:55 UTC
Return-Path: <jukka.manner@tkk.fi>
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 B886528C122 for <nsis@core3.amsl.com>; Wed, 28 Apr 2010 11:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.184
X-Spam-Level:
X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[AWL=-0.185, 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 k058xl3qzxaK for <nsis@core3.amsl.com>; Wed, 28 Apr 2010 11:55:23 -0700 (PDT)
Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by core3.amsl.com (Postfix) with ESMTP id B055A28C12D for <nsis@ietf.org>; Wed, 28 Apr 2010 11:55:18 -0700 (PDT)
Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id o3SIt3kp010145 for <nsis@ietf.org>; Wed, 28 Apr 2010 21:55:03 +0300
Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 26516-1118 for <nsis@ietf.org>; Wed, 28 Apr 2010 21:55:03 +0300 (EEST)
Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id o3SIsvdA010109 for <nsis@ietf.org>; Wed, 28 Apr 2010 21:54:57 +0300
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 214B61E0C1 for <nsis@ietf.org>; Wed, 28 Apr 2010 21:54:57 +0300 (EEST)
X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi
Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OsSizC+1NIFl for <nsis@ietf.org>; Wed, 28 Apr 2010 21:54:52 +0300 (EEST)
Received: from [192.168.100.46] (a91-152-186-160.elisa-laajakaista.fi [91.152.186.160]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 774ED1E15A for <nsis@ietf.org>; Wed, 28 Apr 2010 21:54:52 +0300 (EEST)
Message-ID: <4BD8847C.6060901@tkk.fi>
Date: Wed, 28 Apr 2010 21:54:52 +0300
From: Jukka Manner <jukka.manner@tkk.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre
MIME-Version: 1.0
To: nsis@ietf.org
References: <3513_1272364860_ZZ0L1J00LDI706OX.00_004B9CA4-AB30-4107-80E0-E0986387A3C4@nokia.com>
In-Reply-To: <3513_1272364860_ZZ0L1J00LDI706OX.00_004B9CA4-AB30-4107-80E0-E0986387A3C4@nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi
Subject: Re: [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: Wed, 28 Apr 2010 18:55:24 -0000
Thanks, Lars. Authors, please update the draft as soon as possible and resubmit. cheers, Jukka On 04/27/2010 01:40 PM, Lars Eggert wrote: > 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 mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis -- Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+470 22481 Aalto University Mobile: +358+(0)50+5112973 Department of Communications Fax: +358+(0)9+470 22474 and Networking (Comnet) Office: G320a (Otakaari 5A) P.O. Box 13000, FIN-00076 Aalto E-mail: jukka.manner@tkk.fi Finland www.netlab.hut.fi/~jmanner/
- [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