Re: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)

[Magnus Westerlund <[e-mail]>]

Hi,

I have now read Sergio and Bernards discussion on the Dispatch list. By dropping
it down to only dispatch I missed that discussion. 

On Thu, 2020-09-10 at 10:18 -0400, Richard Barnes wrote:
> Hi Magnus,
> 
> I agree with Sergio here.  The whole idea of SFrame is to have an encryption
> layer that doesn't care about any of the RTP nuances you talk about -- all of
> the details of how what decoder you send the plaintext to, substreams, etc.
> are handled by whatever RTP configuration mechanism you've set up.  SFrame is
> just a translation layer between what you send on the wire and what you do all
> the other stuff with.

Let me clarify what I see as the issue with the charter. 

So the whole point is to ensure that you can move SFRAMEs without any RTP. Thus,
what I was trying to exemplify through the previous work in RTP is to be able to
do this SFRAME do require meta data that enables a handling function to seperate
layers and dependecies. To support this I think you end up i the need for
extensible meta data, data that is unencrypted but strong considerd to avoid
information leakage and have good security properties. Taking the regular RTP
payload format headers straight may not be the best fit for many codecs.  If
that is going to be generic you end up in a naming and strucutre discussion like
what ended up in the Taxonomy RFC and like for the frame marking RTP header
extension.

However, the issue I really reacted to here is the fact that the charter is
stating that it should do an RTP payload format. When doing an RTP payload
format I think it is pre-mature of the charter to say that the signalling
required for the RTP payload foramt is out of scope. I think that needs to be
part of the process to discuss in the RTP payload format how an RTP middlebox
can use the payload format, and any RTP extension like frame marking to figure
out what to do when switching. That RTP payload format will require some
configuration capability to be able to work. 

So what I am really asking for is the removable of the restriction that prevents
a regular RTP payload format design work. And stating that SDP is out of scope
implies that to me in the direct context of the payload format. 

> 

https://docs.google.com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=sharing
> 

I think the edits are an improvement solving several unclarities around the
other issues I raised.

Maybe one way forward is to break the paragraph talking about signalling and RTP
payload format into two different paragraph. Where the RTP payload format need
for signalling is not associated with the higher level need for SFRAME
signalling over for example a SIP system. Which I am fine with excluding
explicitly. 

So just talking about the RTP Payload format. I think this do need a model for
how an RTP SFU is going to be able to do switching on it. Shouldn't that be in
scope? 

Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------