Re: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10
Xiaoming Fu <fu@cs.uni-goettingen.de> Thu, 29 April 2010 11:20 UTC
Return-Path: <fu@cs.uni-goettingen.de>
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 F2FA128C279 for <nsis@core3.amsl.com>; Thu, 29 Apr 2010 04:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.949
X-Spam-Level:
X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35]
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 EBQP4w1jOoZF for <nsis@core3.amsl.com>; Thu, 29 Apr 2010 04:20:50 -0700 (PDT)
Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by core3.amsl.com (Postfix) with ESMTP id ADF4C3A6C77 for <nsis@ietf.org>; Thu, 29 Apr 2010 04:19:49 -0700 (PDT)
Received: from s5.ifi.informatik.uni-goettingen.de ([134.76.81.25] helo=[172.23.0.20]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <fu@cs.uni-goettingen.de>) id 1O7RmF-0007cv-MU; Thu, 29 Apr 2010 13:19:31 +0200
Message-ID: <4BD96B69.80407@cs.uni-goettingen.de>
Date: Thu, 29 Apr 2010 13:20:09 +0200
From: Xiaoming Fu <fu@cs.uni-goettingen.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@nokia.com>
References: <3513_1272364860_ZZ0L1J00LDI706OX.00_004B9CA4-AB30-4107-80E0-E0986387A3C4@nokia.com> <4BD8847C.6060901@tkk.fi> <4BD8ACF7.3050600@cs.uni-goettingen.de> <5971873F-46D7-49B6-8863-B42E28BFCA48@nokia.com>
In-Reply-To: <5971873F-46D7-49B6-8863-B42E28BFCA48@nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Authenticated: Id:xfu
X-Virus-Scanned: (clean) by exiscan+sophie
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 11:20:53 -0000
Sorry being in a hurry - will get a native proof-reader to review asap and also address the other issues you raised. Xiaoming On 4/29/2010 12:12 PM, Lars Eggert wrote: > 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 -- Xiaoming Fu, http://user.informatik.uni-goettingen.de/~fu
- [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