Hi Roni, See my answers below. On 6/23/14, 7:28 AM, Roni Even wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments you > may receive. > > Document: draft-ietf-tram-stun-dtls-03 > > Reviewer: Roni Even > > Review Date:2014-6-23 > > IETF LC End Date: 2014-6-25 > > IESG Telechat date: > > > > Summary: This draft is almost ready for publication as an Standard track > RFC. > > > > > > Major issues: > > > > Minor issues: > > > > I am not sure I understand section 4.3. When talking about "media keep-alive > packets" is it for the STUN Binding Indication usage or for all the options > in section 10 of RFC 5245. Yes, only the STUN Binding Indication usage. You are right this is not clear. > Maybe you meant that you should prefer DTLS/SRTP > keep-alive like RTP no-op in this case. I had problem understanding this > section. Please clarify. > No the text did not meant to choose one over the other, just to explain the pros and cons of running the STUN Binding Indication usage over DTLS. I propose this new text: " When STUN is being used for media keep-alive (described in Section 10 of [RFC5245]), it runs alongside an RTP or RTCP session. It is possible to send the media keep-alive packets inside a separately negotiated non-SRTP DTLS session if DTLS-SRTP [RFC5764] is used, but that would add overhead, with minimal security benefit." Thanks. -- Marc Petit-Huguenin Developer | Jive Communications, Inc. Jive.com | marcph@xxxxxxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature