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

From: [email-masked]
Date: Mon, 12 Jan 2015 17:46:55 -0000

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

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

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

 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])."

 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]."

Best wishes,

Gorry

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 14 Jan 2015 12:33:24 +0100

> 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
> hurt, and it makes it obvious!
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...
> resets the congestion window and slow start threshold to their initial
OK. Taken.
> 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.
> 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?

---

From: [email-masked]
Date: Wed, 14 Jan 2015 11:57:37 -0000

Please see comments in line.

> diagram followed up by the sentence added to the overview? There is no
The first section would be fine.

> the RFC 4820, since I don't know why you are referring to RFC 4960.
The new text sounds good.

> this at the end of Section 4. OK?
This looks good.

Gorry

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 14 Jan 2015 22:39:16 +0100

> On 14 Jan 2015, at 12:57, [email-masked] wrote:
> 
Done.
>> this at the end of Section 4. OK?
I added at the end of section 4:
<t>The path MTU discovery is performed by SCTP when SCTP over DTLS is used
for data channels (see Section 4 of
<xref target='I-D.ietf-rtcweb-data-channel'/>).</t>
(some word smithing applied...) 

Best regards
Michael