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

[Magnus Westerlund via Datatracker <[e-mail]>]

Magnus Westerlund has entered the following ballot position for
charter-ietf-sframe-00-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-sframe/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I know we have had discussion touching on this before. But post vacation and
looking on this charter again I think we need to have some additional
discussion of the goals and how the charter describes them in relation to
encoder sub-streams and identification of what is encapsulated.

In regards to the below:

This working group will not specify the signaling required to configure SFrame
encryption.  In particular, considerations related to SIP or SDP are out of
scope.  This is because SFrame is intended to be applied as an additional layer
on top of the base levels of protection that these protocols provide.  This
working group will, however, define how SFrame interacts with RTP (e.g., with
regard to packetization, depacketization, and recovery algorithms) to ensure
that it can be used in environments such as WebRTC.

I think there exist a conflict in the above paragraph in relation to stated
goals of the work. With the following earlier sentence: " It may also be
desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1 OBUs)
to allow partial frames to be usable." in mind creating an RTP payload format
that is capable of carrying SFRAMEs that contains these units will require some
interaction with the signalling. Even without these sub-stream SFRAMEs there
exist a description capability that needs to exist in an RTP payload format for
the end-consumer to correctly be able to route the protected data after
decapsulation and that the end-point having that capability.

If the goal here when it comes to RTP is simply to be able to treat SFRAME as
CODEC in WebRTC and thus use WebRTC InsertableStreams as a receiver of the
decrypted media ADUs. Require the use of the WebRTC application to have a
proprietary signalling to know what this ADU is and then route it to a media
decoder? I can see that working in the WebRTC only context. However, I would
prefer if some thought was spent on at least having a model for what
information may be needed to be able to handle the media streams. Considering
RFC 7656 (https://datatracker.ietf.org/doc/rfc7656/) and the work that was
needed for us to up-level how RTP worked and even discuss this so that we
understood each other. I think SFRAME needs to discuss how it is going to
handle identification of the data encapsulated by SFRAMEs for media. A single
media source can be encoded in multiple formats. Each format may produce one or
more sub-streams of encoding for scalability or robustness and this needs to
conveyed.

So looking at the above challenges in the context of SFRAME over RTP. So a
possibility here is to say that the SSRC represents either just a media source.
The RTP payload format provides only fragmentation of the SFRAME across
multiple RTP packets and the RTP timestamp can be used to indicate its
belonging in the timeline of the encoding. That puts a lot of the
identification on the SFRAME layer, but its minimizes the signalling
interactions related to RTP. However it creates limitation about what the SFU
can do, especially when it comes to repair. Switching can be done based on
Frame-marker extension header. However, layer related loss detection becomes
impossible without additional information, or use of multiple SSRCs.

Thus, I think the charter as currently written are uncertain if it can be
executed on with stated goals.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


* Information to form a unique nonce within the scope of the key

Is this really "Information to form a" the best formulation. I am uncertain if
the goal is to have a specification for how to generate unique Nonce values
within the context of a particular key, or if it is related to which
information sources that should be used when creating a nonce?