Re: Review of GIST over SCTP and DTLS - updated

Hi all,

I have submitted a new version (v09), which has been verified by Elwyn 
to address his comments; it also fixed some other minor issues. Thanks a 
lot for Elwyn and other reviewers for your valuable inputs!

http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-09.txt

Cheers,
Xiaoming

Xiaoming Fu wrote:
> 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