Subject: [AVTCORE] FW: New Version Notification for draft-mattsson-avtvore-cloud-conferencing-use-case-00.txt

From: John Mattsson <[email-masked]>
Date: Fri, 4 Jul 2014 21:44:16 +0000

We have submitted a new draft describing the use case of Privacy Ensured
Cloud Conferencing.

There is an ongoing transformation towards virtualized cloud-based
conferencing is happening and IETF should take action to make such
services viable and trustworthy from a pervasive monitoring perspective.

John Mattsson

On 04/07/14 15:57, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D,
>draft-mattsson-avtvore-cloud-conferencing-use-case-00.txt
>has been successfully submitted by John Mattsson and posted to the
>IETF repository.
>
>Name:		draft-mattsson-avtvore-cloud-conferencing-use-case
>Revision:	00
>Title:		Privacy Ensured Cloud Conferencing - Use Case and Goals
>Document date:	2014-07-04
>Group:		Individual Submission
>Pages:		8
>URL:            
>http://www.ietf.org/internet-drafts/draft-mattsson-avtvore-cloud-conferenc
>ing-use-case-00.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-mattsson-avtvore-cloud-conferencing
>-use-case/
>Htmlized:       
>http://tools.ietf.org/html/draft-mattsson-avtvore-cloud-conferencing-use-c
>ase-00
>
>
>Abstract:
>   The aim of this document is to describe the use case of privacy
>   ensured cloud conferencing in a pervasive monitoring landscape and to
>   point out goals for a solution mitigating the pervasive monitoring
>   threat [RFC7258].
>
>   Virtualized cloud-based conferencing is happening and IETF should
>   take action to make such services viable and trustworthy from a
>   pervasive monitoring perspective.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 6 Jul 2014 16:21:58 -0700

A few comments: 
> 
> Did you really mean to submit this to AVTVORE instead of AVTCORE?
> 
> From Urban Dictionary:  "The most common type of vore...  being swallowed or swallowing whole with no bloodshed." 
> 
> The IETF is not the type of organization likely to satisfy this definition :)
> 
> Section 4: 
>    The RTP mixer will be forced to behave like a video switching MCU in
>    RFC 5117.  SRTP prevents the mixer from performing any type of RTP or
>    RTCP rewrite.  However, to keep the bitrate in check its switching
>    decision will result in stopping RTP streams from reaching the
>    client.  This results in RTP sequences with large gaps in them.
>    These gaps hide packet losses at the edges of the gaps, resulting in
>    that the receiver has issues in determining if loss near switching
>    point is intentional or not.  This can cause repair attempts,
>    buffering issues, and triggering bit-rate adaptation.  In addition
>    the congestion control mechanism has significant difficulties to act
>    correctly in such an environment.
> 
> [BA] I would suggest dividing the discussion into problems arising from an inability to modify RTP header fields (such as Payload Type, SSRC, CSRC and Sequence Number) and problems arising from an inability to decrypt/encrypt the Payload.  
> The RTP header fields that need to be modified is determined by the SFU taxonomy.  For example if the SFU supports distinct SSRCs per SVC layer then the sequence numbers do not need to be rewritten.  
> The need to decrypt (or encrypt) the payload derives from the characteristics of existing codec designs.  For example, in order to determine whether to forward or drop packets, today's SFUs need to decrypt and parse the payload, since that is where the layer and other relevant information is provided.    In codecs such as H.264/SVC a layer-drop indication needs to be inserted to address the issues described above, so that access to the SRTP session keys is required. 
>