Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)

[Robert Sparks <[e-mail]>]

On 4/13/15 10:51 AM, Jonathan Lennox wrote:
>
>> On Apr 13, 2015, at 11:42 AM, Robert Sparks <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>
>>
>> On 4/13/15 10:24 AM, Jonathan Lennox wrote:
>>>
>>>> On Apr 13, 2015, at 11:11 AM, Jonathan Lennox <[e-mail] 
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>
>>>>> On Apr 13, 2015, at 9:49 AM, Paul Kyzivat <[e-mail] 
>>>>> <mailto:[e-mail]>> wrote:
>>>>>
>>>>> On 4/13/15 4:33 AM, Magnus Westerlund wrote:
>>>>>> On 2015-04-10 16:37, Robert Sparks wrote:
>>>>>>> So, I think this should get chartered.
>>>>>>> I have a couple of charter-bashing questions/comments.
>>>>>>>
>>>>>>> It would be good to be clear what any interactions with the work 
>>>>>>> in CLUE
>>>>>>> might be.
>>>>>>
>>>>>> I hope someone more active than me can step in an give their view 
>>>>>> here.
>>>>>> To me this should be possible to use with CLUE. I don't know if that
>>>>>> will be possible without any extensions to the clue part.
>>>>>
>>>>> I *think* there will be a problem: that a mixer won't be able to 
>>>>> insert the clue capture-id into the RTP/RTCP.
>>>>>
>>>>> Roni and Jonathan should be able to be more definitive about this.
>>>>
>>>> PERC will need the ability for the middleboxes to insert hop-by-hop 
>>>> header extensions and RTCP SSRC values — BUNDLE will need this for 
>>>> the mid values.
>>>
>>> Should be “SDES” values, sorry.
>> If SDES is an assumption, it should land in the charter.
>> I hope it's not an assumption, and that you'll be able to use other 
>> tools.
>
> Oh, this stupid name collision.
>
> I mean RTCP SDES packets, “Source Description” (as defined in RFC 
> 3550), not SDP Security Descriptions (RFC 4568).
>
> I think Security Descriptions should absolutely not be used for PERC, 
> I think it would completely break the security model (barring magical 
> secure side-channels).
Good - thanks for the clarification.