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

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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/nsis
>

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