Re: [Sframe] WGLC for draft-ietf-sframe-enc-04

Inline.

On Tue, Nov 7, 2023 at 3:30 AM Youenn Fablet <youenn@apple.com> wrote:

> The minimum bar to me is to have one implementation and a test suite
> including the feature, which is currently met with the reference
> implementation I think.
> Do you know of any additional implementation that supports it?
>

I'm not aware of any production implementations.  FWIW, I have been
experimenting some with applying SFrame to MOQ and have found it useful
there to bind in some MOQ context.

> W3C SFrameTransform does not seem a blocker as we could probably extend
> the API to support it, should there be a need in the future.
>

Agreed, we could have SFrameTransform supply empty metadata for now, and
specify a way to add it later.

> I do not see any blocker that would strongly indicate to remove it (nor a
> strong indicator we should keep it).
>

I agree with this assessment.  I'm just slightly in favor of keeping it
because it seems like a useful extension point (as with MLS
authenticated_data).

> I still find the spec a bit light on when users should use metadata and
> when they should not.
> The RTP header extension case is a bit unclear to me and section 9.4 does
> not provide applicability guidance.
>

I would be interested to understand better what you're looking for here.
(There's no mention of header extension here.  Maybe that's the problem?)
The most important thing is that the sender and receiver have the same
metadata; the current text captures that.  If you want to address the idea
of RTP extensions explicitly, we could add some "for example..." text.

> For example, if SFrame is being carried over RTP, an application might
use the metadata field to provide end-to-end authentication to some parts
of the RTP header, e.g., the RTP extensions for indicating audio levels or
video frame information {{RFC6464}} {{I-D.ietf-avtext-framemarking}}.  If
the application does this, however, it must ensure that the protected
header data is not modified between the SFrame sender and receiver.
Otherwise, the SFrame integrity check will fail.

> For the record, the past discussion summary is at
> https://github.com/sframe-wg/sframe/issues/63#issuecomment-1484641916 which
> indicates we should decide what to do at WGLC, now is the time.
>

>
>
> On 6 Nov 2023, at 17:17, Richard Barnes <rlb@ipv.sx> wrote:
>
> Thanks, Youenn.
>
> With regard to metadata: Given that we're about to finalize the spec, the
> time for "feature at risk" has passed.  We need to decide whether it's in
> or it's out.
>
> Personally I would be inclined to keep it.  This is the classic
> "proactively add an extension point" (which inherently leaves it
> underspecified) vs. "YAGNI / add the extension point when it's needed"
> (thus requiring a code change later) argument.  My inclination for the
> former is based on this being a very simple extension point that doesn't
> change the behavior of the protocol much.  And it seems like there are some
> things like frame marking that might benefit from being bound into the
> metadata.
>
> A comparable story from MLS/MIMI: We added an `authenticated_data` field
> to the MLS encrypted message structure, which has largely the same
> trade-offs we have here (except it *also* consumes space in the message).
> When it was added, there wasn't an explicit use case for it, but it looks
> like MIMI is going to make a fair bit of use.
>
> On Mon, Nov 6, 2023 at 10:34 AM Youenn Fablet <youenn=
> 40apple.com@dmarc.ietf.org> wrote:
>
>> The document looks ready to advance.
>>
>> About metadata, it is considered a feature at risk. It might still be a
>> bit early to decide whether this is a useful addition. How are we planning
>> to deal with it in the future?
>>
>> Thanks,
>> Youenn
>>
>> On 23 Oct 2023, at 01:08, Martin Thomson <mt@lowentropy.net> wrote:
>>
>> Hi All,
>>
>> This starts a 3 week working group last call for draft-ietf-sframe-enc-04.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/
>>
>> We've been somewhat slow about this, but progress has been steady and the
>> discussions have all been very productive.  The editors tell me that this
>> is ready.  Please let us know whether you agree.
>>
>> This WGLC will end at about the end of the upcoming IETF meeting.
>>
>> Cheers,
>> Martin
>>
>> --
>> Sframe mailing list
>> Sframe@ietf.org
>> https://www.ietf.org/mailman/listinfo/sframe
>>
>>
>> --
>> Sframe mailing list
>> Sframe@ietf.org
>> https://www.ietf.org/mailman/listinfo/sframe
>>
>
>