Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-sctp-10

From: Jukka Manner <[email-masked]>
Date: Wed, 28 Apr 2010 21:54:52 +0300

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
> [email-masked]
> 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: [email-masked]
Finland                           www.netlab.hut.fi/~jmanner/

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 28 Apr 2010 23:47:35 +0200

Hi Lars (and Jukka),

Many thanks for your time and efforts. I just uploaded version 11 
addressing your comments.

Best,
Xiaoming

-- 
Xiaoming Fu, http://user.informatik.uni-goettingen.de/~fu

---

From: Lars Eggert <[email-masked]>
Date: Thu, 29 Apr 2010 13:12:01 +0300

Hi,

> 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 

Still true.

>>>   first submitted before 10 November 2008.  Should you add the

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.

>>>   I think you mean "SCTP implementations *to transport GIST* MUST

This now says something like "SCTP over GIST", a phrase you also use elsewhere. This is obviously incorrect.

>>>   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?

>>>   Nit: Suggestion: This information; These informations

Changed, but the new text is still grammatically wrong.

>>>   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

---

From: Xiaoming Fu <[email-masked]>
Date: Thu, 29 Apr 2010 13:20:09 +0200

Sorry being in a hurry - will get a native proof-reader to review asap 
and also address the other issues you raised.
Xiaoming