Re: Review of GIST over SCTP and DTLS - updated

Hi Elwyn,

Thanks for your helpful comments. Feedbacks to your comments inline:

Elwyn Davies wrote:
> Hi.
> 
> Sorry this is bit late.  I reviewed draft-ietf-nsis-ntlp-sctp-07.
> 
> Comments:
> 
> Header: I guess this has to be experimental now.

Yes, fixed.
> 
> 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.

Yes, will include these text.
> 
> 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.

According to SCTP API specification 
(http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket), errors will be 
notified when detecting some problems and maybe notified via 
SCTP_PEER_ADDR_CHANGE (, SCTP_SEND_FAILED or SCTP_REMOTE_ERROR messages 
to the application.  For multi-homing scenario, when a destination 
address of a peer encounters a change, an SCTP_PEER_ADDR_CHANGE message 
may be sent to the application, to notify about the new primary address 
(primary path, in turn) or the (un)availability of different addresses.

If people agree, we can add a statement summarizing above to the ID.

These will be in line with the GIST spec:
"an error MUST be indicated to the local signalling application 
identifying the routing information for the message in question."
and complimenting with the notification when multihoming is applied.


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

Path-coupled signaling in this context is still valid: although multiple 
possible paths may be detected, at one time there is only one path as 
primary path per standard SCTP spec. Of course detecting multiple paths 
and choosing which one to transport NSIS messages is the job of SCTP 
itself, and GIST just needs to give SCTP instance with the desired 
message. I think this is clear, thus there may be no need for extra 
explanation.

> 
> 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

Yes, you're right.
> 
>      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.

Thanks for your suggestion. will update.
> 
> s1, last para: Do we describe SCTP as a datagram transport protocol?  I
> thought it was more sequenced packet, but I may be wrong.

We meant by DTLS is primarily a datagram secure protocol, but SCTP is a 
mixture of streaming and datagram transport + other feature. What about:

" This document also specifies how to establish GIST security using an 
extension to DTLS for use in combination with e.g., SCTP and UDP."

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

We added in a recent version, due to the request from several WG members 
in their reviews.
> 
> 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.
Ok - will fix.

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

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