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

[Xiaoming Fu <[e-mail]>]

Hi Lars,

please find v12 which attempts to address your comments to v10.  
Additional remarks below:

On 4/27/2010 12: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.
>    
Thanks for your comments. We had a native speaker checked.
> 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.
>    
Done.
>
> 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?
>    
Now, ipr="pre5378Trust200902" - hope this is fine.
>
> Section 1., paragraph 2:
>    
>>     definite lifetime, therefore, the GIST transport protocol could
>>      
>    Nit: s/definite/limited/
>    
Thanks, fixed.
>
> Section 1., paragraph 4:
>    
>>     between GIST and NSLPs.  Furthermore, this document descibes how GIST
>>      
>    Nit: s/descibes/describes/
>
>    
Fixed
> Section 1., paragraph 5:
>    
>>     the additional capabilties offered by SCTP to deliver GIST C-mode
>>      
>    Nit: s/capabilties/capabilities/
>
>
>    
Fixed
> 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..."
>
>    
Fixed.
> 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.")
>
>    
To keep the minimal semantics within this document, some of them are 
reproduced from the related specs. I fixed the ones which were not the same.
> Section 3.1.1., paragraph 2:
>    
>>     These information are main part of the Stack Configuration Data [1].
>>      
>    Nit: Suggestion: This information; These informations
>    
Fixed
>
> Section 3.1.1., paragraph 3:
>    
>>     This document adds Forwards-SCTP as another possible protocol option.
>>      
>    And it adds DTLS, no? Section 7.
>    
One sentence was added in the end of first paragraph of Section 3, about 
DTLS in Section 7.
>
> Section 3.2., paragraph 1:
>    
>>     functionality over TCP, this section dicusses the implications of
>>      
>    Nit: s/dicusses/discusses/
>
>    
Fixed
> 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?
>    
The path in SCTP here means a primary path (default time) and a 
secondary/alternative path (when failover). The text changed since v11 
mainly says, SCTP adds robustness to a non-GIST segment between two 
GIST/SCTP nodes (lets call them as GIST/SCTP endpoints here), due to its 
multihoming feature. If there are GIST nodes between these endpoint 
nodes, then the signaling needs to be done also in between these 
endpoints, upon the primary path's failure (by informing NSLP about the 
route change and initializing new NSLP signaling in the secondary SCTP 
path).

> Section 7., paragraph 2:
>    
>>     negotiate the DTLS NULL and block cipher ciphers and SHOULD be able
>>      
>    Nit: s/cipher ciphers/ciphers/
>
>    
Fixed
> 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].
>
>
>    
Fixed.

Thanks for your review again. Let me know if this is fine for you.
Best,
Xiaoming