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

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

_______________________________________________
nsis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nsis