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

[Michael Tuexen <[e-mail]>]

> On 14 Jan 2015, at 12:57, [e-mail] wrote:
> 
> 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.
Done.
> 
>>> 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.
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
> 
>>> 
>>> Best wishes,
>>> 
>>> Gorry
>>> 
>> 
> 
> Gorry
> 
>