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

[[e-mail]]

Please see comments in line.

> 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...
>
The first section would be fine.

>> 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.
>
The new text sounds good.

>>
>> 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?
>
This looks good.

>>
>> Best wishes,
>>
>> Gorry
>>
>

Gorry