[tsvwg] Fwd: I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt

[Michael Tuexen <[e-mail]>]

WGLC comments from Joe.

Best regards
Michael

Begin forwarded message:

> From: Joe Touch <[e-mail]>
> Subject: Re: Fwd: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-03.txt
> Date: 6 Mar 2014 23:55:24 GMT
> To: Michael Tuexen <[e-mail]>
> Cc: Gorry Fairhurst <[e-mail]>, Randall Stewart <[e-mail]>, Randell Jesup <[e-mail]>, Salvatore Loreto <[e-mail]>
> 
> Hi, Michael,
> 
> On 2/7/2014 7:55 AM, Michael Tuexen wrote:
>> Hi Joe,
>> 
>> Gorry suggested that you might be interested in reviewing the SCTP over DTLS
>> ID, since you are interested in transport tunnels. So would it be possible
>> for you to review the document (it is pretty short)? I would appreciate your
>> review very much!
> ...
>>> 	Filename        : draft-ietf-tsvwg-sctp-dtls-encaps-03.txt
> 
> Comments below. Feel free to post/forward as usual; please cc me if you do, so I can track any followups if needed.
> 
> Joe
> 
> -----
> 
> 1 - I'm not a fan of "stacked headers"; section 1 should have something to say before you jump into 1.1
> 
> 1.1 - This section should more clearly explain the need for DTLS encapsulation, given RFC 6951 (SCTP over UDP) - i.e., you want UDP with security. That's implied right now, and should be explicit.
> 
> Why doesn't the entirety of this document not boil down to "run SCTP over UDP as per RFC 6951 except use DTLS instead of UDP? Wouldn't that description then mean you can then omit section 3?
> 
> 3 - I don't understand "sent down to the DTLS layer"; RFC6951 doesn't say "sent down to UDP". But, as noted, this section isn't needed.
> 
> 4 - The first sentence should be "SCTP over DTLS MUST support DTLS v1.2 or higher [RFC6341]."  T
> 
> The MTU discovery is already in DTLS 1.2 - no need to state, and no need to require that particular solution (e.g., it seems OK if DTLS updates it).
> 
> I'm not sure what the issue with probe packets is, but why is this a MUST, rather than just the statement "Probe packets are supported using existing DTLS extensions [RFC6520]"? Again, do you care if there are other DTLS methods for doing this?
> 
> The Path MTU paragraph is already addressed in RFC6951 - why add it here?
> 
> The doc should explain why you care about disabling DTLS compression.
> 
> The last sentence seems like it should be MUST NOT.
> 
> I.e., overall, it seems like you get what you need with a simpler first sentence, and the last two only.
> 
> 5 - same stacked header problem
> 
> 5.1 - odd wording on first sentence. seems like you want to say "This doc defines SCTP [RFC4960] in DTLS 1.2."
> 
> The issue here is, IMO, more that DTLS is connectionless *vs UDP* (the comparison is more direct).
> 
> I would not suggest using abbreviated terminology; you refer to associations only in one place. Why make it hard to understand that you mean "SCTP associations"?
> 
> The last bullet in this list is redundant; it's already covered in SCTP over UDP. IMO you're really applying SCTP over UDP to this, so you should refer to RFC6951 as normative and describe this as a superset of that.
> 
> 5.2 - redundant with RFC6951 AFAICT
> 
> 5.3 - why not put all the "no explicit addresses in band" somewhere, and include both this and other uses of addresses as examples?
> 
> -----
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>