Re: AD review: draft-ietf-nsis-ntlp-sctp-10

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