Hi,
> On May 22, 2018, at 8:13 PM, Christopher Wood <[email protected]> > wrote: > > Hi Michael, > > Many thanks for reading the document and taking time to provide comments! > They are greatly appreciated. I've filed #33 ( Gee, thanks to you for this friendly response after getting so much work thrown in your face! :) seriously, sorry for this! I’m only keeping and answering things that I think call for an answer - everything I removed has my implicit positive ACK… and I mark my response with [MW]. >> Similarly, what is the rationale for making some features mandatory and > some optional in section 4? Reasons for this choice should be explicitly > laid out at the beginning of section 4. > > In general, our rationale for mandatory features is that they were offered > by most popular protocols and are "critical" for the security protocol to > operate correctly. Optional features are those protocols can work around. [MW] I think that’s fine - but please state this in the draft. >> This brings me to the next issue: I think there’s a terminology problem > with this document. The terminology section, in line with all other TAPS > documents, mentions “confidentiality” as an example of a “Transport > Feature”. Further down, “Security Feature” is introduced. Given the > description of Transport Feature, a Security Feature is a special case of a > Transport Feature. Maybe the first sentence of the Security Feature > definition could be changed to say “A Transport Feature that a network > security layer provides to applications.” Section 3 then talks about > “Protocol features”; these are maybe not offered to applications, so I > think it’s fine to use this term, but you should also define it in the > Terminology section. Then, Section 5 talks about Transport Security > Protocol Interfaces - but that term isn’t defined anywhere. I think these > “interfaces” are really Security Features, no? > > Not quite. They're interfaces to the security protocols. Those interfaces > may of course drive or control certain features. I see where you’re coming from… but the way the terminology is, and was interpreted in other TAPS documents so far, is that “provides to applications” in the phrase "a specific feature that a network security layer provides to applications” really means that this is visible in the API. You already use the (new) term “protocol feature” to talk about things that may not be visible in the API. Do you need yet another term, then? If so, maybe you should define “Interface” in the Terminology section too to clarify how this is different. >> Section 3.2.3: Path MTU Discovery surprised me here. What does that mean? > That DTLS relies on an application implementing PMTUD (as it’s over UDP), > and then telling DTLS about it? Doesn’t DTLS do this on its own? Why not? > Sorry for asking a DTLS question, surely it’s me… but just listing PMTUD as > a dependency isn’t a good enough explanation, I think. > > Clients have to set the maximum DTLS fragment (record) size, as each record > must fit within a single datagram. Oh, wow, so it is true -- you have to do PMTUD in your application to properly use DTLS?? Note the previous comment from Mikael Abrahamsson in his email about minset: he wondered if a TAPS system should offer PMTUD. If using DTLS is such a hassle, maybe the answer should be yes? (being application-independent, for UDP, I think this could only be done with a mechanism such as draft-ietf-tsvwg-datagram-plpmtud ) Sorry for the digression! Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
