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

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