Subject: [MMUSIC] avtext-sdes-hdr-ext has been approved, BUNDLE should probably be changed to use it.

From: Jonathan Lennox <[email-masked]>
Date: Mon, 20 Jun 2016 16:21:42 +0000

The IESG approval announcement was just sent out for draft-ietf-avtext-sdes-hdr-ext.

This document was essentially motivated as being a generalization of BUNDLE’s MID, but it has managed to pass BUNDLE in the IETF process.  So I suggest at this point BUNDLE should be modified to reference sdes-hdr-ext for its definition of the MID header extension (and the IANA header extension registration be updated to point at the new sub registry that sdes-hdr-ext defines).

This shouldn’t be a behavioral change at all, just documentation.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 21 Jun 2016 09:12:34 -0400

Hi Jonathan

This obviously represents a change to the document that the WG would 
have to agree to, not least considering that we have completed WGLC on 
the bundle draft (several times).

Can we get some more feedback on this proposal before we agree to this 
(late) change ?

Thanks

-- Flemming (as MMUSIC co-chair)

On 6/20/16 12:21 PM, Jonathan Lennox wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Jun 2016 15:39:46 +0200

> Can we get some more feedback on this proposal before we agree to this

Hi,

I think this really should be done. It is actually a fairly minor 
change. The main change is that the registration of the MID header 
extension shall be done in the sub-registry created by the SDES header 
extension document, and following its rules rather than the generic RTP 
header extension registry.

In fact the current version of bundle, already reference the right 
registry. A thing missing is a normative reference to the SDES header 
ext RFC-to-be.

Also when it comes to registration rules they are mostly fulfilled.

       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.

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

       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.

Looking at the current version, I would wish for a slightly clearer 
motivation in 14.1 for why the header extension is needed and RTCP is 
not sufficient. That being to ensure that one gets the MID identifier 
upon receipt of the first decodable media so that they can be correctly 
associated in the receiving application.

What I feel is not adequately described is the privacy consideration for 
the MID item. There are no guidelines for how to generate the MID 
identification-tag other than it is preferably be short. I think from a 
privacy perspective, the most important information aspect is that no 
user related information shall be included in the tag value. Secondly, 
there is risk for implementation identification due to implementation 
specific patterns in how they generate the tag.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jun 2016 13:48:41 +0000

Hi Jonathan/Magnus,

So, just to clarify what I¹d have to do in BUNDLE.

1. 	BUNDLE still needs to define and register the new MID RTP SDES item in
the IANA "RTP SDES item types" registry.

2.	BUNDLE will then register the item/URI extension in the newly formed
IANA "RTP SDES Compact Header Extensions registry².

AFAIK, BUNDLE already does both, based on earlier feedback from Alissa.

So, what exactly would I still need to change?

Regarding Magnus¹ bullets 2) and 3), where is that information for the
"urn:ietf:params:rtp-hdrext:sdes:cname² defined in avtext-sdes-hdr-ext?
The draft mentions CNAME here and there, but I can¹t really find a clear
description of its usage in the RTP SDES header extension.

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 21 Jun 2016 16:48:19 +0200

> description of its usage in the RTP SDES header extension.

Well, as usually in retrospect, that part should have been written as 
its own section so that it would provide an example. Instead it is 
spread out across the whole document.

The motivation for CNAME is covered in the general motivation for the 
SDES header extension, see section 3:

    For the case of rapid media synchronization, one may use the RTP
    header extension for Rapid Synchronization of RTP Flows [RFC6051].
    This header extension carries the clock information present in the
    RTCP sender report (SR) packets.  It however assumes that the CNAME
    binding is known, which can be provided via signaling [RFC5576] in
    some cases, but not all.  Thus an RTP header extension for carrying
    SDES items like CNAME is a powerful combination to enable rapid
    synchronization in all cases.

The privacy considerations for CNAME is covered in Section 6:

    Source Description items may contain data that are sensitive from a
    security perspective.  There are SDES items that are or may be
    sensitive from a user privacy perspective, like CNAME, NAME, EMAIL,
    PHONE, LOC and H323-CADDR.  Some may contain sensitive information,
    like NOTE and PRIV, while others may be sensitive from profiling
    implementations for vulnerability or other reasons, like TOOL.  The
    CNAME sensitivity can vary depending on how it is generated and what
    persistence it has.  A short term CNAME identifier generated using a
    random number generator [RFC7022] may have minimal security
    implications, while a CNAME of the form user@host has privacy
    concerns, and a CNAME generated from a MAC address has long term
    tracking potentials.

Cheers

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jun 2016 11:16:01 -0400

> Can we get some more feedback on this proposal before we agree to this

ISTM it would be good for Christer and Magnus to work out a specific set 
of changes to bundle and bring them back to the wg as a specific 
proposal. I guess it is just clerical, not technical, so it then should 
not be controversial to approve.

	Thanks,
	Paul

>> This document was essentially motivated as being a generalization of
>> BUNDLE’s MID, but it has managed to pass BUNDLE in the IETF process.
>> So I suggest at this point BUNDLE should be modified to reference
>> sdes-hdr-ext for its definition of the MID header extension (and the
>> IANA header extension registration be updated to point at the new sub
>> registry that sdes-hdr-ext defines).
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jun 2016 15:27:18 +0000

Hi,

...

>> The draft mentions CNAME here and there, but I can¹t really find a 
>> clear description of its usage in the RTP SDES header extension.
>
>
> Well, as usually in retrospect, that part should have been written as its own section so that it would provide an example. Instead it is spread out across the whole document.

As avtext-sdes-hdr-ext is supposed to be a "template" for other extensions, I think it would be good to put it in a dedicated section. After all, CNAME is not even the main thing of the document, just one usage of the created registry.

Also, if we update BUNDLE (if something needs to be updated) I assume the text talking about the MID SDES item will be removed from avtext-sdes-hdr-ext?

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Jun 2016 11:03:16 +0200

Den 2016-06-21 kl. 17:27, skrev Christer Holmberg:
> Hi,
>
> ...
>
>>> Regarding Magnus¹ bullets 2) and 3), where is that information
>>> for the "urn:ietf:params:rtp-hdrext:sdes:cname² defined in
>>> avtext-sdes-hdr-ext? The draft mentions CNAME here and there, but
>>> I can¹t really find a clear description of its usage in the RTP
>>> SDES header extension.
>>
>>
>> Well, as usually in retrospect, that part should have been written
>> as its own section so that it would provide an example. Instead it
>> is spread out across the whole document.
>
> As avtext-sdes-hdr-ext is supposed to be a "template" for other
> extensions, I think it would be good to put it in a dedicated
> section. After all, CNAME is not even the main thing of the document,
> just one usage of the created registry.
>
> Also, if we update BUNDLE (if something needs to be updated) I assume
> the text talking about the MID SDES item will be removed from
> avtext-sdes-hdr-ext?
>

I think the only text in SDES header ext document about BUNDLE is the 
following:

    The ongoing work on bundling SDP media descriptions
    [I-D.ietf-mmusic-sdp-bundle-negotiation] has identified a new SDES
    item that can benefit from timely delivery.  A corresponding RTP SDES
    compact header extension is therefore also defined and registered in
    that document:

    MID:  This is a media description identifier that matches the value
       of the Session Description Protocol (SDP) [RFC4566] a=mid
       attribute [RFC5888], to associate RTP streams multiplexed on the
       same transport with their respective SDP media description.

All I can see that is does is saying. Hey, there is this other document 
that also have a SDES item that needs a header extension. Here is the 
abstract what it does. Go read the bundle draft for the details.

I don't see an issue with leaving that in. Do you? Or have I forgotten 
about some other text about bundle?

Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jun 2016 09:06:58 +0000

Hi,

...

>about some other text about bundle?

No, you are correct. It can be left in the document.

Regards,

Christer