Subject: [avtext] SDP directorate review of draft-ietf-avtext-splicing-notification-00

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 3 Dec 2014 09:50:41 -0800

SDP directorate review of draft-ietf-avtext-splicing-notification-00, Dan Wing, 2-Dec-2014.

1.  the SDP in draft-ietf-avtext-splicing-notification is re-using FID from RFC5888, but is using different semantics.  How does a receiver know if the FID semantics are RFC5888's semantics or are draft-ietf-avtext-splicing-notification's semantics?  Seems we would benefit from an indication of the semantics in the SDP, perhaps a new session-level attribute (e.g., "a=splicing") or perhaps not re-use a=group:FID and instead invent its own grouping for splicing (e.g., a=group:SPLICE).

2. Security Considerations says:

   In the Secure Real-time Transport Protocol  
   (SRTP)[RFC3711], RTP header extensions are authenticated but not  
   encrypted.  A malicious endpoint could choose to set the values in  
   this header extension falsely, so as to falsely claim the splicing  
   time.

A malicious endpoint would need the SRTP key to do that, correct?  The I-D should mention that the malicious endpoint needs the SRTP key.  

Also, auch a malicious endpoint (with possession of the SRTP key) could also cause splicing of any arbitrary content it wishes, like a Rick Astley video, which is a different attack that isn't just against the *time*.  I-D should mention that.  I don't think either of these are significant, as the same problem exists without splicing.

Nits:  

1. The SDP in Section 6 has spurious whitespace, for example a space after "m=", which is prohibited by https://tools.ietf.org/html/rfc4566#page-8 ("Whitespace MUST NOT be used on either side of the "=" sign").  My read of the grouping RFC (RFC5888) is that it doesn't allow the spurious whitespace after "a=mid:", either.  The SDP in Section 6 is unclear if it is normative or a non-normative example.

2. Section 3.1 title, "ExtenTion" -> "ExtenSion"

3. Section 4 title, "Reduing" -> "ReduCing"

4. Section 6,
OLD:
   But at
   a particular point in time, the mixer only selects one stream and
   output the content from the chosen stream to the downstream
   receivers.
NEW:
   But at
   a particular point in time, the mixer only selects one stream and
   outputs the content from the chosen stream to the downstream
.........^
   receivers.

5. idnits had a couple of complaints, https://tools.ietf.org/tools/idnits/webservice

-d

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 5 Dec 2014 09:14:58 +0000

Hi Dan,

Thank you for the careful review. These two issues will be addressed in the new version.

BR,
Rachel

-----邮件原件-----
发件人: 🔓Dan Wing [mailto:[email-masked]] 
发送时间: 2014年12月4日 1:51
收件人: [email-masked]; [email-masked]
抄送: mmusic
主题: SDP directorate review of draft-ietf-avtext-splicing-notification-00

Nits:  

4. Section 6,
OLD:
   But at
   a particular point in time, the mixer only selects one stream and
   output the content from the chosen stream to the downstream
   receivers.
NEW:
   But at
   a particular point in time, the mixer only selects one stream and
   outputs the content from the chosen stream to the downstream .........^
   receivers.

-d