Hi, There's only one remaining item to address, so I'm cutting away the others:
>>> In Section A.3.6, "Data encryption" and "source authenticity" are absent >>> from the list of "security related transport features" (that are relegated >>> to the other document); this seems like a fatal omission. >> >> The list here are the security related transport features from A.1, >> which are taken (literally, for consistency) from RFC 8303, which is >> an analysis of what TCP, MPTCP, SCTP, UDP(-Lite) and LEDBAT offer. >> Since none of them offer encryption and "Data encryption" is thus >> not included in RFC 8303, we believe that this is a misunderstanding. >> We have now clarified where this list is from by adding >> "from Appendix A.1" in the sentence that introduces this list. > > Because it is a list of things *not* covered, I do not think that the > artificial limitation of scope to just those from RFC 8303 is necessarily > binding. In particular, the TAPS charter even calls out that "content > privacy to in-path devices" is to be considered. So, given how important > these features have become for the modern internet, I think it would be > good to say something like "it also excludes security transport features > not listed in Appendix A, including content privacy to in-path devices" at > the end of Section 5.6 (of the -09, since things got moved around a lot). Done, with version -10 (just submitted). > A previous draft of this message also was going to list something like > "integrity protection from active replacement", but I think that the > existing source authentication mechanisms would cover that. > (Also it looks like there's an "and and" in the list there.) Thanks, fixed! Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
