Re: [secdir] Secdir Last Call Review of draft-ietf-mmusic-data-channel-sdpneg-24

["Steve Hanna" <[e-mail]>]

Roni,

Thanks for taking my feedback in such a positive manner. That's just how I
intended it. The document is well written and pretty easy to understand. I
especially appreciated Appendix A, which helped me avoid needing to read
many other documents. I can't provide any technical feedback because I'm not
an expert in your domain. But I can say that from a security perspective,
your explanation makes sense to me.

As for the English language nits, there seem to be 1-2 in every paragraph.
If your co-authors don't see many, please invite someone who does
copyediting or proofreading to review the document. They'll find lots more
like the ones that I cited. These don't substantially impeded the
comprehension of the document but they slow down the reader and in some
cases could lead to confusion (especially with agreement errors like the
first and third nit that I cited).

Thanks,

Steve

-----Original Message-----
From: Roni Even (A) <[e-mail]> 
Sent: Monday, March 11, 2019 9:07 AM
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: RE: Secdir Last Call Review of
draft-ietf-mmusic-data-channel-sdpneg-24

HI Steve,
Thanks for the review. I will update the document. As for the nits, it is my
fault for not noticing these nits, will fix all of them and some of the
co-authors are native English speakers.
Roni

-----Original Message-----
From: Steve Hanna [mailto:[e-mail]] 
Sent: Monday, March 11, 2019 2:41 AM
To: [e-mail]; [e-mail];
[e-mail]
Subject: Secdir Last Call Review of draft-ietf-mmusic-data-channel-sdpneg-24

Review result: Ready with nits
Reviewer: Steve Hanna

I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should treat
these comments just like any other IETF Last Call comments.

This document specifies how the SDP (Session Description Protocol)
offer/answer exchange can be used to achieve an out-of-band non-DCEP
negotiation for establishing a data channel.

Major Concerns:

None

Minor Concerns:

The last sentence in the Security Considerations section says:

   Error cases like the use of unknown parameter values or violation the
   odd/even rule must be handled by closing the corresponding Data
   Channel.

I suspect that the "must" in this sentence should be "MUST". Nothing else in
the document seems to state this requirement but it does seem necessary.

Nits:

This document has many small English language errors.  For example, the
first paragraph of the Introduction has three things that need to be
corrected:
- s/a bi-directional data channels/bi-directional data channels/
- s/prtocols/protocols/
- s/an endpoint applications/endpoint applications/

Please enlist a native English speaker as a proofreader.