Telechat Review of draft-ietf-perc-srtp-ekt-diet-11
review-ietf-perc-srtp-ekt-diet-11-genart-telechat-holmberg-2020-01-31-00
Request | Review of | draft-ietf-perc-srtp-ekt-diet |
---|---|---|
Requested revision | No specific revision (document currently at 13) | |
Type | Telechat Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2020-02-04 | |
Requested | 2020-01-30 | |
Authors | Cullen Fluffy Jennings , John Preuß Mattsson , David McGrew , Dan Wing , Flemming Andreasen | |
I-D last updated | 2020-01-31 | |
Completed reviews |
Secdir Last Call review of -08
by Hilarie Orman
(diff)
Genart Last Call review of -09 by Christer Holmberg (diff) Genart Telechat review of -11 by Christer Holmberg (diff) |
|
Assignment | Reviewer | Christer Holmberg |
State | Completed | |
Request | Telechat review on draft-ietf-perc-srtp-ekt-diet by General Area Review Team (Gen-ART) Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/leV-v09Mq4Pah9CzmTMDtZ1YGII | |
Reviewed revision | 11 (document currently at 13) | |
Result | Ready w/issues | |
Completed | 2020-01-31 |
review-ietf-perc-srtp-ekt-diet-11-genart-telechat-holmberg-2020-01-31-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-perc-srtp-ekt-diet-11 Reviewer: Christer Holmberg Review Date: 2020-01-31 IETF LC End Date: None IESG Telechat date: 2020-02-06 Summary: I took a long time before I got a reply to my original review comments, and now I realize that I never addressed that reply. Sorry for that. In my previous review, I had a number of editorial suggestions (Minor Issues), and in many cases the author did not agree to those. I will not pursue those, but leave it to the IESG to decide whether something needs to be done. Many of my issues have been addressed in the latest version. However, I do still have a couple of issues. One of them (Q1_1) is a follow-up from my previous review, and for convenience I will include the discussion content in this review. Major issues: Q1_1: >> The text in section 1 says that EKT removes the need for coordinating >> SSRCs,and that an endpoint can choose whatever value it wants. >> >> However, I can't find any explanation on how EKT removes that need. > > The answer is toward the end of the introduction: "EKT does not control the > manner in which the SSRC is generated..." -- it just makes the distribution > of security information easier. I extended that paragraph to clarify. As far as I understand, SSRC collisions can still occur. But, if that occurs, endpoints can provide the new SSRC using EKT – without the need for OOB solutions or signaling – and that is the reason EKT removes the need for coordinating SSRCs. I think it would be good to clarify that. Q_1_2: Section 5.3 reference RFC 3264 for the Offer/Answer procedures. However, since the text is specific to DTLS-SRTP, I think the reference should be to RFC 5763 and draft-ietf-mmusic-dtls-sdp. I assume this also applies to the RFC 3264 reference in Section 4.1 (SRTPMasterKeyLength definition). Minor issues: N/A Nits/editorial comments: N/A