Re: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10
Lars Eggert <lars.eggert@nokia.com> Thu, 29 April 2010 10:13 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 BC7DB28C28F for <nsis@core3.amsl.com>; Thu, 29 Apr 2010 03:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.419
X-Spam-Level:
X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, 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 1Ufz4qal1CEs for <nsis@core3.amsl.com>; Thu, 29 Apr 2010 03:13:24 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4CCDD3A691C for <nsis@ietf.org>; Thu, 29 Apr 2010 03:13:00 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o3TACM9f009490; Thu, 29 Apr 2010 05:12:28 -0500
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Apr 2010 13:12:18 +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); Thu, 29 Apr 2010 13:12:17 +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 o3TACGkT029758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Apr 2010 13:12:17 +0300
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: multipart/signed; boundary="Apple-Mail-9-23461433"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <4BD8ACF7.3050600@cs.uni-goettingen.de>
Date: Thu, 29 Apr 2010 13:12:01 +0300
Message-Id: <5971873F-46D7-49B6-8863-B42E28BFCA48@nokia.com>
References: <3513_1272364860_ZZ0L1J00LDI706OX.00_004B9CA4-AB30-4107-80E0-E0986387A3C4@nokia.com> <4BD8847C.6060901@tkk.fi> <4BD8ACF7.3050600@cs.uni-goettingen.de>
To: Xiaoming Fu <fu@cs.uni-goettingen.de>
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]); Thu, 29 Apr 2010 13:12:06 +0300 (EEST)
X-OriginalArrivalTime: 29 Apr 2010 10:12:17.0740 (UTC) FILETIME=[7292C0C0:01CAE784]
X-Nokia-AV: Clean
Cc: "nsis@ietf.org" <nsis@ietf.org>
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: Thu, 29 Apr 2010 10:13:25 -0000
Hi, On 2010-4-29, at 0:47, Xiaoming Fu wrote: > Many thanks for your time and efforts. I just uploaded version 11 > addressing your comments. I checked -11 and there are still some issues. Since you posted the new revision without any attempt at explaining the changes you made, you won't be surprised that I still believe some of them are not addressed. >>> This document would benefit from being proof-read by a native >>> speaker. Still true. >>> 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? No change. If you want to leave it as-is, have you confirmed with all contributors that they sign over the rights to the trust? See the RFC. >>> 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..." This now says something like "SCTP over GIST", a phrase you also use elsewhere. This is obviously incorrect. >>> 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.") You simply removed the terminology. Other options were to update the terms definitions so they are in line with [1] and [2], and optionally pulling in more terms so that the document is self contained. Is the WG in agreement that this is the best solution? >>> Section 3.1.1., paragraph 2: >>>> These information are main part of the Stack Configuration Data >>>> [1]. >>> >>> Nit: Suggestion: This information; These informations Changed, but the new text is still grammatically wrong. >>> 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? There are text changes in -11, but I don't see how they address the point I raised. Lars
- [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