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

[Christian Groves <[e-mail]>]

Hello,

Please see below [CNG].

Regards, Christian
>> What is the motivation for declaring any extensions to signalling
>> systems out of scope? (Not saying I see any that need to be created, but
>> I'm surprised that it's not something that the group might need to
>> investigate rather than making that call at chartering time)?
>>
> My reasons is to keep this WG focused on what it actually needs to
> produce and not get completely tied up in discussion of exactly how one
> will integrate this into ones signalling system. So I know people want
> this in WebRTC and SIP based conferences. I haven't heard anyone saying
> CLUE, but that is likely. These integrations are quite different,
> especially in what pieces you will trust when it comes to client
> software. Thus, my view was that WG working with signalling systems is
> the ones that should provide any necessary integration towards the
> framework.
[CNG] I don't see CLUE being a lot different from normal SIP based 
conferences apart from the RTP header issue raised by Paul K. All CLUE 
is really doing is providing metadata to endpoints to allow them to 
select media captures more intelligently. If an endpoint is using 
private media there may be some consideration of "how much" CLUE 
metadata to provide to a 3rd party switch.
>
>
> I do note that this consideration of integration is mentioned in this
> paragraph under Non-Goals:
>
> "The WG is not chartered to extend any signaling system used to
> establish the RTP based conferences. It will however, need to consider
> in its architecture how the solution may integrate with these systems."
[CNG] I think this is the important thing. Whilst the proposed WG may 
not actually do extensions, I think its important to consider how PERC 
will be integrated and this should be documented up front as part of the 
architecture. I think that will be an aid to further discussions.

>
> But, I guess one could be more explicit and require the WG to consider
> how one integrate into WebRTC, SIP and CLUE so that the framework is
> functional for these systems.
>
> When it comes to the key-management function, I think there exists an
> assumption here. That is that signalling and its nodes can't be trusted,
> only possible be used as a transport for key-management system
> information. But that will require that the communication fails if
> someone strips or modify such information.
>
> Does this help clarify the situation.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch