Re: [tsvwg] draft-ietf-tsvwg-sctp-dtls-encaps-08.txt

[Michael Tuexen <[e-mail]>]

On 12 Jan 2015, at 18:46, [e-mail] wrote:
> 
> It looks like we are getting towards a point where it would be useful to
> issue a new draft, so with this in mind I have a few comments (no Chair's
> hat yet), so please feel free to comment on these comments...
Hi Gorry,

thank you very much for your review. See my comments in-line.

Best regards
Michael
> 
> 
> I think the abstract  could benefit from a little explanation of the need
> for DTLS encapsulation, given RFC 6951, and  RTCweb wishes to use UDP with
> security. That's implied right now, and I think should be explicit.
> 
> I'd really encourage you to add this diagram to the intro, this wouldn't
> hurt, and it makes it obvious!
> 
> "
>                               +----------+
>                               |   SCTP   |
>                               +----------+
>                               |   DTLS   |
>                               +----------+
>                               | ICE/UDP  |
>                               +----------+
> 
>                       Figure 1: Basic stack diagram"
> 
> And suggest you follow with something like:
> 
>   This encapsulation of SCTP over DTLS over UDP or ICE/UDP (see [RFC5245])
>   can provide a NAT traversal solution together with confidentiality,
>   source authentication, and integrity protected transfers. "
Just the be clear:
Do you want to to add some clarifying text to the abstract and the stack
diagram followed up by the sentence added to the overview? There is no
section called intro...
> 
> This new text:
> "In case of a window based congestion..."
> Maybe would be clearer as:
> "The window-based congestion control method specified in [RFC4960],
> resets the congestion window and slow start threshold to their initial
> values."
OK. Taken.
> 
> In 6.2, is it perhaps clearer to say exactly what is done, to help the DTLS
> reader understand e.g.
> "and can be used to send probe packets (HEARTBEAT chunks
> bundled with PADDING chunks [RFC4960])."
What about:
<t>When the SCTP layer performs path MTU discovery as specified in
<xref target='RFC4821'/>, the padding extension defined in
<xref target='RFC4820'/> MUST be supported and used for probe packets
(HEARTBEAT chunks bundled with PADDING chunks <xref target='RFC4820'/>).</t>

Please note that I don't use "can be used" and that I changed the reference
the RFC 4820, since I don't know why you are referring to RFC 4960.
> 
> I think it would be useful to also mention: "Path MTU discovery
> is required by SCTP when SCTP over DTLS is used
> for data channels (section 4 of draft-ietf-rtcweb-data-channel-13]."
I added to section 6.2:
<t>Path MTU discovery is required by SCTP when SCTP over DTLS is used
for data channels
(see Section 4 of <xref target='I-D.ietf-rtcweb-data-channel'/>).</t>
Not sure this is the best place. I think a better place would be to add
this at the end of Section 4. OK?
> 
> Best wishes,
> 
> Gorry
> 
>