Re: Starting WGLC on draft-ietf-nsis-ntlp-sctp-05.txt

Hi all,

I just posted a latest update (v7) which hopefully addresses almost all 
(if not all) WGLC comments, including Roland's. Thanks for all your 
insightful reviews!

Additional remarks to Roland's comments below:

Roland Bless wrote:
> Section 1:
> *  In the introduction:
>    - not clear whether one should also mention
>      the advantage of message-oriented transport by SCTP instead of
>      using the byte stream oriented TCP where one must provide its own
>      framing mechanisms.
>    - not clear at the end of the 2nd paragraph whether DTLS over SCTP
>      is also in scope of the draft or not.
Fixed.

> *  typo s/extention/extension
Fixed.

> *  PR-SCTP seems to be contradicting to the C-mode (reliable) transport
>    requirements of GIST at first. This must be clarified.
C-mode does not need to be reliable: Per ntlp-17:
   Connection Mode (C-mode):  A mode of sending GIST messages directly
       between nodes using point-to-point messaging associations (see
       below).  Connection mode allows the re-use of existing transport
       and security protocols where such functionality is required.
But yes, PR-SCTP is used for delivering C-mode messages. Clarified

> Section 2:
> SCTP Association: it could be mentioned in parentheses that the
> transport addresses also contain the port number (same remark
> as in RFC 4960) or that for an SCTP endpoint the following holds:
>       All transport addresses used by an SCTP endpoint must use the same
>       port number, but can use multiple IP addresses.  A transport
>       address used by an SCTP endpoint must not be used by another SCTP
>       endpoint.  In other words, a transport address is unique to an
>       SCTP endpoint.
Ok
> 
> 
> Section 3.1.1:
> TLS as protocol specifier is not useful alone. It can only be specified
> together with another protocol, e.g., Forwards-TCP+TLS.

I think this is already clear from GIST spec itself, which we don't need 
to repeat here (?)
> 
> Section 3.1.2:
> "The destination information MUST..." it is not very clear which
> destination information is meant, should be clarified that the
> destination for establishing the SCTP association is meant here
> (or SCTP endpoint destination).

Fixed
> 
> Section 3.3.:
> It should be clarified under which circumstances the reliability
> requirements for GIST C-mode messages are still met when PR-SCTP
> is used. As far as I understood, the "timed reliability"
> service is only one potential/special use case of PR-SCTP.
Added clarification.
> 
> Section 5.1:
> To me it makes sense for the path-coupled MRI to limit the available
> SCTP transport addresses to exactly the one from the NLI, so that
> only this IP address is used for establishing the SCTP association.
> This should also be mentioned in Section 3.1.2.

Any text suggestion? The main concern is that a path-coupled MRI 
contains only one interface-address field?
       The interface-address must be routable, i.e. it MUST be usable as
       a destination IP address for packets to be sent back to the node
       generating the signalling message, whether in D-mode or C-mode. 
[ntlp-17]

> 
> Section 6:
> "For securing _a_ GIST over SCTP channel"
> A little bit too short to discuss DTLS over SCTP. Forwards-DTLS
> should be mentioned and motivated and why TLS+SCTP would be different.
> It is not clear to me whether DTLS over SCTP is still "reliable".
> DTLS would qualify as being secure but not reliable (GIST would require
> to establish an MA for this, but I guess it also implies C-mode =>
> reliability?).
clarified
> 
> And finally:
> What about NAT traversal issues with SCTP? IMHO there should be a short
> section on discussing this. Can one simply use the NAT traversal object
> of GIST etc.? Is there anything special?
Tentatively added one section 6 (may be moved as subsection 5.3): 
however I'm not sure whether this is too heavy to have such section in 
this document. Any comments from other WG members?

Xiaoming