[{"author": "Robert Sparks", "text": "

Red on black on the slide :(

", "time": "2023-07-24T16:30:57Z"}, {"author": "Phillip Hallam-Baker", "text": "

Form a working group: This is an important problem, it needs a solution. Existing solutions I worked on included SAML and WS-Security/SOAP which was designed to do exactly this.

", "time": "2023-07-24T16:41:56Z"}, {"author": "Phillip Hallam-Baker", "text": "

Probably should look at the earlier stuff but it would need changes anyway

", "time": "2023-07-24T16:42:19Z"}, {"author": "Pete Resnick", "text": "

@Phillip Hallam-Baker Agreed, but this is sounding more appropriate for SEC rather than ART.

", "time": "2023-07-24T16:44:23Z"}, {"author": "Ted Hardie", "text": "

I guess I'm missing why this isn't a secdispatch question.

", "time": "2023-07-24T16:44:33Z"}, {"author": "Pete Resnick", "text": "

I hope he has a slide explaining that.

", "time": "2023-07-24T16:45:00Z"}, {"author": "Robert Sparks", "text": "

interrupt the presentation to ask that question?

", "time": "2023-07-24T16:45:10Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Pete, depends on what you think SEC is about. The signing part of this isn't going to be the hard part. Everything is a SEC problem if you try even a little bit...

", "time": "2023-07-24T16:47:37Z"}, {"author": "Daniel Gillmor", "text": "

I'm dubious about some of the use cases here. how much do we think the chains of attestation are known and understood by the services involved? Should the client itself be able to constrain what happens to the request or the resource after it leaves the client? what kind of logic do we imagine being applied to the chains of communication?

", "time": "2023-07-24T16:48:48Z"}, {"author": "John Klensin", "text": "

I'm wondering about something else... given the beating that OAUTH has taken recently on the IETF list, do they see ways to avoid those issues?

", "time": "2023-07-24T16:49:48Z"}, {"author": "Lucas Pardue", "text": "

iffy on SPIFFE?

", "time": "2023-07-24T16:52:37Z"}, {"author": "Ted Hardie", "text": "

At least so far \"propose a bof at 118\" seems like a reasonable answer here, especially if there is good traffic on wimse in the meantime.

", "time": "2023-07-24T16:53:23Z"}, {"author": "Atul Tulshibagwale", "text": "


", "time": "2023-07-24T16:54:15Z"}, {"author": "Jonathan Rosenberg", "text": "

I think its a bof in art

", "time": "2023-07-24T16:54:39Z"}, {"author": "Phillip Hallam-Baker", "text": "

@John, that is why I think this might be ART rather than SEC. What is needed is an understanding of how to apply this mechanism to actual deployments and get some idea of what can be made standard.

", "time": "2023-07-24T16:54:41Z"}, {"author": "Ted Hardie", "text": "

You'll need a technical advisor from the other area, no matter which area it ends up in. But that's pretty easy to arrange.

", "time": "2023-07-24T16:55:13Z"}, {"author": "Jonathan Rosenberg", "text": "

Depending on which pieces get standardized, some might go to sec. But this is still sufficiently unclear on scope, i think art is more general

", "time": "2023-07-24T16:55:18Z"}, {"author": "Phillip Hallam-Baker", "text": "

I don't think it matters where the BOF is. Just make sure the SEC ADs are present. The ADs can decide where.

", "time": "2023-07-24T16:55:19Z"}, {"author": "John Klensin", "text": "

@Ted: agreed. And I don't think the nominal Area for the BOF is located as long as that is not treated as a commitment.

", "time": "2023-07-24T16:55:42Z"}, {"author": "Pete Resnick", "text": "

\"Dispatch me?\" is never a question; we will dispatch, though sometimes to the bin. ;-)

", "time": "2023-07-24T16:59:34Z"}, {"author": "Lucas Pardue", "text": "

that's a bad client adaptation algorithm :D

", "time": "2023-07-24T17:00:21Z"}, {"author": "Daniel Gillmor", "text": "

why is the network the thing doing this limiting? can't the client say \"don't give me more than 2Mbps\"?

", "time": "2023-07-24T17:02:50Z"}, {"author": "Alan Frindell", "text": "

The client doesn't necessarily know about the desired rate from the network

", "time": "2023-07-24T17:03:26Z"}, {"author": "Pete Resnick", "text": "

@Daniel Gillmor The shaper is there for when the client wants more than the network provider is willing to give.

", "time": "2023-07-24T17:03:59Z"}, {"author": "Daniel Gillmor", "text": "

the two reasons given in the presentation for the limit were client rationales.

", "time": "2023-07-24T17:04:37Z"}, {"author": "Luca Niccolini", "text": "

Lucas Pardue said:


that's a bad client adaptation algorithm :D


1-->20 is probably exaggerated a bit , but in practice there isn't a whole lot of granularity, which makes this hard

", "time": "2023-07-24T17:04:44Z"}, {"author": "Nick Doty", "text": "

right, but if the network told the client what the bandwidth limits are, the client could then adjust

", "time": "2023-07-24T17:04:47Z"}, {"author": "Lucas Pardue", "text": "

you can't trust the client to do that

", "time": "2023-07-24T17:05:06Z"}, {"author": "Lucas Pardue", "text": "

also, it doesn't work when a client wants to play multiple streams over one link

", "time": "2023-07-24T17:05:32Z"}, {"author": "Richard Barnes", "text": "

@Daniel Gillmor i think the point he's making is that client-driven adaptation doesn't work quickly enough

", "time": "2023-07-24T17:05:39Z"}, {"author": "Nick Doty", "text": "

the network doesn't trust the client, no, and they can continue to use these shapers for that reason. but the client can avoid this ping-pong

", "time": "2023-07-24T17:05:43Z"}, {"author": "Abhishek Tiwari", "text": "

Nick Doty said:


right, but if the network told the client what the bandwidth limits are, the client could then adjust


Network telling endpoints is the essence of the proposed solution

", "time": "2023-07-24T17:05:51Z"}, {"author": "Nick Doty", "text": "

abhishek, my skepticism is picking a solution where the content server is informed, rather than the client (if I understood the draft properly)

", "time": "2023-07-24T17:07:15Z"}, {"author": "Alan Frindell", "text": "

The solution in the draft can be used either between the client and network or the network and the server

", "time": "2023-07-24T17:07:48Z"}, {"author": "Daniel Gillmor", "text": "

so the specific questions are:

\n", "time": "2023-07-24T17:09:43Z"}, {"author": "Nick Doty", "text": "

I only saw a single sentence mentioning the possibility of communicating to the client

", "time": "2023-07-24T17:10:23Z"}, {"author": "Daniel Gillmor", "text": "

smells a lot like path-aware networking, no?

", "time": "2023-07-24T17:10:33Z"}, {"author": "Hang Shi", "text": "

Does the side meeting have online link?

", "time": "2023-07-24T17:11:03Z"}, {"author": "Abhishek Tiwari", "text": "

Nick Doty said:


abhishek, my skepticism is picking a solution where the content server is informed, rather than the client (if I understood the draft properly)


As Alan said the draft discusses communication both ways, but Nick can you elaborate on your skepticism on informing content server (May be in the side meeting)

", "time": "2023-07-24T17:11:25Z"}, {"author": "Luca Niccolini", "text": "

Daniel Gillmor said:


so the specific questions are:


very good questions, the side meetings presentation will have more details on the solution design

", "time": "2023-07-24T17:11:38Z"}, {"author": "Daniel Gillmor", "text": "

side meeting wiki: https://wiki.ietf.org/en/meeting/117/sidemeetings

", "time": "2023-07-24T17:11:51Z"}, {"author": "John Klensin", "text": "

Once upon a time, one of the key principles for the network (perhaps _the_ key principle once one gets past \"packets\" and \"datagrams\" was that the transport was completely agnostic about applications and the applications couldn't mess with the transport. Anyone else having trouble keeping their footing on this increasingly slippery slope?

", "time": "2023-07-24T17:12:12Z"}, {"author": "Pete Resnick", "text": "

Transport people are fine if you're doing this kind of thing so long as you're inside TCP, right?

", "time": "2023-07-24T17:12:56Z"}, {"author": "Pete Resnick", "text": "

(or DCCP or anything with it's own CC)

", "time": "2023-07-24T17:13:40Z"}, {"author": "Daniel Gillmor", "text": "


", "time": "2023-07-24T17:14:30Z"}, {"author": "John Klensin", "text": "

As I said, Pete, slilippery slooe

", "time": "2023-07-24T17:14:38Z"}, {"author": "Lucas Pardue", "text": "

what do you mean by \"mess with the transport\"

", "time": "2023-07-24T17:15:53Z"}, {"author": "Robert Sparks", "text": "

remote people - is Richard Barnes coming through loud enough?

", "time": "2023-07-24T17:15:54Z"}, {"author": "John Klensin", "text": "

@Meetecho: having a lot of trouble hearing the floor mic. Alissa was tough, Richard incomprehensible

", "time": "2023-07-24T17:15:56Z"}, {"author": "Phillip Hallam-Baker", "text": "

Hmm, I can avoid the stall...

", "time": "2023-07-24T17:15:57Z"}, {"author": "James Gruessing", "text": "

@Robert he was loud and clear, as is Ali

", "time": "2023-07-24T17:16:14Z"}, {"author": "Ted Hardie", "text": "

@John A signal that says \"there is a 2MB shaper on this path\" might be completely application neutral; think of it like a pre-ECN signal. Different apps would have different responses to that message (and it is definitely better for ABR video than many others), but it can be done in ways that is app agnostic.

", "time": "2023-07-24T17:16:16Z"}, {"author": "John Klensin", "text": "

@Robert. Nope. Nor is this speaker

", "time": "2023-07-24T17:16:18Z"}, {"author": "Jonathan Lennox", "text": "

Richard was fairly off-mic. We should probably remind people to speak directly into the mic.

", "time": "2023-07-24T17:16:43Z"}, {"author": "Lorenzo Miniero", "text": "

@John Klensin we'll go check if the mic level is low in the mixer

", "time": "2023-07-24T17:16:55Z"}, {"author": "Daniel Gillmor", "text": "

@Ali Begen can you provide a pointer to the other work you're describing?

", "time": "2023-07-24T17:17:00Z"}, {"author": "Daniel Gillmor", "text": "

@Magnus Westerlund i missed your comment at the mic, i'd like to put it in the notes. can you repeat it here?

", "time": "2023-07-24T17:17:30Z"}, {"author": "John Klensin", "text": "

@Jonathan: yes, and to announce their names. Harald did both.

", "time": "2023-07-24T17:17:46Z"}, {"author": "Phillip Hallam-Baker", "text": "

If we are dealing with static data, accelerate the delivery rate till packets are dropped but at the lower quality until it is established that the link can cope with the higher speed.

", "time": "2023-07-24T17:17:46Z"}, {"author": "Pete Resnick", "text": "

@Jim Fenton Do remind people to say their name (and eat the mic).

", "time": "2023-07-24T17:18:41Z"}, {"author": "Ali Begen", "text": "

doing traffic shaping for abr without client's knowledge usually calls for a disaster. this is an outcome from 10+ year old research.

", "time": "2023-07-24T17:18:42Z"}, {"author": "Daniel Gillmor", "text": "

Phil, it sounds like you're talking about congestion control, no?

", "time": "2023-07-24T17:18:51Z"}, {"author": "Ali Begen", "text": "

@Daniel: https://cdn.cta.tech/cta/media/media/resources/standards/pdfs/cta-5004-final.pdf

", "time": "2023-07-24T17:19:34Z"}, {"author": "Ali Begen", "text": "

The sister spec is cta-5006

", "time": "2023-07-24T17:19:45Z"}, {"author": "Ali Begen", "text": "

MPEG spec is 23009-5: https://www.iso.org/standard/69079.html

", "time": "2023-07-24T17:20:09Z"}, {"author": "Lucas Pardue", "text": "

in the days of ABR video using plaintext HTTP, some operators were known to groom the media manifest and take out bitrates - that was terrible

", "time": "2023-07-24T17:20:32Z"}, {"author": "Ali Begen", "text": "

that is why manifests are encrypted now

", "time": "2023-07-24T17:21:28Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Daniel, only to the extent ABR is artificial congestion...

", "time": "2023-07-24T17:21:28Z"}, {"author": "Harald Alvestrand", "text": "

ESNI should terrify the traffic shapers...

", "time": "2023-07-24T17:21:34Z"}, {"author": "Ali Begen", "text": "

thanks to a few big SPs in the US...

", "time": "2023-07-24T17:21:42Z"}, {"author": "Phillip Hallam-Baker", "text": "

@ali and why RUD encrypts every part of every packet.

", "time": "2023-07-24T17:22:02Z"}, {"author": "Phillip Hallam-Baker", "text": "

[Except for initial helo]

", "time": "2023-07-24T17:22:16Z"}, {"author": "Richard Barnes", "text": "

/me points to EKT

", "time": "2023-07-24T17:26:02Z"}, {"author": "Harald Alvestrand", "text": "

Is RFC 4568 used in production?

", "time": "2023-07-24T17:26:48Z"}, {"author": "Jonathan Rosenberg", "text": "

I laud his completeness in dredging up old specs that hardly saw any deployment

", "time": "2023-07-24T17:27:52Z"}, {"author": "Rohan Mahy", "text": "

Alan Frindell said:


The client doesn't necessarily know about the desired rate from the network


which is in fact the whole problem. the client should be able to get that info from its L2 network and \"do the right thing\"

", "time": "2023-07-24T17:30:39Z"}, {"author": "Hang Shi", "text": "

What is L2 network?

", "time": "2023-07-24T17:31:54Z"}, {"author": "Jon Peterson", "text": "

Is there a non SIPREC requirement for this?

", "time": "2023-07-24T17:32:16Z"}, {"author": "Pete Resnick", "text": "

Hang Shi said:


What is L2 network?


Layer 2 network

", "time": "2023-07-24T17:32:31Z"}, {"author": "Harald Alvestrand", "text": "

Rohan: but in the general case, it's not his L2 network, it's one of the networks on the way between him and the content provider.
\nI was thinking of the case where the client is on 4G and switches to home wifi mid-video.

", "time": "2023-07-24T17:32:48Z"}, {"author": "Jon Peterson", "text": "

I mean it has no integrity protection anyway

", "time": "2023-07-24T17:33:16Z"}, {"author": "Hang Shi", "text": "

+1 to Harald

", "time": "2023-07-24T17:33:32Z"}, {"author": "Harald Alvestrand", "text": "

re a=crypto: isn't that considered a Bad Thing anyway?

", "time": "2023-07-24T17:33:50Z"}, {"author": "Harald Alvestrand", "text": "

(I only have two telcos to go before being able to delete that code from webrtc)

", "time": "2023-07-24T17:34:08Z"}, {"author": "Jonathan Lennox", "text": "

It is, but his point is that people are using it anyway.

", "time": "2023-07-24T17:34:11Z"}, {"author": "Richard Barnes", "text": "

can we not just throw this in an RTP extension and be done with it?

", "time": "2023-07-24T17:34:15Z"}, {"author": "Jonathan Lennox", "text": "

This is the information you need to decrypt/auth the RTP, so that's a chicken-and-egg problem.

", "time": "2023-07-24T17:34:46Z"}, {"author": "Harald Alvestrand", "text": "

so the real problem is that the frame counter has too few bits...

", "time": "2023-07-24T17:35:11Z"}, {"author": "Harald Alvestrand", "text": "

RTP header extension will work fine as long as you don't do CRYPTEX or header extension crypto.

", "time": "2023-07-24T17:36:12Z"}, {"author": "Harald Alvestrand", "text": "

and if you are using a=crypto, you don't care about security issues anyway.....

", "time": "2023-07-24T17:36:50Z"}, {"author": "Jonathan Rosenberg", "text": "

why do we need a new standard in this area?

", "time": "2023-07-24T17:38:53Z"}, {"author": "Jonathan Rosenberg", "text": "

(referring to S-expressions)

", "time": "2023-07-24T17:39:19Z"}, {"author": "Daniel Gillmor", "text": "

people are currently extending S-expression :grimacing:

", "time": "2023-07-24T17:39:34Z"}, {"author": "Daniel Gillmor", "text": "

(i don't know whether they're contemplating those extensions here)

", "time": "2023-07-24T17:39:52Z"}, {"author": "Jonathan Rosenberg", "text": "

So is this a historic spec?

", "time": "2023-07-24T17:39:56Z"}, {"author": "Carsten Bormann", "text": "

Jonathan: We don't. He is resurrecting old work.

", "time": "2023-07-24T17:40:07Z"}, {"author": "Carsten Bormann", "text": "


", "time": "2023-07-24T17:40:09Z"}, {"author": "Robert Sparks", "text": "

It's a thing that was in an ID that was lost

", "time": "2023-07-24T17:40:12Z"}, {"author": "Marc Petit-Huguenin", "text": "


", "time": "2023-07-24T17:40:19Z"}, {"author": "Murray Kucherawy", "text": "

Is this related to multiformats at all?

", "time": "2023-07-24T17:40:24Z"}, {"author": "Robert Sparks", "text": "

The real intent here is to document something that we _thought_ we had documented, but really didn't

", "time": "2023-07-24T17:40:32Z"}, {"author": "Murray Kucherawy", "text": "

which is seeking chartering

", "time": "2023-07-24T17:40:53Z"}, {"author": "Robert Sparks", "text": "

that last bullet

", "time": "2023-07-24T17:40:57Z"}, {"author": "Daniel Gillmor", "text": "

extended S-expressions: https://dev.gnupg.org/source/gnupg/browse/master/agent/keyformat.txt

", "time": "2023-07-24T17:41:13Z"}, {"author": "Daniel Gillmor", "text": "


", "time": "2023-07-24T17:41:56Z"}, {"author": "Carsten Bormann", "text": "

Murray: Are we going to talk about multi... today?

", "time": "2023-07-24T17:41:58Z"}, {"author": "Hang Shi", "text": "

The online conference link to SADCDN side meeting is TBD.

", "time": "2023-07-24T17:42:04Z"}, {"author": "Richard Barnes", "text": "

i see no value in IETF consensus on this

", "time": "2023-07-24T17:42:20Z"}, {"author": "Murray Kucherawy", "text": "

Carsten: \"we\" being DISPATCH, or you and me?

", "time": "2023-07-24T17:42:26Z"}, {"author": "Carsten Bormann", "text": "

ARTAREA, actually

", "time": "2023-07-24T17:42:36Z"}, {"author": "Pete Resnick", "text": "

Yeah, ISE sounds right for this.

", "time": "2023-07-24T17:42:45Z"}, {"author": "Phillip Hallam-Baker", "text": "

This should be an AD sponsored private draft. There is no scope for design changes.

", "time": "2023-07-24T17:42:48Z"}, {"author": "Murray Kucherawy", "text": "

It's not on the DISPATCH agenda as far as I know. There might be AOB time though if you want ot get some.

", "time": "2023-07-24T17:42:48Z"}, {"author": "Jonathan Rosenberg", "text": "

independent rfced submission

", "time": "2023-07-24T17:43:25Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Pete, yep, ISE would also work

", "time": "2023-07-24T17:43:29Z"}, {"author": "Jon Peterson", "text": "


", "time": "2023-07-24T17:43:32Z"}, {"author": "John Klensin", "text": "

@Pete: seems to me that the claim that this has actually been reviewed in the IETF as a stupidity check is worthwhile.

", "time": "2023-07-24T17:44:59Z"}, {"author": "Murray Kucherawy", "text": "

AD sponsorship isn't very fast these days...

", "time": "2023-07-24T17:45:12Z"}, {"author": "John Klensin", "text": "

And, since there have been a claim or two on IETF mailing lists that it is stupid (I disagree, but...)...

", "time": "2023-07-24T17:45:57Z"}, {"author": "Phillip Hallam-Baker", "text": "

Ask Eliot and see if he pushes back

", "time": "2023-07-24T17:46:06Z"}, {"author": "Carsten Bormann", "text": "

Correctly publishing a document that is being referenced by important historic documents is worth the while of the RFC process. Maybe not of the IETF. So ISE sounds right.

", "time": "2023-07-24T17:47:18Z"}, {"author": "Jonathan Lennox", "text": "

MIT reorganized their web pages so the link everyone was using went dead, so it's good to have it somewhere archival. +1 ISE.

", "time": "2023-07-24T17:47:45Z"}, {"author": "John Klensin", "text": "

Can't here Rich

", "time": "2023-07-24T17:48:20Z"}, {"author": "Carsten Bormann", "text": "

Rich's audio was fine

", "time": "2023-07-24T17:48:30Z"}, {"author": "Pete Resnick", "text": "

Rich was a bit quiet in the room. People are chicken about eating the mic.

", "time": "2023-07-24T17:49:17Z"}, {"author": "Magnus Westerlund", "text": "

Daniel Gillmor said:


Magnus Westerlund i missed your comment at the mic, i'd like to put it in the notes. can you repeat it here?


What I said was approximately: There are other use cases for a network <-> endpoint explicit communication which need a solution. Also with actual security between the entities communicating some of the security issues that was raised for general path signalling in PLUS and SPUD are dealt with.

", "time": "2023-07-24T17:50:56Z"}, {"author": "Jonathan Lennox", "text": "

Do we need to re-split ART?

", "time": "2023-07-24T17:56:20Z"}, {"author": "Murray Kucherawy", "text": "

The idea has been proposed.

", "time": "2023-07-24T17:56:35Z"}, {"author": "Jon Peterson", "text": "


", "time": "2023-07-24T17:57:13Z"}, {"author": "Pete Resnick", "text": "

@Jonathan Lennox Splitting should only be done if (a) the two proposed areas really don't have much participant overlap and (b) it's likely to stay that way for a long time.

", "time": "2023-07-24T17:57:55Z"}, {"author": "Hans-J\u00f6rg Happel", "text": "

@Johnathin: what were the historic components it was merged from?

", "time": "2023-07-24T17:58:06Z"}, {"author": "Pete Resnick", "text": "

Hans-J\u00f6rg Happel said:


@Johnathin: what were the historic components it was merged from?


Applications and Real-Time-Appplications-and-Infrastructure (RAI)

", "time": "2023-07-24T17:58:52Z"}, {"author": "Daniel Gillmor", "text": "

@Carsten Bormann i can relay from chat if you'd like that. i also didn't understand what you were asking for.

", "time": "2023-07-24T17:59:07Z"}, {"author": "Hans-J\u00f6rg Happel", "text": "

tnx Pete

", "time": "2023-07-24T17:59:11Z"}, {"author": "Pete Resnick", "text": "

RAI originally spun out of Transport

", "time": "2023-07-24T17:59:12Z"}, {"author": "Carsten Bormann", "text": "

@dkg -- I really just wanted to hear things at high bandwidth, sorry this didn't work

", "time": "2023-07-24T18:00:43Z"}]