Re: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10
Xiaoming Fu <fu@cs.uni-goettingen.de> Wed, 28 April 2010 21:47 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 3687A3A6886 for <nsis@core3.amsl.com>; Wed, 28 Apr 2010 14:47:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.042
X-Spam-Level:
X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 vFeMWcvAzTih for <nsis@core3.amsl.com>; Wed, 28 Apr 2010 14:47:17 -0700 (PDT)
Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by core3.amsl.com (Postfix) with ESMTP id A15DD3A687F for <nsis@ietf.org>; Wed, 28 Apr 2010 14:47:16 -0700 (PDT)
Received: from p5b03ae9a.dip.t-dialin.net ([91.3.174.154] helo=[192.168.0.189]) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <fu@cs.uni-goettingen.de>) id 1O7F5x-0007kd-GL; Wed, 28 Apr 2010 23:47:02 +0200
Message-ID: <4BD8ACF7.3050600@cs.uni-goettingen.de>
Date: Wed, 28 Apr 2010 23:47:35 +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: nsis@ietf.org
References: <3513_1272364860_ZZ0L1J00LDI706OX.00_004B9CA4-AB30-4107-80E0-E0986387A3C4@nokia.com> <4BD8847C.6060901@tkk.fi>
In-Reply-To: <4BD8847C.6060901@tkk.fi>
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
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 21:47:18 -0000
Hi Lars (and Jukka), Many thanks for your time and efforts. I just uploaded version 11 addressing your comments. Best, Xiaoming On 4/28/2010 8:54 PM, Jukka Manner wrote: > 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 > -- 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