Review of GIST over SCTP and DTLS

Hi.

Sorry this is bit late.  I reviewed draft-ietf-nsis-ntlp-sctp-07.

Comments:

Header: I guess this has to be experimental now.

Minor Issues:
s2, next to last para:  I don't think you can claim 'no changes to
GIST'.   The addition of SCTP and DTLS inevitably adds code to GIST, and
some changes to the API are envisaged also.  one might say:
    The methods of using an unchanged SCTP with GIST described in this
document do not require any changes to the high level
    operation and structure of GIST.  Addition of the new transport
options require additional interface code and configuration
    support to allow applications to exploit the additional transport
when appropriate.

s3.1.2:  As with other SCTP applications, part of the point of SCTP is
to conceal from the higher level application that a particular
connection has died.  SCTP should or might be able to keep roght on
running using other address pairs even if one link dies.  One shoudl be
clear here just what sort of error is going to be reflected back to the
NSLP.  I am not sure what the socket interface for SCTP does in various
citcumstances as I have never has the opportunity to make use of one.

s5.1:  Maybe one should discuss the meaning of path coupled in the face
of multipath routing! 

Editorial:
s1, para 2:
>    Furthermore, this document shows how GIST
>    SHOULD be used to provide the additional features offered by SCTP to
>    deliver the GIST C-mode messages
This doesn't sound quite right. As with the point (in minor issues)
about s1 (next to last para), GIST *does* have to be expanded to support
SCTP and DTLS.  and you are documenting how to use GIST when it has
SCTP/DTLS support, so

     Furthermore, this document descibes how GIST should be interfaced
to SCTP and used by NSLPs in order to exploit the
     additional capabilties offered by SCTP to deliver GIST C-mode
messages more effectively.

s1, last para: Do we describe SCTP as a datagram transport protocol?  I
thought it was more sequenced packet, but I may be wrong.

s2:  Do we actually need to copy the definitions of MRM. MRI, MRS and SCD?

s2, definition of SCTP Assocation: s/identified by the transport
addresses/identified by the set of transport addresses/

s3.1.1: Maybe mention that these go into the Stack Configuration Data.

s3.2, para 2: s/bi-direction/bi-directional/

s3.3, para 1: s/partial relaible messages/partially reliable messages/

s3.3, para 2: s/In a standard SCTP../With standard basic SCTP[2]../

s5.2: s/as transport GIST/as transport for GIST/

s11.2 [9]  The extensibility draft file name has changed.