Subject: [tsvwg] WGLC Follow-Up: draft-ietf-tsvwg-sctp-dtls-encaps

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 24 Jun 2014 14:28:36 +0100

The WGLC for the above document ended 28th February 2014, and follow-up 
discussions resulted in a revised draft.

I am now starting to prepare for submission of the above document for 
requested publication. Please find detailed comments/questions about the 
text below.

Best wishes,

Gorry Fairhurst.
(TSVWG Co-Chair)

---
ABSTRACT:
    "Using
    encapsulation method described in this document, SCTP is..."
   ^
- insert /the/ ?

---
ABSTRACT:
   "As a consequence, the SCTP associations are single homed."
- This final statement is not clear, although true. Please add text to 
explain to the reader why this is needed in the abstract. Could you say 
something that follows this below, and also explain why in section 6.1?
"The security properties of this encapsulation limit usage to 
single-homed SCTP associations."
---
Section 5:
    "a safe value for the path MTU has to be used by the SCTP stack."
    - How do you choose? - please specify a default or a method.
---
Section 5:
    "Differentiated services code point (DSCP) "
    - reference needed.
---
Section 5:
    "explicit congestion notifications (ECN)"
    - reference needed.
---
Section 5:
    "SCTP performs segmentation and reassembly based on the path MTU.
    Therefore the DTLS layer MUST NOT use any compression algorithm.

    The DTLS MUST support sending messages larger than the current path
    MTU.  This might result in sending IP level fragmented messages."
    - I wonder if some reordering of paras within teh section could
    gather all the size-related topics in one part of the section?
---
Section 6:
    - I am surprised this section does not mention how to handle
    any path changes, should PMTUD be triggered following known changes,
    for instance? Does this affect the SCTP CC state?
---
Section 6.1:
     /doesn't deal/does not deal/
     - please change.
---
Section 6.1:
    "All SCTP associations are single-homed."
    Could you add something like:
    ", because DTLS does not expose any address
    management to its upper layer."
---
Section 6.2:
   "The padding extension defined in [RFC4820] MUST be supported and used
    for probe packets when performing path MTU discovery as specified in
    [RFC4821]."
- Is this section relevant when DTLS implements PMTUD, please explain?
---
References:
  A later version (-10) exists ofdraft-ietf-rtcweb-overview-09
  A later version (-10) exists of draft-ietf-rtcweb-data-channel-08
---
The requirement to use SCTP/DTLS appears to also be cited in 
draft-ietf-rtcweb-overview-09, section 5.5, which requires normative use 
of SCTP/DTLS, but this document is not cited in the current document, I 
think it should be, if not why not?