Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-29

From: Alissa Cooper <[email-masked]>
Date: Mon, 2 May 2016 12:06:31 -0700

A few small things Ben and I noticed while reviewing draft-ietf-avtext-sdes-hdr-ext, which references this document:

In 15.1, the registry being referred to should be “RTP SDES item types,” not “RTCP SDES item types.”

In 15.2, the registry being referred to should be the "RTP SDES Compact Header Extensions” sub-registry of the RTP Compact Header Extensions sub-registry (as defined in draft-ietf-avtext-sdes-hdr-ext).

I would also note that if the RTP SDES Compact Header Extensions sub-registry gets defined as described in draft-ietf-avtext-sdes-hdr-ext, it will require a number of items in the registration documentation for new entires (see 5.2 of that draft), so those would be required here to register MID.

Alissa

> On Apr 29, 2016, at 11:32 AM, Flemming Andreasen <[email-masked]> wrote:
> 
> Greetings
> 
> This is to announce a 2 week Working Last Call for
> 
>    draft-ietf-mmusic-sdp-bundle-negotiation-29
> 
> as Proposed Standard. Please note that we previously issued a WGLC on the -22 version (in June 2015), however, since there has been various updates since then, we want to give people a chance to properly review the current version one last time (hopefully).
> 
> Please review and provide any comments you may have on the document by Friday, May 13, 2016. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.
> 
> Thanks
> 
>        Flemming (MMUSIC co-chair)
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 May 2016 08:35:09 +0000

Hi Alissa,

Thanks for your comments! Reply below.

>In 15.1, the registry being referred to should be “RTP SDES item types,” not “RTCP SDES item types.”

Correct. I’ll fix that.

>In 15.2, the registry being referred to should be the "RTP SDES Compact Header Extensions” sub-registry of the RTP Compact Header Extensions sub-registry (as defined in draft-ietf-avtext-sdes-hdr-ex…

Ok.

When can we expect that new sub-registry to be created? What is the status of draft-ietf-avtext-sdes-hdr-ext?

>I would also note that if the RTP SDES Compact Header Extensions sub-registry gets defined as described in draft-ietf-avtext-sdes-hdr-ext, it will
>require a number of items in the registration documentation for new entires (see 5.2 of that draft), so those would be required here to register MID.

Ok, I see the following:

      “Review process: Same as for RTP Header Extensions [RFC5285]
      registry, with the following requirements added to the expert
      review:”

              When looking at section 9.1 of RFC 5285, all the required information is provided. Regarding the things the expert reviewer is required to look at, in my opinion it is all covered. Bullet 5 of section 9.1 will be covered with the suggested security/privacy text below.

      “1.  Any registration using an Extension URI that starts with
          "urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also
          have a registered Source Description item in the "RTP SDES
          item types" registry.”

              Done. See section 15.1.

      “2.  A security and privacy consideration for the SDES item MUST be
          provided with the registration.”

           I suggest the following text:

           “The SDES item does not reveal privacy information about the users. It
             is simply used to associate RTP-based media with the correct SDP media
             description (m- line) in the SDP used to negotiate the media.”

      “3.  Information MUST be provided on why this SDES item requires
          timely delivery, motivating it to be transported in a header
          extension rather than as RTCP only.”

              I suggest the following text:

              “The purpose of the extension is for the offerer to be able to associate
              received multiplexed RTP-based media before the offerer receives the
              associated SDP answer. See section 14 for more details.”

Regards,

Christer

On Apr 29, 2016, at 11:32 AM, Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:

Greetings

Thanks

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Thu, 12 May 2016 10:02:14 +0100

Flemming,

> On 29 Apr 2016, at 19:32, Flemming Andreasen <[email-masked]> wrote:
> 

One minor comment:

- Section 10.1.1: the last paragraph of this section notes that “once an SSRC has left the RTP session (by sending an RTCP BYE packet), that SSRC value can later be reused”. I agree, but this needs to also specify the time period for “later”, so that the SSRC has timed out if the RTCP BYE was lost. I suggest this sentence is changed to “once an SSRC has left the RTP session (by sending an RTCP BYE packet), that SSRC can be reused after a delay of 5 RTCP reporting intervals (the delay is to ensure the SSRC has timed out, in case the RTCP BYE packet was lost, see [RFC3550] section 6.3.5)”.

Cheers,
Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 May 2016 11:21:22 +0000

Hi Colin,

>> as Proposed Standard. Please note that we previously issued a WGLC on
>>the -22 version (in June 2015), however, since there has been various
>>updates since then, we want to give people a chance to properly review
>>the current version one last time (hopefully).
>> 
>> Please review and provide any comments you may have on the document by
>>Friday, May 13, 2016. Comments should be sent to the document authors
>>and the MMUSIC WG list. If you review the document but do not have any
>>comments, please send a note to that effect as well.
>
>One minor comment:
>
>- Section 10.1.1: the last paragraph of this section notes that ³once an
>SSRC has left the RTP session (by sending an RTCP BYE packet), that SSRC
>value can later be reused². I agree, but this needs to also specify the
>time period for ³later², so that the SSRC has timed out if the RTCP BYE
>was lost. I suggest this sentence is changed to ³once an SSRC has left
>the RTP session (by sending an RTCP BYE packet), that SSRC can be reused
>after a delay of 5 RTCP reporting intervals (the delay is to ensure the
>SSRC has timed out, in case the RTCP BYE packet was lost, see [RFC3550]
>section 6.3.5)².

I am ok with your suggestion. Anyone has any issues?

Thanks!

Regards,

Christer