[{"author": "Bron Gondwana", "text": "

Yep, I'm taking notes!

", "time": "2024-03-17T22:31:56Z"}, {"author": "Bron Gondwana", "text": "

well, not yet - nothing of note has happened so far

", "time": "2024-03-17T22:32:04Z"}, {"author": "Cindy Morgan", "text": "

Are remote folks hearing audio?

", "time": "2024-03-17T22:32:48Z"}, {"author": "John Levine", "text": "

yes

", "time": "2024-03-17T22:32:57Z"}, {"author": "David Weekly", "text": "

I'm remote and am hearing audio just fine.

", "time": "2024-03-17T22:32:58Z"}, {"author": "Prachi Jain", "text": "

yes

", "time": "2024-03-17T22:33:00Z"}, {"author": "Cindy Morgan", "text": "

thanks

", "time": "2024-03-17T22:33:09Z"}, {"author": "Robert Sparks", "text": "

remote audio is excellent even

", "time": "2024-03-17T22:33:10Z"}, {"author": "Randy Bush", "text": "

fine here

", "time": "2024-03-17T22:33:12Z"}, {"author": "John Levine", "text": "

Hard to believe it's a 20,000 km round trip

", "time": "2024-03-17T22:33:25Z"}, {"author": "Brian Carpenter", "text": "

Anybody care to estimate how many people are in the room?

", "time": "2024-03-17T22:34:12Z"}, {"author": "Eric Rescorla", "text": "

6?

", "time": "2024-03-17T22:34:20Z"}, {"author": "Daniel Gillmor", "text": "

10

", "time": "2024-03-17T22:34:30Z"}, {"author": "Tommy Jensen", "text": "

15

", "time": "2024-03-17T22:34:38Z"}, {"author": "Eric Rescorla", "text": "

0xf?

", "time": "2024-03-17T22:34:43Z"}, {"author": "Bron Gondwana", "text": "

200 +/- 50

", "time": "2024-03-17T22:34:53Z"}, {"author": "Eric Rescorla", "text": "

10^8?

", "time": "2024-03-17T22:35:00Z"}, {"author": "Daniel Gillmor", "text": "

what is counting?

", "time": "2024-03-17T22:35:04Z"}, {"author": "Bron Gondwana", "text": "

I'm measuring on smell

", "time": "2024-03-17T22:35:13Z"}, {"author": "Eric Rescorla", "text": "

0xf + 12i?

", "time": "2024-03-17T22:35:24Z"}, {"author": "Bron Gondwana", "text": "

everyone smells a little like a damp sheep

", "time": "2024-03-17T22:35:38Z"}, {"author": "Eric Rescorla", "text": "

That's pretty much like all of australia, right?

", "time": "2024-03-17T22:35:50Z"}, {"author": "Bron Gondwana", "text": "

it's been raining here in sunny Brisbane

", "time": "2024-03-17T22:36:00Z"}, {"author": "Christopher Allen", "text": "

Good morning DISPATCH (calling in virtual from a lovely Sunday afternoon in California).

", "time": "2024-03-17T22:36:02Z"}, {"author": "Brian Carpenter", "text": "

no, more NZ

", "time": "2024-03-17T22:36:06Z"}, {"author": "Bron Gondwana", "text": "

steady

", "time": "2024-03-17T22:36:12Z"}, {"author": "Randy Bush", "text": "

perhaps dissing people and the host country is a bit inappropriate

", "time": "2024-03-17T22:36:34Z"}, {"author": "Bron Gondwana", "text": "

it's the number one Australian hobby

", "time": "2024-03-17T22:37:14Z"}, {"author": "David Lawrence", "text": "

Huh being in the stage right side of the room is rather poor for seeing any slides

", "time": "2024-03-17T22:37:16Z"}, {"author": "Martin Thomson", "text": "

dissing the host country is totally fine here

", "time": "2024-03-17T22:37:19Z"}, {"author": "Bron Gondwana", "text": "

but yeah, we should probably focus on the work

", "time": "2024-03-17T22:37:21Z"}, {"author": "Martin Thomson", "text": "

this blocking thing tends to be seen as a feature, not a bug

", "time": "2024-03-17T22:37:57Z"}, {"author": "Daniel Gillmor", "text": "

port-based blocking or head-of-line blocking?

", "time": "2024-03-17T22:38:15Z"}, {"author": "Eric Rescorla", "text": "

So on the one hand, this seems like the right technical design.

", "time": "2024-03-17T22:38:19Z"}, {"author": "Martin Thomson", "text": "

port blocking

", "time": "2024-03-17T22:38:23Z"}, {"author": "David Lawrence", "text": "

port based

", "time": "2024-03-17T22:38:23Z"}, {"author": "Eric Rescorla", "text": "

(modulo the \"replace the fingerprint with the WebPKI\" part).

", "time": "2024-03-17T22:38:34Z"}, {"author": "Daniel Gillmor", "text": "

i was wondering who would see holb as a feature

", "time": "2024-03-17T22:38:40Z"}, {"author": "Bron Gondwana", "text": "

plenty of \"security\" is running ssh on a different port

", "time": "2024-03-17T22:38:43Z"}, {"author": "Eric Rescorla", "text": "

But OTOH, does anyone want it

", "time": "2024-03-17T22:38:47Z"}, {"author": "Bron Gondwana", "text": "

ssh -p 2222 foo@bar.host.com

", "time": "2024-03-17T22:38:57Z"}, {"author": "Eric Rescorla", "text": "

I mean, we could still run it over 22

", "time": "2024-03-17T22:39:01Z"}, {"author": "Eric Rescorla", "text": "

Just UDP 22

", "time": "2024-03-17T22:39:17Z"}, {"author": "Martin Thomson", "text": "

Yeah, port 22 seems to be available

", "time": "2024-03-17T22:39:22Z"}, {"author": "Neal Krawetz", "text": "

I've seen too many scanning bots look for ssh on any port. but knockd is a great for hiding ssh.

", "time": "2024-03-17T22:39:27Z"}, {"author": "Eric Rescorla", "text": "

also 22222

", "time": "2024-03-17T22:39:32Z"}, {"author": "Martin Thomson", "text": "

222222 would be better

", "time": "2024-03-17T22:39:43Z"}, {"author": "Daniel Gillmor", "text": "

ugh knockd

", "time": "2024-03-17T22:39:44Z"}, {"author": "Eric Rescorla", "text": "

2^22?

", "time": "2024-03-17T22:39:50Z"}, {"author": "Bron Gondwana", "text": "

yeah, I've done knockd protection. It's ugly but works

", "time": "2024-03-17T22:39:52Z"}, {"author": "Neal Krawetz", "text": "

@Daniel: Really? I like knockd. I wish sshd had it built-in!

", "time": "2024-03-17T22:40:10Z"}, {"author": "Eric Rescorla", "text": "

I think more seriously, why HTTP/3 and not just QUIC

", "time": "2024-03-17T22:40:12Z"}, {"author": "Rich Salz", "text": "

+ekr, same question from me

", "time": "2024-03-17T22:40:32Z"}, {"author": "Bron Gondwana", "text": "

(this slide answers that maybe)

", "time": "2024-03-17T22:40:33Z"}, {"author": "Lucas Pardue", "text": "

cos we can reuse HTTP auth mechanisms

", "time": "2024-03-17T22:40:36Z"}, {"author": "Bron Gondwana", "text": "

authentication[tm]

", "time": "2024-03-17T22:40:43Z"}, {"author": "Eric Rescorla", "text": "

HTTP auth mechanisms, are, you, know, bad

", "time": "2024-03-17T22:40:50Z"}, {"author": "Martin Thomson", "text": "

Lucas, that is NOT a feature

", "time": "2024-03-17T22:40:53Z"}, {"author": "Eric Rescorla", "text": "

I mean, much more important is whether you can use the SSH mechanisms

", "time": "2024-03-17T22:41:11Z"}, {"author": "Alex Chernyakhovsky", "text": "

I think the inverse question is just as reasonable, for MASQUE we moved CONNECT-IP from being a direct QUIC user to being HTTP.

", "time": "2024-03-17T22:41:12Z"}, {"author": "Lucas Pardue", "text": "

:smiling_face_with_tear:

", "time": "2024-03-17T22:41:19Z"}, {"author": "Christopher Allen", "text": "

Does this imply that the current SSH authentication would eventually become deprecated? There are aspects of peer-to-peer certificate in SSH, and its used in git for commit and tag signing, that are nice as they more distributed than HTTP certs.

", "time": "2024-03-17T22:41:24Z"}, {"author": "Martin Thomson", "text": "

Yeah, this whole HTTP integration seems unnecessary. SSH is important enough to do it properly.

", "time": "2024-03-17T22:41:29Z"}, {"author": "Eric Rescorla", "text": "

@Alex: I think that was for entirely different reasons

", "time": "2024-03-17T22:41:34Z"}, {"author": "Daniel Gillmor", "text": "

knockd is only good for protecting your logs from authentication attempts. if you want to actually protect the ssh accounts, you need a principled ssh authentication policy

", "time": "2024-03-17T22:41:38Z"}, {"author": "Neal Krawetz", "text": "

I'm liking this ssh over quic.

", "time": "2024-03-17T22:41:46Z"}, {"author": "Bron Gondwana", "text": "

on the more serious question: the dispatch, this feels like it needs its own WG

", "time": "2024-03-17T22:42:02Z"}, {"author": "Eric Rescorla", "text": "

Yeah, I think you'd pretty clearly want to reuse the existing keys.

", "time": "2024-03-17T22:42:03Z"}, {"author": "Bron Gondwana", "text": "

in TSV or SEC?

", "time": "2024-03-17T22:42:08Z"}, {"author": "Eric Rescorla", "text": "

Just like we did for TLS 1.3

", "time": "2024-03-17T22:42:08Z"}, {"author": "Martin Thomson", "text": "

Yes, this is very clearly something for which next steps is a BoF (not straight to WG)

", "time": "2024-03-17T22:42:26Z"}, {"author": "Eric Rescorla", "text": "

Well, I think the threshold question is: does anyone who actually implements SSH want this

", "time": "2024-03-17T22:42:27Z"}, {"author": "Bron Gondwana", "text": "

ooh, connection endpoint migration, I would love htat

", "time": "2024-03-17T22:42:42Z"}, {"author": "Martin Thomson", "text": "

A BoF can answer the threshold quesstion

", "time": "2024-03-17T22:42:44Z"}, {"author": "Eric Rescorla", "text": "

And without that, we don't need a BOF

", "time": "2024-03-17T22:42:44Z"}, {"author": "Jonathan Lennox", "text": "

Bron: WIT not TSV

", "time": "2024-03-17T22:42:45Z"}, {"author": "Bron Gondwana", "text": "

sorry yeah, that

", "time": "2024-03-17T22:42:54Z"}, {"author": "Bron Gondwana", "text": "

I can't acronym

", "time": "2024-03-17T22:42:57Z"}, {"author": "Eric Rescorla", "text": "

@MT: I actually think that we should have some sense of the threshold question before BOF

", "time": "2024-03-17T22:43:02Z"}, {"author": "Daniel Gillmor", "text": "

reusing existing keys sounds potentially risky to me. are we convinced that you can avoid breakage by cross-protocol key reuse?

", "time": "2024-03-17T22:43:07Z"}, {"author": "Martin Thomson", "text": "

@Ekr, I agree

", "time": "2024-03-17T22:43:13Z"}, {"author": "Bron Gondwana", "text": "

as a user, I want it!

", "time": "2024-03-17T22:43:14Z"}, {"author": "Christopher Allen", "text": "

Does this mean SSH auth starts using HPKE? Webauth?

", "time": "2024-03-17T22:43:26Z"}, {"author": "Martin Thomson", "text": "

The number of stars on the GitHub repo for the project indicates some level of interest.

", "time": "2024-03-17T22:43:28Z"}, {"author": "Eric Rescorla", "text": "

@DKG: I mean, we did it with TLS 1.2

", "time": "2024-03-17T22:43:40Z"}, {"author": "Tim Bray", "text": "

smells like a WG to me

", "time": "2024-03-17T22:44:15Z"}, {"author": "Daniel Gillmor", "text": "

yeah, and we ended up with some kind of bleichenbacher , right?

", "time": "2024-03-17T22:44:22Z"}, {"author": "Eric Rescorla", "text": "

@DKG, I don't think that was a cross-protocol attack really.

", "time": "2024-03-17T22:44:36Z"}, {"author": "Rich Salz", "text": "

Sending ctrl-[cz] over a separate quic stream wouild be a win.

", "time": "2024-03-17T22:44:43Z"}, {"author": "Martin Thomson", "text": "

This presentation is running a bit long in terms of answering the dispatch question. Are we going to start the dispatch process?

", "time": "2024-03-17T22:44:45Z"}, {"author": "Daniel Gillmor", "text": "

cross-version, not cross-protocol

", "time": "2024-03-17T22:44:50Z"}, {"author": "Bron Gondwana", "text": "

yeah, it's a bit overly detailed

", "time": "2024-03-17T22:45:02Z"}, {"author": "Maria Mat\u011bjka", "text": "

this looks funny regarding company-wide HTTPS MITM \"proxies\" :smiling_devil:

", "time": "2024-03-17T22:45:25Z"}, {"author": "Rich Salz", "text": "

would we want to maintain the SSH data protocol? toss it all out and simplify

", "time": "2024-03-17T22:45:55Z"}, {"author": "Daniel Gillmor", "text": "

reopen secsh?

", "time": "2024-03-17T22:46:00Z"}, {"author": "Eric Rescorla", "text": "

IIRC it was more like \"once you have a Bleichenbacher oracle in TLS 1.2, you could sort of use it on TLS 1.3 as well\", but that doesn't make matters worse

", "time": "2024-03-17T22:46:08Z"}, {"author": "Jason Livingood", "text": "

@martin good point - these should be really short and drive to 'where do we dispatch it to'

", "time": "2024-03-17T22:46:09Z"}, {"author": "Lucas Pardue", "text": "

there is an expired SSH over QUIC I-D that received feedback that it didn't use QUIC _enough_ https://datatracker.ietf.org/doc/draft-bider-ssh-quic/

", "time": "2024-03-17T22:46:24Z"}, {"author": "Murray Kucherawy", "text": "

Previous versions of ssh were never done through the IETF, right?

", "time": "2024-03-17T22:46:28Z"}, {"author": "Lucas Pardue", "text": "

@Murray Kucherawy https://datatracker.ietf.org/wg/secsh/about/

", "time": "2024-03-17T22:46:51Z"}, {"author": "John Klensin", "text": "

I also wonder whether the expectation is to replace SSH2 or to be available in parallel. Too many systems today that can handle SSH connections but not HTTP-ish ones

", "time": "2024-03-17T22:47:00Z"}, {"author": "Rich Salz", "text": "

right it was outside effort by one guy,, who then formed a company, and then came to the ietf after there was a f-ton of interest.

", "time": "2024-03-17T22:47:03Z"}, {"author": "Warren Kumari", "text": "

@Jason: Yes. This is a DISPATCH, not \"here is my draft in minute detail...\"

", "time": "2024-03-17T22:47:05Z"}, {"author": "Martin Thomson", "text": "

please, do not use webtransport

", "time": "2024-03-17T22:47:07Z"}, {"author": "Jason Livingood", "text": "

Kinda feels like debating the technical aspects is out of scoope (see long queue) ;-)

", "time": "2024-03-17T22:47:20Z"}, {"author": "Eric Rescorla", "text": "

I mean, SSHv2 will clearly be around more or less in perpetuity

", "time": "2024-03-17T22:47:25Z"}, {"author": "Stephen Farrell", "text": "

+1 to have a BoF

", "time": "2024-03-17T22:47:25Z"}, {"author": "Murray Kucherawy", "text": "

@Lucas: Thanks; was that v1 or v2?

", "time": "2024-03-17T22:47:31Z"}, {"author": "Murray Kucherawy", "text": "

way before my time

", "time": "2024-03-17T22:47:44Z"}, {"author": "Martin Thomson", "text": "

+1 to mnot

", "time": "2024-03-17T22:47:52Z"}, {"author": "Daniel Gillmor", "text": "

+1 to mnot

", "time": "2024-03-17T22:48:02Z"}, {"author": "Brian Carpenter", "text": "

TAPS?

", "time": "2024-03-17T22:48:09Z"}, {"author": "Tero Kivinen", "text": "

I think one big issue that authentication in ssh is based on known people, I do not want anybody I have not specifically given permissions even trying to connect my ssh server, but in HTTP the assumption is that everybody can connect to server. Also I do not trust anybody else than me to authenticate my server to me, thus using web certificates would be really bad for me...

", "time": "2024-03-17T22:48:15Z"}, {"author": "Lucas Pardue", "text": "

Murray Kucherawy said:

\n
\n

@Lucas: Thanks; was that v1 or v2?

\n
\n

no idea sorry

", "time": "2024-03-17T22:48:31Z"}, {"author": "Eric Rescorla", "text": "

@Tero: I agree that it would be bad to just replace SSH with WebPKI

", "time": "2024-03-17T22:48:41Z"}, {"author": "Daniel Gillmor", "text": "

+1 Tero: changing the authentication model for ssh while you change the transport model seems too risky

", "time": "2024-03-17T22:48:45Z"}, {"author": "David Lawrence", "text": "

I should know the answer to this, but what's the proper channel for reporting feedback about the room setup? Secretariat?

", "time": "2024-03-17T22:48:51Z"}, {"author": "Rich Salz", "text": "

Shupeng said email iesg

", "time": "2024-03-17T22:49:08Z"}, {"author": "David Lawrence", "text": "

ty

", "time": "2024-03-17T22:49:15Z"}, {"author": "Rich Salz", "text": "

yeah, the setup stinks.

", "time": "2024-03-17T22:49:21Z"}, {"author": "Maria Mat\u011bjka", "text": "

+1 Tero. Also the 1st connection trust issue is already solved by SSHFP.

", "time": "2024-03-17T22:49:22Z"}, {"author": "Lucas Pardue", "text": "

+1 BoF

", "time": "2024-03-17T22:49:27Z"}, {"author": "Murray Kucherawy", "text": "

I think there's an email address they want you to use, looking for it now.

", "time": "2024-03-17T22:49:39Z"}, {"author": "Jason Livingood", "text": "

+1 to a BoF

", "time": "2024-03-17T22:49:59Z"}, {"author": "Prachi Jain", "text": "

+1 BoF

", "time": "2024-03-17T22:50:16Z"}, {"author": "Martin Thomson", "text": "

For people who want to do HTTP, you can always run this over CONNECT-IP or CONNECT-UDP

", "time": "2024-03-17T22:50:20Z"}, {"author": "Richard Barnes", "text": "

+1 to BoF, but we shouldn't waste a whole IETF cycle, have an e-BoF

", "time": "2024-03-17T22:50:22Z"}, {"author": "Mark McFadden", "text": "

+1 to a BoF

", "time": "2024-03-17T22:50:25Z"}, {"author": "Suzanne Woolf", "text": "

+1 to Richard.

", "time": "2024-03-17T22:50:49Z"}, {"author": "Rich Salz", "text": "

+1 wg-forming bof. Need multiple video interims if not going to be F2F discussions about scope

", "time": "2024-03-17T22:50:50Z"}, {"author": "Andrew Campling", "text": "

A BoF seems the best place to deal with detailed questions of approach

", "time": "2024-03-17T22:50:58Z"}, {"author": "Orie Steele", "text": "

+1 to BoF

", "time": "2024-03-17T22:51:11Z"}, {"author": "David Lawrence", "text": "

The consensus of chat is clear at least

", "time": "2024-03-17T22:51:23Z"}, {"author": "Mark Nottingham", "text": "

+1 to eBof

", "time": "2024-03-17T22:51:29Z"}, {"author": "Martin Thomson", "text": "

ekr your audio isn't particularly clear

", "time": "2024-03-17T22:51:49Z"}, {"author": "Tero Kivinen", "text": "

ssh and ipsec authentication is between entities that do have direct trust relationship with each other. TLS/QUIC is completely different as there usually is not direct trust relationship especially when verifying the server.

", "time": "2024-03-17T22:51:55Z"}, {"author": "Daniel Gillmor", "text": "

ekr's audio was clear to me (given that he speaks at 1.0ekr)

", "time": "2024-03-17T22:52:14Z"}, {"author": "Dhruv Dhody", "text": "

Hearing this discussion, BOF makes sense!

", "time": "2024-03-17T22:52:24Z"}, {"author": "Mirja K\u00fchlewind", "text": "

+1 to BoF

", "time": "2024-03-17T22:52:33Z"}, {"author": "David Weekly", "text": "

Exciting to hear Google support

", "time": "2024-03-17T22:52:36Z"}, {"author": "Eric Rescorla", "text": "

OK, well I'm chaining microphones and we'll see

", "time": "2024-03-17T22:52:37Z"}, {"author": "Eric Rescorla", "text": "

changing

", "time": "2024-03-17T22:52:46Z"}, {"author": "Eric Rescorla", "text": "

The TCP fallback can just work in the usual way

", "time": "2024-03-17T22:52:58Z"}, {"author": "Jason Livingood", "text": "

@dlawrence Yes to email for now - recommend someone from AMS. I have asked them to add a link to reporting venue issues to the main 119 page at https://www.ietf.org/how/meetings/119/

", "time": "2024-03-17T22:53:08Z"}, {"author": "Yoav Nir", "text": "

@Tero: This is more a shell/VPN vs the web. All protocols support both.

", "time": "2024-03-17T22:53:24Z"}, {"author": "Pete Resnick", "text": "

+1 to @Richard Barnes : Virtual BOF if possible.

", "time": "2024-03-17T22:54:23Z"}, {"author": "Murray Kucherawy", "text": "

Yes, room feedback to the Secretariat please, not the IESG.

", "time": "2024-03-17T22:54:37Z"}, {"author": "Martin Thomson", "text": "

This one is easy: take it to TLS

", "time": "2024-03-17T22:55:02Z"}, {"author": "Eric Rescorla", "text": "

Or alternately \"just register your code points with an I-D\"

", "time": "2024-03-17T22:55:26Z"}, {"author": "Jason Livingood", "text": "

Re room feedback - Greg Wood is added a link under venue info on the main 119 page for this. In the meantime, report it via https://www.ietf.org/how/meetings/issues/

", "time": "2024-03-17T22:55:34Z"}, {"author": "Jim Fenton", "text": "

@meetecho I need a reminder how to grant the presenter control of the slides

", "time": "2024-03-17T22:55:40Z"}, {"author": "Pete Resnick", "text": "

@meetecho: Can we up the volume of remote participants?

", "time": "2024-03-17T22:55:48Z"}, {"author": "Jason Livingood", "text": "

s/added/adding

", "time": "2024-03-17T22:55:49Z"}, {"author": "Ben Campbell", "text": "

Traditionally in the various dispatch-process groups, the main argument for asking for a BOF was that something needed cross-area review. This _is_ a cross-area group. I know that's not the only meeting, but I wonder if the bar should be different now.

", "time": "2024-03-17T22:55:51Z"}, {"author": "Tim Bray", "text": "

\"next slide\" seems to be working

", "time": "2024-03-17T22:56:02Z"}, {"author": "Daniel Gillmor", "text": "

just lost Andrea audio

", "time": "2024-03-17T22:56:23Z"}, {"author": "Neal Krawetz", "text": "

Whew... I thought it was me.

", "time": "2024-03-17T22:56:35Z"}, {"author": "Wataru Ohgai", "text": "

seems muted

", "time": "2024-03-17T22:56:55Z"}, {"author": "Eric Rescorla", "text": "

Hah. I reconnected because I thought the audio was me

", "time": "2024-03-17T22:56:56Z"}, {"author": "Jason Livingood", "text": "

Frozen like ice. Ice, ice, baby.

", "time": "2024-03-17T22:57:00Z"}, {"author": "Francesca Palombini", "text": "

Ben: in this case I would think that a (wg forming) BoF was needed to figure out the details of what a possible charter would include, rather than the cross area review

", "time": "2024-03-17T22:57:02Z"}, {"author": "Martin Thomson", "text": "

Jason: ICE tends to be the problem, yes

", "time": "2024-03-17T22:57:13Z"}, {"author": "Tim Bray", "text": "

maybe move onto next press while Andrea debugs

", "time": "2024-03-17T22:57:15Z"}, {"author": "Eric Rescorla", "text": "

Maybe we can just close this presentation now with \"this goes to TLS\"

", "time": "2024-03-17T22:57:18Z"}, {"author": "Andrew Alston", "text": "

he was showing as muted

", "time": "2024-03-17T22:57:20Z"}, {"author": "Christopher Allen", "text": "

this one hits all of my keywords. I was editor of TLS, coined Self-Sovereign Identity, architect of DIDs, and invited expert on VCs. But there are a lot of issues of bringing this to IETF.

", "time": "2024-03-17T22:57:23Z"}, {"author": "Mirja K\u00fchlewind", "text": "

A bof is for cross area review. Dispatch was more an in area review. But I don\u2019t think that\u2019s the main point. It just a low bar to pitch some new work.

", "time": "2024-03-17T22:57:50Z"}, {"author": "Ben Campbell", "text": "

@francesca: My comment was not aimed at that particular item--just in general (And in keeping with Richard's \"extra 3 months\" comment)

", "time": "2024-03-17T22:57:56Z"}, {"author": "Christopher Allen", "text": "

SPICE charter is looking at BOF for VC-like functionality.

", "time": "2024-03-17T22:58:10Z"}, {"author": "Francesca Palombini", "text": "

Ben: got it :)

", "time": "2024-03-17T22:58:21Z"}, {"author": "Tom Hill", "text": "

Ahh, the universal fix for all connectivity issues: suggest moving on :grinning_face_with_smiling_eyes:

", "time": "2024-03-17T22:58:21Z"}, {"author": "Daniel Gillmor", "text": "

d'oh, lost audio again

", "time": "2024-03-17T22:58:24Z"}, {"author": "Martin Thomson", "text": "

NEXT PRESENTATION

", "time": "2024-03-17T22:58:33Z"}, {"author": "Tom Hill", "text": "

... I spoke too soon

", "time": "2024-03-17T22:58:39Z"}, {"author": "Orie Steele", "text": "

I read the draft, I think UTA is probably the right place.

", "time": "2024-03-17T22:58:44Z"}, {"author": "Tony Li", "text": "

It seems to me that we\u2019re getting too much technical detail (and time) on the proposals and that a much more condensed summary would be appropriate for this.

", "time": "2024-03-17T22:58:52Z"}, {"author": "Eric Rescorla", "text": "

Well, UTA shouldn't be registering code points in tLS

", "time": "2024-03-17T22:58:54Z"}, {"author": "Eric Rescorla", "text": "

@Tony: ++

", "time": "2024-03-17T22:58:59Z"}, {"author": "Mark Nottingham", "text": "

exactly - the only sensible place for this is tls

", "time": "2024-03-17T22:59:05Z"}, {"author": "Orie Steele", "text": "

^ except for that part EKR... agreed.

", "time": "2024-03-17T22:59:06Z"}, {"author": "Martin Thomson", "text": "

Feedback for ALLDISPATCH chairs: work with people to get more condensed presentations.

", "time": "2024-03-17T22:59:27Z"}, {"author": "Stephen Farrell", "text": "

does this VC stuff have a privacy issue that the pk is exposed to something when the tls server wants to use it?

", "time": "2024-03-17T22:59:31Z"}, {"author": "Jason Livingood", "text": "

+1 @TonyLi

", "time": "2024-03-17T22:59:32Z"}, {"author": "Eric Rescorla", "text": "

The presentation about hash elision is also too long based on the slides

", "time": "2024-03-17T22:59:54Z"}, {"author": "Robert Sparks", "text": "

Also wonder if this will keep people from making BoF proposals, thinking waiting for alldispatch will be easier.

", "time": "2024-03-17T23:00:13Z"}, {"author": "Jason Livingood", "text": "

Good coaching for the chairs afterwards. And probably each presenter should be prepped in advance on how to present & frame things here.

", "time": "2024-03-17T23:00:18Z"}, {"author": "Eric Rescorla", "text": "

Is there anything in this presentation which is going to change the outcome?

", "time": "2024-03-17T23:00:26Z"}, {"author": "Richard Barnes", "text": "

probably not

", "time": "2024-03-17T23:00:35Z"}, {"author": "Eric Rescorla", "text": "

Because it not, maybe we can just skip ahead

", "time": "2024-03-17T23:00:40Z"}, {"author": "Robert Sparks", "text": "

An alternate history would have had the ssh question beeing a BoF at this meeting if it had been proposed that way

", "time": "2024-03-17T23:00:43Z"}, {"author": "Christopher Allen", "text": "

The whole concept of \"decentralization\" in IETF standards is an interesting challenge.

", "time": "2024-03-17T23:01:05Z"}, {"author": "Richard Barnes", "text": "

@Robert all the more reason for an e-BoF. We need to quit fetishizing in-person

", "time": "2024-03-17T23:01:16Z"}, {"author": "Christopher Allen", "text": "

@Eric Rescorla Don't worry, we timed it at 8.5 minutes.

", "time": "2024-03-17T23:01:19Z"}, {"author": "Jason Livingood", "text": "

+1. Drive this to a decision and keep moving

", "time": "2024-03-17T23:01:25Z"}, {"author": "Orie Steele", "text": "

This side suggests TLS is the only place this could go.... to me.

", "time": "2024-03-17T23:01:43Z"}, {"author": "Stephen Farrell", "text": "

TLS is the place to process this IMO

", "time": "2024-03-17T23:01:56Z"}, {"author": "Eric Rescorla", "text": "

yes

", "time": "2024-03-17T23:01:56Z"}, {"author": "Tony Li", "text": "

I\u2019ll propose that we limit things to 1 slide and 3 minutes to present per document.

", "time": "2024-03-17T23:02:03Z"}, {"author": "Christopher Allen", "text": "

@Orie Steele but it sounds it more of an auth alternative.

", "time": "2024-03-17T23:02:05Z"}, {"author": "Eric Rescorla", "text": "

Or, you know, just individually register the code points

", "time": "2024-03-17T23:02:07Z"}, {"author": "Michael Prorock", "text": "

yes - tls

", "time": "2024-03-17T23:02:08Z"}, {"author": "Orie Steele", "text": "

if the draft was refactored to not have extensions, and just used service identity in TLS, UTA would be fine imo.

", "time": "2024-03-17T23:02:19Z"}, {"author": "Daniel Gillmor", "text": "

agreed, TLS seems like the right place. are the TLS chairs OK with that?

", "time": "2024-03-17T23:02:23Z"}, {"author": "Christopher Allen", "text": "

@Eric Rescorla Is integrating auth methods really future of TLS WG?

", "time": "2024-03-17T23:02:29Z"}, {"author": "Yoav Nir", "text": "

If you have a TLS handshake with changes in a slide, you need to take it to TLS

", "time": "2024-03-17T23:02:36Z"}, {"author": "Eric Rescorla", "text": "

In the spirit of saving time, I think we could have pre-sent these guys to TLS

", "time": "2024-03-17T23:02:38Z"}, {"author": "Pete Resnick", "text": "

@Tony Li I'm OK with 3 slides, 1 minute each.

", "time": "2024-03-17T23:02:43Z"}, {"author": "Henk Birkholz", "text": "

Why would you trust the resolve?

", "time": "2024-03-17T23:02:51Z"}, {"author": "Stephen Farrell", "text": "

DID resolve seems like clients doing OCSP checks in that it exposes to someone that the client is accessing the server at that point in time

", "time": "2024-03-17T23:02:56Z"}, {"author": "Andrew Campling", "text": "

Perhaps a template presentation

", "time": "2024-03-17T23:03:24Z"}, {"author": "Tommy Jensen", "text": "

Well, if the other slides didn't sell the tls WG recommendation, that handshake ASCII art sure did

", "time": "2024-03-17T23:03:29Z"}, {"author": "Mark McFadden", "text": "

+1 for sending this to TLS

", "time": "2024-03-17T23:03:49Z"}, {"author": "Eric Rescorla", "text": "

@Christopher Allen: I mean, probably not the greatest idea, but the actually TLS details are pretty trivial

", "time": "2024-03-17T23:03:59Z"}, {"author": "Martin Thomson", "text": "

Too much redundant detail in presentations is not a problem that can be solved with a template.

", "time": "2024-03-17T23:04:17Z"}, {"author": "Eric Rescorla", "text": "

Actually I take that back. This draft is trivial. Doing it right is not, as sftcd indicates

", "time": "2024-03-17T23:04:20Z"}, {"author": "Rich Salz", "text": "

The instructions for what to do were on the wiki, https://wiki.ietf.org/group/alldispatch which was mentioned in the call-for-presentations. So far, I'd say nobody read them.

", "time": "2024-03-17T23:04:26Z"}, {"author": "Christopher Allen", "text": "

There is a process problem of TLS group vs new auth methods.

", "time": "2024-03-17T23:04:38Z"}, {"author": "Rich Salz", "text": "

Chairs need to be empowered to say \"too much tech detail, condense it or we reject it\"

", "time": "2024-03-17T23:05:15Z"}, {"author": "Eric Rescorla", "text": "

@Rich: 100%

", "time": "2024-03-17T23:05:26Z"}, {"author": "Christopher Allen", "text": "

W3C would say they can't do extensions to TLS as it is IETF.

", "time": "2024-03-17T23:05:26Z"}, {"author": "Stephen Farrell", "text": "

wrt the meta-question of whether alldispatch is a good/bad idea, I'm reserving judgement until 2+ hours in to see how cranky everyone gets:-)

", "time": "2024-03-17T23:05:44Z"}, {"author": "Bron Gondwana", "text": "

ekr yes it's better

", "time": "2024-03-17T23:05:48Z"}, {"author": "Daniel Gillmor", "text": "

now ekr is not only too fast but too loud

", "time": "2024-03-17T23:05:52Z"}, {"author": "Rich Salz", "text": "

@dkg: It's almost like he was here in person

", "time": "2024-03-17T23:06:25Z"}, {"author": "Eric Rescorla", "text": "

Well, hopefully someone can tune my mic lower remotely

", "time": "2024-03-17T23:06:58Z"}, {"author": "Jason Livingood", "text": "

I have had my espresso and ekr is at normal speed for me ;-)

", "time": "2024-03-17T23:07:06Z"}, {"author": "Nick Sullivan", "text": "

As written, this draft forces VC auth to happen at handshake time.

", "time": "2024-03-17T23:07:20Z"}, {"author": "Daniel Gillmor", "text": "

@ekr, i think your mic was clipping, which can't really be fixed remotely

", "time": "2024-03-17T23:07:32Z"}, {"author": "Martin Thomson", "text": "

+1 to barnes

", "time": "2024-03-17T23:07:34Z"}, {"author": "Mark Nottingham", "text": "

+1 Richard - well seaid

", "time": "2024-03-17T23:07:45Z"}, {"author": "Eric Rescorla", "text": "

My input level is already quite low, so...

", "time": "2024-03-17T23:07:54Z"}, {"author": "Tim Bray", "text": "

That whole W3C VC/DID space is terrifyingly large and complex to me, but maybe I'm just slow on the pickup

", "time": "2024-03-17T23:07:57Z"}, {"author": "Henk Birkholz", "text": "

+1 Hannes

", "time": "2024-03-17T23:08:08Z"}, {"author": "Carsten Bormann", "text": "

+1 Tim

", "time": "2024-03-17T23:08:24Z"}, {"author": "Nick Sullivan", "text": "

For post-handshake with. It may be compatible with exported authenticators, but that isn\u2019t fleshed out in the draft and would need a higher level protocol like H2 on top.

", "time": "2024-03-17T23:08:25Z"}, {"author": "Martin Thomson", "text": "

Tommy has stolen our logo!

", "time": "2024-03-17T23:08:51Z"}, {"author": "Carsten Bormann", "text": "

The illusion that you can solve any problem by just providing a 100 options

", "time": "2024-03-17T23:08:51Z"}, {"author": "Eric Rescorla", "text": "

200 options.

", "time": "2024-03-17T23:09:00Z"}, {"author": "Martin Thomson", "text": "

Unless the plan is to do happy eyeballs over HTTP/3

", "time": "2024-03-17T23:09:09Z"}, {"author": "Carsten Bormann", "text": "

Sorry, like Tim I'm not up to date

", "time": "2024-03-17T23:09:11Z"}, {"author": "Bron Gondwana", "text": "

I could understand ekr the second time to take notes, so that's all that matters :p

", "time": "2024-03-17T23:09:17Z"}, {"author": "Eric Rescorla", "text": "

SSH over happy eyeballs over HTTP/3

", "time": "2024-03-17T23:09:23Z"}, {"author": "Daniel Gillmor", "text": "

with verifiable credentials

", "time": "2024-03-17T23:09:33Z"}, {"author": "Christian Huitema", "text": "

+1 for using Mike Bishop's art!

", "time": "2024-03-17T23:09:35Z"}, {"author": "Jason Livingood", "text": "

Happy Eyeballs: send it to TSVWG

", "time": "2024-03-17T23:10:06Z"}, {"author": "Martin Thomson", "text": "

Another presentation with too many slides

", "time": "2024-03-17T23:10:47Z"}, {"author": "Shuping Peng", "text": "

To the onsite presenters, you would need to use the full client meetecho to access in order to have the control of your slides. Otherwise, we cannot pass the control to you.

", "time": "2024-03-17T23:10:47Z"}, {"author": "Tommy Jensen", "text": "

Jason, just wait, it's not as transport as you might think from the last time we saw this presentation

", "time": "2024-03-17T23:10:57Z"}, {"author": "Tim Bray", "text": "

I'm presenting remote and I'd prefer to say \"next slide\" if that's OK

", "time": "2024-03-17T23:11:09Z"}, {"author": "Jim Fenton", "text": "

@tim OK

", "time": "2024-03-17T23:11:24Z"}, {"author": "Lorenzo Miniero", "text": "

@Shuping Peng no, the onsite tool supports controlling slides

", "time": "2024-03-17T23:11:27Z"}, {"author": "Stephen Farrell", "text": "

happy eyeballs: send to some WG, no strong opinion which

", "time": "2024-03-17T23:11:34Z"}, {"author": "Eric Rescorla", "text": "

Send to httpbis

", "time": "2024-03-17T23:11:43Z"}, {"author": "Jason Livingood", "text": "

@tommy but TSVWG is now Transport & Services - seems like a good match for new WG scope and a way to bring in folks across the stack

", "time": "2024-03-17T23:12:01Z"}, {"author": "Bill Fenner", "text": "

If anyone in the room is using a wifi hotspot ZTE_435119: it is transmitting at max power across 160MHz, interfering with at least 4 of the APs that IETF users are trying to use.

", "time": "2024-03-17T23:12:20Z"}, {"author": "Tommy Jensen", "text": "

@jason hmm, true, I forgot about that

", "time": "2024-03-17T23:12:33Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Happy eyeballs was in intarea but they want to do more than just IP. So the whole point of the dispatch session is really which area/group should this go

", "time": "2024-03-17T23:12:39Z"}, {"author": "Martin Thomson", "text": "

TSVWG seems like a reasonable call to me

", "time": "2024-03-17T23:12:39Z"}, {"author": "Shuping Peng", "text": "

We can only see \"chat\" and \"open profile\", no \"pass control\"

", "time": "2024-03-17T23:12:42Z"}, {"author": "Christian Huitema", "text": "

Happy eyeball: send to several WG in parallel, pick the one that accepts the draft first!

", "time": "2024-03-17T23:12:46Z"}, {"author": "Eric Rescorla", "text": "

@Bill Fenner: that's mine, but it's here in California, I just dialed up the transmit power a lot

", "time": "2024-03-17T23:12:55Z"}, {"author": "Bron Gondwana", "text": "

+100

", "time": "2024-03-17T23:12:55Z"}, {"author": "Tommy Jensen", "text": "

@christian xD

", "time": "2024-03-17T23:12:58Z"}, {"author": "Martin Duke", "text": "

@jason if tsvwg scope has changed, I wrote the recharter poorly

", "time": "2024-03-17T23:12:58Z"}, {"author": "Brian Carpenter", "text": "

The expertise is in v6ops if it's anywhere

", "time": "2024-03-17T23:12:59Z"}, {"author": "Jason Livingood", "text": "

:eyes::eye:\ufe0f:eyes::eye:\ufe0f

", "time": "2024-03-17T23:13:04Z"}, {"author": "Tommy Jensen", "text": "

v6ops rejected this at 118

", "time": "2024-03-17T23:13:12Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@Christian Huitema that finishes the draft first :wink:

", "time": "2024-03-17T23:13:25Z"}, {"author": "Bill Fenner", "text": "

@Eric Rescorla I want to see that antenna

", "time": "2024-03-17T23:13:31Z"}, {"author": "Eric Rescorla", "text": "

Pringles can and a Tesla Powerwall

", "time": "2024-03-17T23:13:42Z"}, {"author": "Brian Carpenter", "text": "

@tommy: and maybe they were wrong

", "time": "2024-03-17T23:13:48Z"}, {"author": "Pete Resnick", "text": "

Again, this is too long for a dispatch discussion. \ud83e\udee4

", "time": "2024-03-17T23:13:52Z"}, {"author": "Jason Livingood", "text": "

@martin seems a place where folks understand transport and svcs - so a good match

", "time": "2024-03-17T23:13:54Z"}, {"author": "Donald Eastlake", "text": "

Should clearly be sent to multiple WGs so they can race to handle it. This is the Happy Protocol dispatch method.

", "time": "2024-03-17T23:14:30Z"}, {"author": "Jason Livingood", "text": "

@martin - other WGs would be just layer 7 or layer 3, nice to have a place that can bridge

", "time": "2024-03-17T23:14:45Z"}, {"author": "Tommy Jensen", "text": "

@brian I think it was the right call considering how far above IP this proposal goes, but I'm happier to be proved that I'm eyeballing this incorrectly

", "time": "2024-03-17T23:14:47Z"}, {"author": "Mirja K\u00fchlewind", "text": "

do we need a new working group?

", "time": "2024-03-17T23:14:50Z"}, {"author": "Adrian Farrel", "text": "

What is the implication of not standardising the algorithm? Would that impact interoperability?

", "time": "2024-03-17T23:14:56Z"}, {"author": "David Lawrence", "text": "

It'd be an interesting test of the IETF wg efficiency

", "time": "2024-03-17T23:14:57Z"}, {"author": "Ted Hardie", "text": "

@Tommy If it got rejected there at 118, why did you bring it here and not as a BoF?

", "time": "2024-03-17T23:15:11Z"}, {"author": "Martin Thomson", "text": "

@adrian I believe that this is about having people avoid patterns that are harmful

", "time": "2024-03-17T23:15:20Z"}, {"author": "Tommy Jensen", "text": "

(possibly wrong Tommy, I'm not a co-author, Tommy Pauly is)

", "time": "2024-03-17T23:15:31Z"}, {"author": "Eric Rescorla", "text": "

@Ted: maybe you could ask this at the mic

", "time": "2024-03-17T23:15:35Z"}, {"author": "Martin Thomson", "text": "

and describing good patterns

", "time": "2024-03-17T23:15:36Z"}, {"author": "Stephen Farrell", "text": "

as an FYI, curl needs something like this to handle SVCB/HTTPS properly and it'd be a BIG change for that code, so something well thought out seems like a v. good idea

", "time": "2024-03-17T23:15:49Z"}, {"author": "Brian Carpenter", "text": "

I don't think it will get enough attention in a non-v6 WG. Although there's a relationship to TAPS.

", "time": "2024-03-17T23:15:54Z"}, {"author": "Jason Livingood", "text": "

@mirja IMO no new WG unless there are many more I-Ds coming related to this. Just send to an existing WG so we can focus on sorting the tech details vs administrivia of setting up a new WG

", "time": "2024-03-17T23:15:55Z"}, {"author": "Eric Rescorla", "text": "

I didn't understand the bit about racing full connections

", "time": "2024-03-17T23:16:00Z"}, {"author": "Daniel Gillmor", "text": "

describing specifically what is good to do is super useful. we don't give implementers nearly enough guidance like that

", "time": "2024-03-17T23:16:05Z"}, {"author": "Eric Rescorla", "text": "

I'm worried it might have a downgrade attack, but I guess we could sort tha tout

", "time": "2024-03-17T23:16:13Z"}, {"author": "Martin Thomson", "text": "

the downgrade attacks are real

", "time": "2024-03-17T23:16:26Z"}, {"author": "Lucas Pardue", "text": "

I have lots of anecdotes of people that are eternally confused by user agent decision making wrt to IP and transport proto selection

", "time": "2024-03-17T23:16:26Z"}, {"author": "Daniel Gillmor", "text": "

@ekr i think the question is when do you decide that one connection has \"won\"

", "time": "2024-03-17T23:16:28Z"}, {"author": "Christian Huitema", "text": "

I really wonder whether this kind of algorithms should be standardized in the first place. These are entirely based on local actions, with unilateral deployment in clients.

", "time": "2024-03-17T23:16:43Z"}, {"author": "Eric Rescorla", "text": "

@DKG: correct. So what happens if the attacker wants to block one ALPN

", "time": "2024-03-17T23:16:48Z"}, {"author": "Pete Resnick", "text": "

@Brian Carpenter TAPS is an interesting choice.

", "time": "2024-03-17T23:16:55Z"}, {"author": "Yoav Nir", "text": "

Describing what clients should do can help avoid firewalls blocking them as \"behaving suspiciously\"

", "time": "2024-03-17T23:17:09Z"}, {"author": "Martin Thomson", "text": "

For downgrade: https://datatracker.ietf.org/doc/html/draft-thomson-tls-sic-00

", "time": "2024-03-17T23:17:11Z"}, {"author": "Daniel Gillmor", "text": "

@ekr: they can do that as long as there's no ECH

", "time": "2024-03-17T23:17:12Z"}, {"author": "Magnus Westerlund", "text": "

I think racing full connections, is meaning that you race untill you actually can transmitt application data on the connection.

", "time": "2024-03-17T23:17:19Z"}, {"author": "Tommy Jensen", "text": "

@christian agreed, I'm not convinced there can be consensus on a correct priority ordering of these dimensions versus the more simple \"IPv6 > IPv4\"

", "time": "2024-03-17T23:17:21Z"}, {"author": "Brian Carpenter", "text": "

@Pete: yes, TAPS has to do some of the same

", "time": "2024-03-17T23:17:24Z"}, {"author": "Eric Rescorla", "text": "

@DKG: as long as there is diversity along the ALPN axis, yes

", "time": "2024-03-17T23:17:25Z"}, {"author": "Brian Carpenter", "text": "

+1 to the importance

", "time": "2024-03-17T23:17:46Z"}, {"author": "Stephen Farrell", "text": "

I dunno the internal dynamics of v6ops or tsvwg but ignoring that, the latter seems like a better fit given what's new here

", "time": "2024-03-17T23:17:58Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Recharter Taps\u2026.?

", "time": "2024-03-17T23:18:32Z"}, {"author": "Pete Resnick", "text": "

@Mirja K\u00fchlewind A simple addition to deal with this particular bit might be OK.

", "time": "2024-03-17T23:19:10Z"}, {"author": "Brian Carpenter", "text": "

@mirja: maybe, but they aren't done yet on their main job?

", "time": "2024-03-17T23:19:12Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Taps is done

", "time": "2024-03-17T23:19:35Z"}, {"author": "Mirja K\u00fchlewind", "text": "

all docs with IESG

", "time": "2024-03-17T23:19:41Z"}, {"author": "Daniel Gillmor", "text": "

the interesting challenge here is that this new protocol is no longer optimizing specifically for speed; preferring ECH suggests a distinct prioritization, which might be at odds with speed.

", "time": "2024-03-17T23:19:45Z"}, {"author": "David Lawrence", "text": "

\"but we don't do policy\" except when we do policy

", "time": "2024-03-17T23:20:13Z"}, {"author": "Martin Thomson", "text": "

This speed/security balance is something endpoints might want to differentiate on.

", "time": "2024-03-17T23:20:29Z"}, {"author": "Eric Rescorla", "text": "

So it's one thing to do HTTP/2 vs. HTTP/3, when they ostensibly have similar security properties.

", "time": "2024-03-17T23:21:05Z"}, {"author": "Eric Rescorla", "text": "

But you really can't race ECH and non-ECH for obvious reasons!

", "time": "2024-03-17T23:21:11Z"}, {"author": "Orie Steele", "text": "

leaning towards BoF / new WG... based on comments from others.

", "time": "2024-03-17T23:21:12Z"}, {"author": "Francesca Palombini", "text": "

@Ted do you think that the scope is clear enough for a wg to be formed directly without BoF?

", "time": "2024-03-17T23:21:24Z"}, {"author": "Stephen Farrell", "text": "

new WG with no BoF needed would be my gtake

", "time": "2024-03-17T23:21:33Z"}, {"author": "Michael Prorock", "text": "

+1 taps with a short recharter would be a much better path than a new wg

", "time": "2024-03-17T23:21:45Z"}, {"author": "Ted Hardie", "text": "

@Francesca not yet, but it could be hammered out without a BoF, so I don't think you need to wait for IETF 120

", "time": "2024-03-17T23:22:14Z"}, {"author": "Martin Thomson", "text": "

I tend to think that HTTP/2 vs HTTP/3 selection on the basis of security does bias toward h3, but there are some axes of speed that favour h2.

", "time": "2024-03-17T23:22:15Z"}, {"author": "Eric Rescorla", "text": "

Just turn your APs to 161 Mhz!

", "time": "2024-03-17T23:22:16Z"}, {"author": "Eric Rescorla", "text": "

:)

", "time": "2024-03-17T23:22:17Z"}, {"author": "Ted Hardie", "text": "

Yes

", "time": "2024-03-17T23:23:27Z"}, {"author": "Mark McFadden", "text": "

What was the dispatch decision on happy eyeballs? I didn\u2019t catch it.

", "time": "2024-03-17T23:23:42Z"}, {"author": "Eric Rescorla", "text": "

New WG

", "time": "2024-03-17T23:23:48Z"}, {"author": "Daniel Gillmor", "text": "

sounded like new WG to me

", "time": "2024-03-17T23:23:53Z"}, {"author": "Brian Carpenter", "text": "

(but get the TAPS expertise in!)

", "time": "2024-03-17T23:24:11Z"}, {"author": "Daniel Gillmor", "text": "

(and security expertise as well)

", "time": "2024-03-17T23:24:23Z"}, {"author": "Matt Joras", "text": "

Martin Thomson said:

\n
\n

I tend to think that HTTP/2 vs HTTP/3 selection on the basis of security does bias toward h3, but there are some axes of speed that favour h2.

\n
\n

Curious what speed things are you thinking that favor h2?

", "time": "2024-03-17T23:24:24Z"}, {"author": "Eric Rescorla", "text": "

Or change your name to Dianne Weekly

", "time": "2024-03-17T23:24:31Z"}, {"author": "Eric Rescorla", "text": "

Or Dianne Doug Weekly

", "time": "2024-03-17T23:24:44Z"}, {"author": "Daniel Gillmor", "text": "

@ekr, i did that back in the day to get more 12 CDs for a penny

", "time": "2024-03-17T23:25:01Z"}, {"author": "Martin Thomson", "text": "

@Matt raw throughput is still, sometimes, better.

", "time": "2024-03-17T23:25:06Z"}, {"author": "Jim Fenton", "text": "

It's sometimes fun...I once picked the wedding music for another Jim Fenton

", "time": "2024-03-17T23:25:10Z"}, {"author": "David Lawrence", "text": "

I do, however, have procmail so POOF

", "time": "2024-03-17T23:25:17Z"}, {"author": "Jason Livingood", "text": "

@Jim LOL

", "time": "2024-03-17T23:25:26Z"}, {"author": "Tim Bray", "text": "

I got an email this morning with some kid's report card from a primary school in a different country.

", "time": "2024-03-17T23:25:45Z"}, {"author": "Bron Gondwana", "text": "

we've been talking about \"trust and safety\" response to extend unsubscribe for more than just this

", "time": "2024-03-17T23:25:45Z"}, {"author": "David Lawrence", "text": "

Oh how I loathe noreply@

", "time": "2024-03-17T23:26:11Z"}, {"author": "Ted Hardie", "text": "

@Tim. How's the kid doing? Redirection could be a mitzvah, or maybe not.

", "time": "2024-03-17T23:26:14Z"}, {"author": "Tim Bray", "text": "

snicker

", "time": "2024-03-17T23:26:23Z"}, {"author": "Michael Prorock", "text": "

the current chat has improved my outlook on the day considerably

", "time": "2024-03-17T23:26:45Z"}, {"author": "Richard Barnes", "text": "

i don't care how we do this, let's do it

", "time": "2024-03-17T23:26:57Z"}, {"author": "David Lawrence", "text": "

SMS spam has taught me well to not ever respond \"you have the wrong recipient\"

", "time": "2024-03-17T23:26:59Z"}, {"author": "Orie Steele", "text": "

^ that

", "time": "2024-03-17T23:27:14Z"}, {"author": "Daniel Gillmor", "text": "

the big question is \"how will people abuse this?\"

", "time": "2024-03-17T23:27:24Z"}, {"author": "John Levine", "text": "

I deleted two messages to the wrong John Levine during this session, so yes.

", "time": "2024-03-17T23:27:30Z"}, {"author": "Martin Thomson", "text": "

an automated \"you have the wrong recipient\" might not be as vulnerable to those fishing attacks

", "time": "2024-03-17T23:27:48Z"}, {"author": "Richard Barnes", "text": "

@dkg i thought about this for a second, liveness verification was the only thing that occurred to me

", "time": "2024-03-17T23:27:56Z"}, {"author": "Timothy Holborn", "text": "

useful for work email accounts, redirecting if a person moves to a different company or gov. department, etc.

", "time": "2024-03-17T23:28:11Z"}, {"author": "John Levine", "text": "

Spammers don't care about liveness, they just blast out to everything on their list

", "time": "2024-03-17T23:28:17Z"}, {"author": "Richard Barnes", "text": "

yeah, i expeect this would manifest as an MUA button, not something that would be phishable

", "time": "2024-03-17T23:28:19Z"}, {"author": "Daniel Gillmor", "text": "

@Timothy, i think those are pretty distinct semantics

", "time": "2024-03-17T23:28:28Z"}, {"author": "John Levine", "text": "

Just like the unsubscribe button that's already there

", "time": "2024-03-17T23:28:49Z"}, {"author": "Michael Prorock", "text": "

this way it can be totally honored the way unsubscribe is :)

", "time": "2024-03-17T23:29:20Z"}, {"author": "Wataru Ohgai", "text": "

Spammers won't implement this. They already have several means to check if the address is alive.

", "time": "2024-03-17T23:29:28Z"}, {"author": "Eric Rescorla", "text": "

For some reason I don't get a lot of misaddressed email

", "time": "2024-03-17T23:29:30Z"}, {"author": "Pete Resnick", "text": "

@Murray Kucherawy I want to dispatch this to a not-yet-existing WG.

", "time": "2024-03-17T23:29:32Z"}, {"author": "Neal Krawetz", "text": "

For wrong recipient: How do you prevent someone from using this to scan for email addresses on the server?

", "time": "2024-03-17T23:29:36Z"}, {"author": "Daniel Gillmor", "text": "

@Pete +1 :P

", "time": "2024-03-17T23:29:50Z"}, {"author": "Stephen Farrell", "text": "

I also feel left out here, don't think I ever got one of these

", "time": "2024-03-17T23:29:52Z"}, {"author": "Murray Kucherawy", "text": "

@Pete: Yep.

", "time": "2024-03-17T23:30:03Z"}, {"author": "Murray Kucherawy", "text": "

If I could figure out how to join the queue, I'd say that.

", "time": "2024-03-17T23:30:08Z"}, {"author": "Alexey Melnikov", "text": "

@Pete + 1 :-)

", "time": "2024-03-17T23:30:09Z"}, {"author": "Tim Bray", "text": "

@ekr I get loads: Banks, schools, Sam's club. Probably having to do with how common one's name is?

", "time": "2024-03-17T23:30:13Z"}, {"author": "Daniel Gillmor", "text": "

someone sign up Stephen and ekr to their children's learning management system

", "time": "2024-03-17T23:30:15Z"}, {"author": "Jonathan Lennox", "text": "

WHere was 8058 done?

", "time": "2024-03-17T23:30:16Z"}, {"author": "Richard Barnes", "text": "

AD-sponsored seems fine to me

", "time": "2024-03-17T23:30:22Z"}, {"author": "Mike Bishop", "text": "

@Neal, that's already possible -- you just attempt to deliver mail and see what gets an NDR.

", "time": "2024-03-17T23:30:28Z"}, {"author": "Richard Barnes", "text": "

@Jonathan AD sponsored IIRC

", "time": "2024-03-17T23:30:28Z"}, {"author": "Murray Kucherawy", "text": "

Where's my \"AD Sponssored\" meme when I need it

", "time": "2024-03-17T23:30:35Z"}, {"author": "Martin Thomson", "text": "

can we create a new email maintenance working group? we can call it MAILMAN. No risk of confusion there.

", "time": "2024-03-17T23:30:38Z"}, {"author": "Eric Rescorla", "text": "

@Tim Bray: yes, that was the joke I was making

", "time": "2024-03-17T23:30:39Z"}, {"author": "Murray Kucherawy", "text": "

@Martin Thomson: In progress.

", "time": "2024-03-17T23:30:50Z"}, {"author": "Rohan Mahy", "text": "

I get tons for my rohan@rohan address. Mostly for services in India

", "time": "2024-03-17T23:31:17Z"}, {"author": "John Gray", "text": "

I think this is more of a problem for people with common names. My name is common so I get these kinds of mails all the time.

", "time": "2024-03-17T23:31:24Z"}, {"author": "Tim Bray", "text": "

@ekr was going to say \"your name is weird\" but that felt rude

", "time": "2024-03-17T23:31:39Z"}, {"author": "Robert Moskowitz", "text": "

When I wrote for Network Computing, there was another Robert Moskowitz writing for Windows Magazine. That is pretty much the only time I got someone else's mail. But I can see for some, this would be of value. If it does not make more work....

", "time": "2024-03-17T23:31:44Z"}, {"author": "Daniel Gillmor", "text": "

i used to work with john@john.org in the late '90s. he got loads of \"interesting\" stuff

", "time": "2024-03-17T23:31:58Z"}, {"author": "Michael Prorock", "text": "

my name is not super common, but i still get confliict between myself and michael prorok

", "time": "2024-03-17T23:32:18Z"}, {"author": "Rich Salz", "text": "

8058 was non-WG (primary author john levine)

", "time": "2024-03-17T23:32:18Z"}, {"author": "Martin Thomson", "text": "

https://www.ietf.org/mailman/listinfo/mailman :scream:

", "time": "2024-03-17T23:32:21Z"}, {"author": "Pete Resnick", "text": "

Some AD just cursed @Christopher Allen name. :wink:

", "time": "2024-03-17T23:32:26Z"}, {"author": "Richard Barnes", "text": "

this reminds me of that time APNIC advertised 1.1.1.0/24 and got like 100Mbps of junk

", "time": "2024-03-17T23:32:29Z"}, {"author": "Alexey Melnikov", "text": "

Murray has things to say about \u201cjust send to AD\u201d

", "time": "2024-03-17T23:32:40Z"}, {"author": "Michael Prorock", "text": "

rofl

", "time": "2024-03-17T23:32:50Z"}, {"author": "Daniel Gillmor", "text": "

+1 to mailmaint

", "time": "2024-03-17T23:32:51Z"}, {"author": "Murray Kucherawy", "text": "

Thank you for your support. :)

", "time": "2024-03-17T23:33:27Z"}, {"author": "John Gray", "text": "

Robert, when I worked for Nortel many years ago there were 2 other John Gray's there, so I got wrong emails daily. Lol...

", "time": "2024-03-17T23:33:29Z"}, {"author": "Tobias Fiebig", "text": "

+1 to not send to ad;

", "time": "2024-03-17T23:33:29Z"}, {"author": "Deb Cooley", "text": "

@DKG +100000

", "time": "2024-03-17T23:33:34Z"}, {"author": "Rich Salz", "text": "

advice to mail systems: if you auto-file this to SPAM folder, don't add the \"misdelivered\" button

", "time": "2024-03-17T23:33:37Z"}, {"author": "Jonathan Hoyland", "text": "

Is this a XSRF vuln?

", "time": "2024-03-17T23:33:40Z"}, {"author": "Eric Rescorla", "text": "

Send to SEC AD?

", "time": "2024-03-17T23:33:45Z"}, {"author": "Daniel Gillmor", "text": "

@hoyland: exactly what i was thinking

", "time": "2024-03-17T23:33:57Z"}, {"author": "Richard Barnes", "text": "

Yeah, i think we should assign it to the newest SEC AD

", "time": "2024-03-17T23:33:59Z"}, {"author": "Jonathan Hoyland", "text": "

Or do I mean that? Like the one where I can make the victim visit a random link

", "time": "2024-03-17T23:34:11Z"}, {"author": "Spencer Dawkins", "text": "

I'm only sorry that Murray didn't say that the DISPATCH request was directed to the wrong recipient ...

", "time": "2024-03-17T23:34:12Z"}, {"author": "Deb Cooley", "text": "

@RB: no

", "time": "2024-03-17T23:34:21Z"}, {"author": "Richard Barnes", "text": "

Counterpoint: Yes!

", "time": "2024-03-17T23:34:45Z"}, {"author": "Eric Rescorla", "text": "

As Richard once said, the \"junior SEC AD\"

", "time": "2024-03-17T23:35:03Z"}, {"author": "Deb Cooley", "text": "

@ekr: I'd take that as a compliment....

", "time": "2024-03-17T23:35:25Z"}, {"author": "Eric Rescorla", "text": "

Dear Chairs: this is a good example of material that is irrelevant to the DISPATCH quesiton

", "time": "2024-03-17T23:35:38Z"}, {"author": "Orie Steele", "text": "

This should go to COSE... but it will probably take a while to see why.

", "time": "2024-03-17T23:35:45Z"}, {"author": "Richard Wilhelm", "text": "

there are likely security considerations on that previous item ... forged \"wrong recipient\" messages could unsubscribe me from billing notifications, etc (I think that was part of the point that was made at the last statement at the mic)

", "time": "2024-03-17T23:35:52Z"}, {"author": "Bron Gondwana", "text": "

mail providers are already really clear on \"only provide list unsubscribe if you think the provider isn't a general spammer\"

", "time": "2024-03-17T23:36:23Z"}, {"author": "Michael Prorock", "text": "

this should maybe go to COSE if it should go anywhere at ietf.... but i wonder if we will get to something ietf related

", "time": "2024-03-17T23:36:23Z"}, {"author": "Rich Salz", "text": "

These slides reek of marketing.

", "time": "2024-03-17T23:36:29Z"}, {"author": "Eric Rescorla", "text": "

Well once again, who at IETF wants this

", "time": "2024-03-17T23:36:34Z"}, {"author": "Shuping Peng", "text": "

@Eric, suggestions were given

", "time": "2024-03-17T23:36:36Z"}, {"author": "Eric Rescorla", "text": "

@Shuping: you need to make them more than suggestions

", "time": "2024-03-17T23:36:51Z"}, {"author": "Bron Gondwana", "text": "

WE WANT THE POLICE

", "time": "2024-03-17T23:37:12Z"}, {"author": "Eric Rescorla", "text": "

You will notice that HRPC isn't even an IETF document

", "time": "2024-03-17T23:37:18Z"}, {"author": "Bron Gondwana", "text": "

^ TO BE

", "time": "2024-03-17T23:37:21Z"}, {"author": "Robert Sparks", "text": "

13 of 41?

", "time": "2024-03-17T23:37:22Z"}, {"author": "David Weekly", "text": "

Richard: this is why the draft mandates having the sender include difficult-to-guess components in the URL, such as signing the URL or using a UUID, so third parties can't submit malicious wrong recipient notifications.

", "time": "2024-03-17T23:37:29Z"}, {"author": "Eric Rescorla", "text": "

Nor is 6973!

", "time": "2024-03-17T23:37:43Z"}, {"author": "Martin Thomson", "text": "

Bitcoin is an object lesson in many different ways.

", "time": "2024-03-17T23:38:12Z"}, {"author": "Richard Wilhelm", "text": "

@David: thx

", "time": "2024-03-17T23:38:15Z"}, {"author": "David Weekly", "text": "

Rich Salz said:

\n
\n

advice to mail systems: if you auto-file this to SPAM folder, don't add the \"misdelivered\" button

\n
\n

Totally - that's part of the draft, too. Only show a misdelivered button if confident it's not spam.

", "time": "2024-03-17T23:38:16Z"}, {"author": "Rich Salz", "text": "

+1 @david, thanks.

", "time": "2024-03-17T23:38:31Z"}, {"author": "Pete Resnick", "text": "

Chairs: You accepted these 41 slides, so we're going to have to suck it up, but please don't do that again.

", "time": "2024-03-17T23:38:42Z"}, {"author": "Martin D\u00fcrst", "text": "

Is there a mailing list for mailmaint now? I didn't find anything on https://www.ietf.org/mailman/listinfo/ that i thought was matching.

", "time": "2024-03-17T23:39:04Z"}, {"author": "Bron Gondwana", "text": "

when in doubt, use more slides!

", "time": "2024-03-17T23:39:08Z"}, {"author": "Carsten Bormann", "text": "

41 takahasi slides is no problem, if the presenter can control.

", "time": "2024-03-17T23:39:16Z"}, {"author": "Jim Fenton", "text": "

Yes, lotsa slides but they assured me they did a dry run and it ran on time

", "time": "2024-03-17T23:39:29Z"}, {"author": "Bron Gondwana", "text": "

I can't even keep track of things when it's showing me so little on each slide

", "time": "2024-03-17T23:39:38Z"}, {"author": "Carsten Bormann", "text": "

(takahashi)

", "time": "2024-03-17T23:39:44Z"}, {"author": "Andrew Campling", "text": "

+1 to Pete Resnick, anything above say 5 slides is probably too many for a dispatch question

", "time": "2024-03-17T23:39:48Z"}, {"author": "Rich Salz", "text": "

One sentence per slide is JUST PLAIN WRONG for ietf presentations

", "time": "2024-03-17T23:39:50Z"}, {"author": "Martin Thomson", "text": "

The bad thing with this form of elision is that the signatures are linkable.

", "time": "2024-03-17T23:39:58Z"}, {"author": "Stephen Farrell", "text": "

40% of this presentation is someone saying \"next slide\" :-)

", "time": "2024-03-17T23:40:07Z"}, {"author": "Carsten Bormann", "text": "

I'm not saying these are good slides, just the the number 41 is not a problem per se

", "time": "2024-03-17T23:40:07Z"}, {"author": "Bron Gondwana", "text": "

the nice thing about lots of slides is you can elide data from individual slides and show it as you page forward

", "time": "2024-03-17T23:40:19Z"}, {"author": "Eric Rescorla", "text": "

@MT: they do have something about salting, but what we want is a commitment

", "time": "2024-03-17T23:40:32Z"}, {"author": "Pete Resnick", "text": "

@Carsten Bormann Fair enough

", "time": "2024-03-17T23:40:36Z"}, {"author": "Bron Gondwana", "text": "

but it has a pretty tree

", "time": "2024-03-17T23:40:50Z"}, {"author": "Henk Birkholz", "text": "

It could have been 42

", "time": "2024-03-17T23:40:54Z"}, {"author": "Tobias Fiebig", "text": "

Martin D\u00fcrst said:

\n
\n

Is there a mailing list for mailmaint now? I didn't find anything on https://www.ietf.org/mailman/listinfo/ that i thought was matching.

\n
\n

i think it's mailman

", "time": "2024-03-17T23:40:57Z"}, {"author": "Rich Salz", "text": "

No, 41 slides for allldispatch that everyone attends is bad.

", "time": "2024-03-17T23:41:00Z"}, {"author": "Martin Thomson", "text": "

@Ekr I'm concerned about the issuer being able to link issuance with redemption

", "time": "2024-03-17T23:41:01Z"}, {"author": "David Weekly", "text": "

Neal Krawetz said:

\n
\n

For wrong recipient: How do you prevent someone from using this to scan for email addresses on the server?

\n
\n

Because per the spec the sender includes hard-to-forge components of the URL (such as just using a UUID or signing the other parameters), which makes it difficult for an attackers to submit a valid wrong recipient POST, even with a valid email address.

", "time": "2024-03-17T23:41:05Z"}, {"author": "Tim Bray", "text": "

this guy was from something blockchain something. Does this rely on that?

", "time": "2024-03-17T23:41:07Z"}, {"author": "Michael Prorock", "text": "

why isn't this just two slides:
\nhttps://datatracker.ietf.org/doc/draft-ietf-cose-merkle-tree-proofs/04/ exists

\n

we think it should be extended in XYZ way - if that is what they are saying

\n

but if they are saying this, why isn't this just an email on the cose list?

", "time": "2024-03-17T23:41:15Z"}, {"author": "Tobias Fiebig", "text": "

https://www.ietf.org/mailman/listinfo/mailman

", "time": "2024-03-17T23:41:19Z"}, {"author": "Shuping Peng", "text": "

@Andrew, Pete, yes, it would be a good idea to have a limited number of slides as a requirement to present in a dispatch session.

", "time": "2024-03-17T23:41:20Z"}, {"author": "Carsten Bormann", "text": "

(I have 5)

", "time": "2024-03-17T23:41:37Z"}, {"author": "Shiva Raj", "text": "

41-42 ?? next slides!!!

", "time": "2024-03-17T23:41:42Z"}, {"author": "Jonathan Hoyland", "text": "

Non-dispatch question, how do I know that the data has been deleted?

", "time": "2024-03-17T23:41:54Z"}, {"author": "Eric Rescorla", "text": "

The reason these RFCs were ignored is that they're not IETF RFCs!

", "time": "2024-03-17T23:42:07Z"}, {"author": "Jonathan Hoyland", "text": "

I can simulate deletion without deleting it

", "time": "2024-03-17T23:42:13Z"}, {"author": "David Lawrence", "text": "

If the alldispatch experiment continues in the future (and so far I think it should) definitely need to get presenters focused on \"is this problem something to work on and where do we dispatch it\"

", "time": "2024-03-17T23:42:14Z"}, {"author": "Carsten Bormann", "text": "

That is the difference between security and privacy

", "time": "2024-03-17T23:42:17Z"}, {"author": "Martin Thomson", "text": "

don't say \"we feel like these RFCs have been ignored\".

", "time": "2024-03-17T23:42:22Z"}, {"author": "Bron Gondwana", "text": "

RESPECT THE CORE VALUES

", "time": "2024-03-17T23:42:22Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan they deleted it, after copying it somewhere else. don't worry!

", "time": "2024-03-17T23:42:26Z"}, {"author": "Jim Fenton", "text": "

my slide advance finger is getting tired :)

", "time": "2024-03-17T23:42:34Z"}, {"author": "Spencer Dawkins", "text": "

(during HotRFC last night) Neal Krawetz
\nsaid:

\n

The 4-minute clock is scary and awesome. Reminds me of Scalzi's book, \"Starter Villain\", where the bad presenters got launched into a lake.

", "time": "2024-03-17T23:42:34Z"}, {"author": "Alissa Cooper", "text": "

might be good to present some evidence of these docs being ignored

", "time": "2024-03-17T23:42:41Z"}, {"author": "Martin Thomson", "text": "

Alissa++

", "time": "2024-03-17T23:42:49Z"}, {"author": "Eric Rescorla", "text": "

Well the HRPC one is definitely ignored!

", "time": "2024-03-17T23:42:58Z"}, {"author": "Richard Barnes", "text": "

or some evidence that someone wants to use any of this stuff

", "time": "2024-03-17T23:43:05Z"}, {"author": "Mark Nottingham", "text": "

I'm still not seeing what he means by the whole \"middle ground\" thing

", "time": "2024-03-17T23:43:08Z"}, {"author": "Pete Resnick", "text": "

I'm inclined to dispatch this to the IAB.

", "time": "2024-03-17T23:43:09Z"}, {"author": "Spencer Dawkins", "text": "

It might be good to consider time limits, rather than slide limits

", "time": "2024-03-17T23:43:12Z"}, {"author": "Martin Thomson", "text": "

I mean, if you ignore something, do not assume that others have

", "time": "2024-03-17T23:43:17Z"}, {"author": "Mark Nottingham", "text": "

Spencer ++

", "time": "2024-03-17T23:43:24Z"}, {"author": "Tommy Jensen", "text": "

of all the slides, what I missed having is a concrete example of where a specific protocol usage was improved by adding support for this

", "time": "2024-03-17T23:43:36Z"}, {"author": "Eric Rescorla", "text": "

@Tommy: precisely

", "time": "2024-03-17T23:43:44Z"}, {"author": "Daniel Gillmor", "text": "

+1 @Tommy

", "time": "2024-03-17T23:43:47Z"}, {"author": "Richard Barnes", "text": "

@Tommy +1

", "time": "2024-03-17T23:43:49Z"}, {"author": "Shiva Raj", "text": "

IoTF?

", "time": "2024-03-17T23:44:01Z"}, {"author": "Pete Resnick", "text": "

IRTF is OK. But not IETF.

", "time": "2024-03-17T23:44:23Z"}, {"author": "Orie Steele", "text": "

COSE WG adopted draft on merkle proofs author here, this is doing similar things, but at the CBOR layer (not COSE layer), see the related code points consumed in https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

", "time": "2024-03-17T23:44:30Z"}, {"author": "Christopher Allen", "text": "

@Mark Nottingham There are a lot of heavier cryptographic ways to do some of this, but given 80/20, hashed elision is realistic.

", "time": "2024-03-17T23:44:33Z"}, {"author": "John Gray", "text": "

Lots of pretty slides, that would have been a lot of work to put together! I think a slide template for All Dispatch with the main questions could be helpful to streamline the process.

", "time": "2024-03-17T23:44:35Z"}, {"author": "Martin D\u00fcrst", "text": "

@TobiasFiebing: mailman@ietf.org sounds right, but it's the mailing list to contact if there are problems with the \"mailman\" mailing list software.

", "time": "2024-03-17T23:44:47Z"}, {"author": "Daniel Gillmor", "text": "

@Durst, it will probably be mailmaint@ or something, not mailman@

", "time": "2024-03-17T23:45:26Z"}, {"author": "Martin Thomson", "text": "

SD-JWT, SD-CWT exist, what does this do that those do not?

", "time": "2024-03-17T23:45:30Z"}, {"author": "Spencer Dawkins", "text": "

Well, Colin Perkins IS in Zulip ...

", "time": "2024-03-17T23:45:35Z"}, {"author": "Brian Campbell", "text": "

ISO mdoc is a cose/cbor salted hash based data elision approach and a SD-CWT is a different cose/cbor salted hash based data elision approach being proposed in/for SPICE, which is arguably already more approaches than is ideal. Is another differs one needed?

", "time": "2024-03-17T23:45:58Z"}, {"author": "Orie Steele", "text": "

@martin its basically CBOR specific and more merkle tree based... but its also doing lots more than just selective disclosure

", "time": "2024-03-17T23:46:12Z"}, {"author": "Eric Rescorla", "text": "

FWIW, I do think that this kind of hash commitment is a useful building block

", "time": "2024-03-17T23:46:40Z"}, {"author": "Christopher Allen", "text": "

We were told at last DISPATCH that it we need a problem statement

", "time": "2024-03-17T23:46:43Z"}, {"author": "Martin Thomson", "text": "

@Orie, I'm asking about what capabilities does it have that justify a new thing.

", "time": "2024-03-17T23:46:52Z"}, {"author": "Eric Rescorla", "text": "

But the place to start is \"what IETF protocol specifications need this building block\"

", "time": "2024-03-17T23:47:04Z"}, {"author": "Mark Nottingham", "text": "

+1 David

", "time": "2024-03-17T23:47:09Z"}, {"author": "Michael Prorock", "text": "

+1 David

", "time": "2024-03-17T23:47:16Z"}, {"author": "Orie Steele", "text": "

my view is, you can do this with COSE or COSE drafts today... nothing new, aside from the layer at which things are being done.

", "time": "2024-03-17T23:47:32Z"}, {"author": "Orie Steele", "text": "

+1 David

", "time": "2024-03-17T23:47:47Z"}, {"author": "Tobias Fiebig", "text": "

Martin D\u00fcrst said:

\n
\n

@TobiasFiebing: mailman@ietf.org sounds right, but it's the mailing list to contact if there are problems with the \"mailman\" mailing list software.

\n
\n

hrm... brainfnord on my side. Indeed not finding an ML, and the zulip link on the datatracker also says 'does not exist or is private'

", "time": "2024-03-17T23:47:53Z"}, {"author": "Martin D\u00fcrst", "text": "

@Gilmor I looked for mailmaint@, but there's no such thing on https://www.ietf.org/mailman/listinfo/

", "time": "2024-03-17T23:48:06Z"}, {"author": "Eric Rescorla", "text": "

Well I think the problem statement in this cases is \"Protocol XYZ needs some kind of selective disclosure\"

", "time": "2024-03-17T23:48:18Z"}, {"author": "Daniel Gillmor", "text": "

patience, Martin -- it's being worked on

", "time": "2024-03-17T23:48:26Z"}, {"author": "Eric Rescorla", "text": "

Or rather that would be the problem statement that would motivate this work

", "time": "2024-03-17T23:48:42Z"}, {"author": "Rich Salz", "text": "

Nicely put @Eric

", "time": "2024-03-17T23:49:07Z"}, {"author": "Christopher Allen", "text": "

@Alissa Cooper So how do we improve \"best practices\" of various aspects. We only focused mostly on data minimization, but it is part a larger problem.

", "time": "2024-03-17T23:49:13Z"}, {"author": "Matt Joras", "text": "

Sorry, but isn't this kind of deja-vu of the DISPATCH outcome for this work when it was presented at IETF 117?

", "time": "2024-03-17T23:49:26Z"}, {"author": "Tobias Fiebig", "text": "

well, in that case, obviously, it should go to opsec.

", "time": "2024-03-17T23:49:48Z"}, {"author": "Christopher Allen", "text": "

So what is the process to IRTF?

", "time": "2024-03-17T23:49:53Z"}, {"author": "Eric Rescorla", "text": "

The process is you take it to Colin

", "time": "2024-03-17T23:50:04Z"}, {"author": "Francesca Palombini", "text": "

That is right, this group cannot dispatch to IRTF (nor to ISE), but it can suggest that the authors reach out to IRTF (or ISE) :)

", "time": "2024-03-17T23:50:34Z"}, {"author": "David Schinazi", "text": "

Or to the mailing list of the relevant research group

", "time": "2024-03-17T23:50:39Z"}, {"author": "Bron Gondwana", "text": "

This is maybe a good proof for the \"people don't look at the stream or information status of things with the RFC number stamp on them\" problem

", "time": "2024-03-17T23:51:16Z"}, {"author": "Pete Resnick", "text": "

Yeah, what Colin means is that we can't \"make it happen\" outside of the IETF; we can recommend that you take it elsewhere, but we can't force them to take it.

", "time": "2024-03-17T23:51:28Z"}, {"author": "Orie Steele", "text": "

I suggest separating these layers, so that the components might fit better into existing WGs

", "time": "2024-03-17T23:51:31Z"}, {"author": "Alissa Cooper", "text": "

There have been a few options discussed around updating RFC 6973 -- going through the IAB (where 6973 came from), or doing some kind of joint update with RFC 3552 or other SEC area documents, which would go through the SEC area.

", "time": "2024-03-17T23:51:31Z"}, {"author": "Orie Steele", "text": "

+1 to the speaker

", "time": "2024-03-17T23:51:34Z"}, {"author": "Stephen Farrell", "text": "

if the authors wanted their current solution to be standardised then the IRTF is not the right venue

", "time": "2024-03-17T23:51:37Z"}, {"author": "Daniel Gillmor", "text": "

Bron, we need more proof of that?

", "time": "2024-03-17T23:51:39Z"}, {"author": "Stephen Farrell", "text": "

sounds more like goto ISE to me

", "time": "2024-03-17T23:52:15Z"}, {"author": "Henk Birkholz", "text": "

Please advise what these pieces should be

", "time": "2024-03-17T23:52:25Z"}, {"author": "Andrew Campling", "text": "

Also, use many less slides if you re-visit dispatch!

", "time": "2024-03-17T23:52:30Z"}, {"author": "Martin Thomson", "text": "

please do not take something like this to ISE

", "time": "2024-03-17T23:52:35Z"}, {"author": "Eric Rescorla", "text": "

82 slides!

", "time": "2024-03-17T23:52:37Z"}, {"author": "Henk Birkholz", "text": "

-1 ise

", "time": "2024-03-17T23:52:45Z"}, {"author": "Eric Rescorla", "text": "

Why would it be good for the ISE to publish this?

", "time": "2024-03-17T23:52:50Z"}, {"author": "Bron Gondwana", "text": "

dkg; we get people saying \"it's not really a problem\" sometimes

", "time": "2024-03-17T23:52:59Z"}, {"author": "Carsten Bormann", "text": "

The subject of elision as a stand-in if on-topic for CBOR. Crypto around that, COSE. The grander vision, don't know.

", "time": "2024-03-17T23:53:05Z"}, {"author": "Martin Thomson", "text": "

The point is to work on improving clarity, not package and publish artifacts that embody lack of clarity.

", "time": "2024-03-17T23:53:27Z"}, {"author": "Eric Rescorla", "text": "

Just move to the right

", "time": "2024-03-17T23:54:00Z"}, {"author": "Henk Birkholz", "text": "

Alive on which are the blocks on how to make them crisp and clear then

", "time": "2024-03-17T23:54:16Z"}, {"author": "Deb Cooley", "text": "

one side gets wifi, the other gets slides

", "time": "2024-03-17T23:54:23Z"}, {"author": "Orie Steele", "text": "

^ perfectly balanced like all things should be

", "time": "2024-03-17T23:54:37Z"}, {"author": "Tobias Fiebig", "text": "

the flash from the pictures is rather... intense.

", "time": "2024-03-17T23:54:45Z"}, {"author": "Robert Moskowitz", "text": "

Snow in Michigan right now. ARGH!!! It is accumulating. I knew I should have attended in person. :)

", "time": "2024-03-17T23:54:45Z"}, {"author": "Tommy Jensen", "text": "

Go team Wi-Fi

", "time": "2024-03-17T23:54:45Z"}, {"author": "Martin Thomson", "text": "

no, one side gets wifi and slides, the other gets

", "time": "2024-03-17T23:54:46Z"}, {"author": "Michael Prorock", "text": "

so sort of like startup pitch decks, we should recommend going and looking at successful dispatch decks as a model

", "time": "2024-03-17T23:54:47Z"}, {"author": "Andrew Campling", "text": "

Slides at https://datatracker.ietf.org/meeting/119/materials/slides-119-alldispatch-7-websocket-extension-to-disable-masking-02

", "time": "2024-03-17T23:54:55Z"}, {"author": "Michael Prorock", "text": "

i like the upcoming deck from carsten

", "time": "2024-03-17T23:54:57Z"}, {"author": "Michael Richardson", "text": "

Deb Cooley said:

\n
\n

one side gets wifi, the other gets slides

\n
\n

Slides and Wifi are Conjugate Variables, and are subject to Heisenburg limit.

", "time": "2024-03-17T23:55:06Z"}, {"author": "Deb Cooley", "text": "

@MT: mea culpa, hard to keep up with who gets what.

", "time": "2024-03-17T23:55:55Z"}, {"author": "Martin Thomson", "text": "

I'm surprised that the authors of the paper didn't know to use 192.0.2.x

", "time": "2024-03-17T23:55:56Z"}, {"author": "Pete Resnick", "text": "

Is there a reason this shouldn't go to WEBTRANS?

", "time": "2024-03-17T23:55:57Z"}, {"author": "Eric Rescorla", "text": "

It's not the server behind the proxies.

", "time": "2024-03-17T23:55:59Z"}, {"author": "Eric Rescorla", "text": "

It's the client which is behind the proxy!

", "time": "2024-03-17T23:56:13Z"}, {"author": "Martin Thomson", "text": "

webtrans does not maintain websockets

", "time": "2024-03-17T23:56:15Z"}, {"author": "Bron Gondwana", "text": "

3.3.3.3

", "time": "2024-03-17T23:56:26Z"}, {"author": "Daniel Gillmor", "text": "

256.256.256.256

", "time": "2024-03-17T23:56:41Z"}, {"author": "Eric Rescorla", "text": "

I know people love 192.0.2.x but it's harder to read in papers

", "time": "2024-03-17T23:56:43Z"}, {"author": "Christopher Allen", "text": "

@Martin Thomson Re: elision - signatures don't have to be linkable. There are technologies for that (like BBS). But remember, not all data at rest is signed, but data at rest is correlatable. We don't have BBS in our spec, but you can sign with BBS signatures if you want anti-correlation of signatures.

", "time": "2024-03-17T23:56:49Z"}, {"author": "Christopher Hawker", "text": "

8.8.8.8 ;)

", "time": "2024-03-17T23:56:52Z"}, {"author": "Bron Gondwana", "text": "

192.0.555.12

", "time": "2024-03-17T23:56:53Z"}, {"author": "Eric Rescorla", "text": "

I am pretty sure I didn't do this diagram, though

", "time": "2024-03-17T23:56:54Z"}, {"author": "Jonathan Lennox", "text": "

There are lots of seats in the center-right block where the slides should be easily visible

", "time": "2024-03-17T23:57:06Z"}, {"author": "Bron Gondwana", "text": "

you can tell it's a movie IP address if it has 555 in it

", "time": "2024-03-17T23:57:07Z"}, {"author": "Martin Thomson", "text": "

127.0.0.3

", "time": "2024-03-17T23:57:13Z"}, {"author": "Murray Kucherawy", "text": "

@Martin Durst:
\nhttps://datatracker.ietf.org/wg/mailmaint/about/

", "time": "2024-03-17T23:57:13Z"}, {"author": "Murray Kucherawy", "text": "

(and whoever else wanted to know about it)

", "time": "2024-03-17T23:57:25Z"}, {"author": "Martin D\u00fcrst", "text": "

Thanks, Murray!

", "time": "2024-03-17T23:57:35Z"}, {"author": "Christopher Allen", "text": "

@Tim Bray Re: Blockchain question. There is no blockchain in Gordian Envelope. It is hash tree of hash trees.

", "time": "2024-03-17T23:57:37Z"}, {"author": "Murray Kucherawy", "text": "

yessir

", "time": "2024-03-17T23:57:43Z"}, {"author": "Pete Resnick", "text": "

https://datatracker.ietf.org/group/chartering/

", "time": "2024-03-17T23:58:19Z"}, {"author": "Christopher Allen", "text": "

ALL: We didn't know we would not be able to \"next slide\" ourselves. This is a presentation tech problem, not a presenter problem.

", "time": "2024-03-17T23:58:38Z"}, {"author": "David Lawrence", "text": "

It's kind of both

", "time": "2024-03-17T23:59:18Z"}, {"author": "Eric Rescorla", "text": "

but here's the thing: the attacker controls the port number

", "time": "2024-03-17T23:59:27Z"}, {"author": "Christian Huitema", "text": "

Is there anything here but a bug report to the concerned proxies?

", "time": "2024-03-17T23:59:51Z"}, {"author": "Ted Hardie", "text": "

Will this deprecate the previous behavior or enable unmasked as well?

", "time": "2024-03-17T23:59:51Z"}, {"author": "Martin Thomson", "text": "

it's not just about unsecured HTTP, but unsecured anything

", "time": "2024-03-18T00:00:00Z"}, {"author": "Martin Thomson", "text": "

My big concern here is the cost of disabling is not in disabling, but the negotiation part.

", "time": "2024-03-18T00:00:20Z"}, {"author": "Eric Rescorla", "text": "

I mean as a practical matter, it has to be negotiated

", "time": "2024-03-18T00:00:22Z"}, {"author": "Rich Salz", "text": "

@Christopher Allen: No, it's a who-made-the-slides problem. If your deck needs chapter headings, then you're doing it wrong.

", "time": "2024-03-18T00:00:23Z"}, {"author": "Eric Rescorla", "text": "

@MT: yes.

", "time": "2024-03-18T00:00:28Z"}, {"author": "Tommy Jensen", "text": "

@ted as pictured now, this is flexibility for opting out, existing usage can continue

", "time": "2024-03-18T00:00:35Z"}, {"author": "Martin Thomson", "text": "

That drives up complexity, but the performance hit is likely trivial.

", "time": "2024-03-18T00:00:44Z"}, {"author": "Ted Hardie", "text": "

Thanks @Tommy.

", "time": "2024-03-18T00:00:56Z"}, {"author": "Martin D\u00fcrst", "text": "

@Resnick, @Kucherawy: Thanks for the info. My original question was about a mailing list. It looks like there isn't one yet. I hope that gets addressed in due time; a mail-related WG without a mailing list would be strange :-).

", "time": "2024-03-18T00:01:00Z"}, {"author": "Martin Thomson", "text": "

So epsilon performance gain for a measurable complexity hit. What value does epsilon take?

", "time": "2024-03-18T00:01:10Z"}, {"author": "Tommy Jensen", "text": "

@MT more than you might think at scale

", "time": "2024-03-18T00:01:29Z"}, {"author": "Eric Rescorla", "text": "

I mean, compared to the encryption?

", "time": "2024-03-18T00:01:36Z"}, {"author": "Daniel Gillmor", "text": "

@Durst, i think the mailing list will come soon

", "time": "2024-03-18T00:01:47Z"}, {"author": "Jonathan Lennox", "text": "

Is the relevant overhead the XOR or the four bytes?

", "time": "2024-03-18T00:01:56Z"}, {"author": "Daniel Gillmor", "text": "

+1 MT

", "time": "2024-03-18T00:02:02Z"}, {"author": "Murray Kucherawy", "text": "

@Martin Durst: Nope, I'll be getting one created this week. I don't think I want to reclaim the older 822 or SMTP lists for this.

", "time": "2024-03-18T00:02:18Z"}, {"author": "Rohan Mahy", "text": "

Carsten Bormann said:

\n
\n

41 takahasi slides is no problem, if the presenter can control.

\n
\n

This neglects the long latency we often experience seeing the slides update on the meeting tool. 5 or 10 slides max for a dispatch question is a reasonable restriction.

", "time": "2024-03-18T00:02:22Z"}, {"author": "Christian Huitema", "text": "

Wow, poisoning privacy-breaking MITM proxies. That seems sad.

", "time": "2024-03-18T00:02:41Z"}, {"author": "Murray Kucherawy", "text": "

@Martin Durst: I'm just waiting a bit to be sure we've settled on a name. :)

", "time": "2024-03-18T00:02:42Z"}, {"author": "Richard Barnes", "text": "

@Christian think of the poor enterprises!

", "time": "2024-03-18T00:03:02Z"}, {"author": "Tommy Jensen", "text": "

@jonathan XOR but with the added requirement that now the payload has to be pulled into code paths / components that could be otherwise skipped with hard coded pass along

", "time": "2024-03-18T00:03:06Z"}, {"author": "Martin D\u00fcrst", "text": "

@Kucherawy: Many thanks for the explanations, all clear!

", "time": "2024-03-18T00:03:12Z"}, {"author": "David Lawrence", "text": "

Personally I think 41 slides is a problem from what we're trying to focus on, and being able to review slides as well.

", "time": "2024-03-18T00:03:14Z"}, {"author": "Christian Huitema", "text": "

@Richard and the children?

", "time": "2024-03-18T00:03:26Z"}, {"author": "Richard Barnes", "text": "

@Christian true, schools are also enthusiastic about breaking TLS

", "time": "2024-03-18T00:03:46Z"}, {"author": "Richard Barnes", "text": "

41 slides is too many, full stop

", "time": "2024-03-18T00:03:59Z"}, {"author": "Jonathan Hoyland", "text": "

41 slides is appropriate for a 90 minute talk.

", "time": "2024-03-18T00:04:32Z"}, {"author": "Daniel Gillmor", "text": "

15 minute talk

", "time": "2024-03-18T00:04:44Z"}, {"author": "Ira McDonald", "text": "

BTW - remote video of the meeting room is entirely useless due to the backlighting - faces are invisible

", "time": "2024-03-18T00:04:44Z"}, {"author": "Richard Barnes", "text": "

@Ira privacy feature

", "time": "2024-03-18T00:05:00Z"}, {"author": "Mark Nottingham", "text": "

@Christian Huitema it certainly keeps me up at night.

", "time": "2024-03-18T00:05:16Z"}, {"author": "David Lawrence", "text": "

Our faces aren't worth viewing anyway.

", "time": "2024-03-18T00:05:19Z"}, {"author": "Michael Prorock", "text": "

backlighting is a privacy and human rights feature

", "time": "2024-03-18T00:05:30Z"}, {"author": "Lorenzo Miniero", "text": "

@Ira McDonald we asked if they can close the shades for next sessions

", "time": "2024-03-18T00:05:36Z"}, {"author": "Rohan Mahy", "text": "

@Eric Rescorla it sounds like your caffeine finally kicked in.

", "time": "2024-03-18T00:05:44Z"}, {"author": "Jonathan Hoyland", "text": "

Daniel Gillmor said:

\n
\n

15 minute talk

\n
\n

A 15 minute talk by Ekr maybe :joy:

", "time": "2024-03-18T00:05:51Z"}, {"author": "Tommy Jensen", "text": "

@ekr sure, but where should this go once you buy the premise? otherwise we get to have this conversation again in Vancouver

", "time": "2024-03-18T00:05:58Z"}, {"author": "Eric Rescorla", "text": "

@Rohan: you are in fact correct

", "time": "2024-03-18T00:06:00Z"}, {"author": "Robert Moskowitz", "text": "

It would be nice to see who is at the mic

", "time": "2024-03-18T00:06:01Z"}, {"author": "A.J. Stein", "text": "

I was worried up until the current comments that Schinazi gave up X or Y enthusiast per tradition, good to see we keep the fun alive.

", "time": "2024-03-18T00:06:33Z"}, {"author": "Pete Resnick", "text": "

I have become uninterested in what @David Schinazi is enthusiastic about. I am now more interested in things about which he is unenthusiastic.

", "time": "2024-03-18T00:07:05Z"}, {"author": "Eric Rescorla", "text": "

I honestly have no idea if the middleboxes are still a problem. but we should find out!

", "time": "2024-03-18T00:07:07Z"}, {"author": "Christian Huitema", "text": "

Masking seems like a half-way measure. If we really are worried about MITM, then we should develop something like MLS for HTTP.

", "time": "2024-03-18T00:07:31Z"}, {"author": "Martin Thomson", "text": "

it is quite likely that finding middleboxes that are vulnerable would be hard

", "time": "2024-03-18T00:07:37Z"}, {"author": "Shiva Raj", "text": "

Masking-> middleboxes!

", "time": "2024-03-18T00:07:51Z"}, {"author": "Martin Thomson", "text": "

if that is the case, that answers half the question, but not the other half (the marginal gain)

", "time": "2024-03-18T00:08:04Z"}, {"author": "Mark Nottingham", "text": "

I'm pretty sure that a good number of them are tucked away on networks in various corners of Australia

", "time": "2024-03-18T00:08:05Z"}, {"author": "Eric Rescorla", "text": "

The purpose of masking (not MASQUEing) was to deal with the existing proxies, not to prevent proxies who knew abuot WS from doing stuff

", "time": "2024-03-18T00:08:10Z"}, {"author": "Daniel Gillmor", "text": "

+1 for needing more motivation to justify the negotiation complexity

", "time": "2024-03-18T00:08:34Z"}, {"author": "Eric Rescorla", "text": "

So think about masking as kind of like the TLS 1.3 changecipherspec hack

", "time": "2024-03-18T00:08:38Z"}, {"author": "Christian Huitema", "text": "

I see this evolving into some equivalent of ECH at the websocket level...

", "time": "2024-03-18T00:09:00Z"}, {"author": "Martin Thomson", "text": "

I'm not aware of any interest in removing the CCS hack from their deployments, even though we have a switch, it's not worth the effort to work out if flipping the switch is safe.

", "time": "2024-03-18T00:09:27Z"}, {"author": "Daniel Gillmor", "text": "

the weekly cycles on the DDoS rates were super surprising to me. DDoS is more common during weekdays?

", "time": "2024-03-18T00:09:34Z"}, {"author": "Eric Rescorla", "text": "

@DKG: maybe attackers don't want to pay their bots overtime?

", "time": "2024-03-18T00:09:53Z"}, {"author": "Tim Bray", "text": "

wow those numbers

", "time": "2024-03-18T00:10:16Z"}, {"author": "Martin Thomson", "text": "

being a bad guy is a day job

", "time": "2024-03-18T00:10:20Z"}, {"author": "Tommy Jensen", "text": "

Not surprising, if services already have more load during weekdays, lowers the bar for DDoS success assuming poor scale reactivity of the service

", "time": "2024-03-18T00:10:52Z"}, {"author": "Jonathan Hoyland", "text": "

Daniel Gillmor said:

\n
\n

the weekly cycles on the DDoS rates were super surprising to me. DDoS is more common during weekdays?

\n
\n

You can sometimes see the working hours of attackers based on their DDoS traffic. It's often 9-5 in a specific timezone, and they sometimes take breaks for national holidays.

", "time": "2024-03-18T00:10:55Z"}, {"author": "Pete Resnick", "text": "

@Daniel Gillmor The entire weekend, or just the Sabbath? Maybe they are observant bots?

", "time": "2024-03-18T00:11:18Z"}, {"author": "Michael Prorock", "text": "

i welcome our new agent overlords - 24/7 now brought to you by LLMs

", "time": "2024-03-18T00:11:33Z"}, {"author": "Daniel Gillmor", "text": "

interesting, thanks for the background. clearly i should shop my resume around, i'm working on sunday evening right now!

", "time": "2024-03-18T00:11:47Z"}, {"author": "Jonathan Hoyland", "text": "

(To be clear, I don't mean one specific timezone in general, just a single timezone for a specific attack.)

", "time": "2024-03-18T00:11:55Z"}, {"author": "Rich Salz", "text": "

DDoS happens more during the week because they generally attacking businesses which are doing less on weekend. IMO

", "time": "2024-03-18T00:12:15Z"}, {"author": "Jonathan Hoyland", "text": "

Rich Salz said:

\n
\n

DDoS happens more during the week because they generally attacking businesses which are doing less on weekend. IMO

\n
\n

It's not something I've really looked into, but I would have guessed DDoS targets are mostly things that are consumer facing, and thus would get more business / traffic on the weekend.

", "time": "2024-03-18T00:13:37Z"}, {"author": "Lucas Pardue", "text": "

In Germany, the law means there can be no slow lorry attacks on Sundays

", "time": "2024-03-18T00:13:51Z"}, {"author": "A.J. Stein", "text": "

I have had this discussed in professional and academic circles frequently for a long time now, is there really not deep research on the timing concurrent with attackers' timezone theory? I guess I have to go look.

", "time": "2024-03-18T00:14:07Z"}, {"author": "Rich Salz", "text": "

DKG: Or you could move to where the IETF is being held. \"Join the IETF, see the world.\" Moving every 120 days seems reasonable.

", "time": "2024-03-18T00:14:27Z"}, {"author": "Pete Resnick", "text": "

Not an expert on YANGy things, but this sounds like a non-controversial WG in O&M, no?

", "time": "2024-03-18T00:15:34Z"}, {"author": "Jonathan Hoyland", "text": "

I wonder how far in advance of the IETF the ground team arrive?

", "time": "2024-03-18T00:15:49Z"}, {"author": "Tom Strickx", "text": "

1 week afaik

", "time": "2024-03-18T00:16:24Z"}, {"author": "Ted Hardie", "text": "

This does not sound like a dispatch question response.

", "time": "2024-03-18T00:16:31Z"}, {"author": "Daniel Gillmor", "text": "

it is at least in part an answer: he was saying \"please do this within the IETF\"

", "time": "2024-03-18T00:18:03Z"}, {"author": "John Klensin", "text": "

@Murray, first time I'm hearing about this new group. I'll try to study the charter later, but a question: EMAILCORE, which is a \"mail maintenance\" project in its own right, is, at least IMO, in trouble. Far behind schedule, bogged down about details in 5321bis, and with a major effort ahead on the A/S. Are you confident that this new group will not pull interested people and other resources away from EMAILCORE, with the effect of either bogging it down further, further reducing the range of perspectives and experience represented, or both?

", "time": "2024-03-18T00:18:20Z"}, {"author": "Mark Nottingham", "text": "

The hard problems here are in the trust relationships between the parties. It's easier for enterprise networks talking to their network providers; it's much harder for eg VPN providers to trust signals from various third parties.

", "time": "2024-03-18T00:18:34Z"}, {"author": "Daniel Gillmor", "text": "

@Mark -- i was wondering the same thing. how do i know who to talk to: how do they know whether to trust me when i ask for a mitigation?

", "time": "2024-03-18T00:19:05Z"}, {"author": "Pete Resnick", "text": "

@John Klensin Read the charter. Different kind of thing.

", "time": "2024-03-18T00:19:38Z"}, {"author": "Jonathan Hoyland", "text": "

Do we really want to end up with a new reputation system?

", "time": "2024-03-18T00:19:45Z"}, {"author": "Andrew Campling", "text": "

+1 to Paul Hoffman on dispatch to BoF

", "time": "2024-03-18T00:19:45Z"}, {"author": "Murray Kucherawy", "text": "

@John Klensin: I'm not concerned, in the sense that I could see them operating serially (i.e., MAILMAINT doesn't take off until EMAILCORE has landed).

\n

It's not in any advanced stage of chartering, so there's plenty of time for discussion and feedback.

", "time": "2024-03-18T00:19:56Z"}, {"author": "Mark Nottingham", "text": "

Well, the fallback is IP reputation as we know it...

", "time": "2024-03-18T00:20:17Z"}, {"author": "Murray Kucherawy", "text": "

@John Klensin: I'm also not sure the core of these two groups overlaps all that much, but I could be wrong.

", "time": "2024-03-18T00:20:27Z"}, {"author": "Martin Thomson", "text": "

Just an observation: this process won't work if we conclude that everything resolves with a BoF.

", "time": "2024-03-18T00:20:58Z"}, {"author": "A.J. Stein", "text": "

@Daniel Gillmor I think that is a good question and I feel a lot of people, despite a valid need for work like this, are not comfortable sharing such important security data without knowing sender and receiver are part of a very limited known list of entities, and that hinders many such initiatives. I hope to be pleasantly surprised otherwise eventually, but I see a repeat them in security data.

", "time": "2024-03-18T00:21:02Z"}, {"author": "Martin D\u00fcrst", "text": "

@Kucherawy Where should that discussion/feedback go? (That's why I asked about the mailing list, because that's often a first step before chartering.)

", "time": "2024-03-18T00:21:18Z"}, {"author": "Richard Barnes", "text": "

\"Unicode is good\" -- :hot_pepper:\ufe0f take there

", "time": "2024-03-18T00:21:57Z"}, {"author": "John Klensin", "text": "

@Murray. If you queue them that way, I have no problem. But, unless I'm reading the progress and engagement in EMAILCORE incorrectly, that means MAILMAINT does not get started for at least many months, probably a year. And that is a different sort of answer to Martin's question.

", "time": "2024-03-18T00:22:21Z"}, {"author": "Daniel Gillmor", "text": "

does this mean reopening PRECIS?

", "time": "2024-03-18T00:22:42Z"}, {"author": "Murray Kucherawy", "text": "

@Martin Durst: To the list I will create later this week when I know the name is stable.

", "time": "2024-03-18T00:23:02Z"}, {"author": "Orie Steele", "text": "

good question DKG... I think it depends on how this work is related to that work.

", "time": "2024-03-18T00:23:26Z"}, {"author": "Martin Thomson", "text": "

again: this detail is not helping us answer the dispatch question

", "time": "2024-03-18T00:23:54Z"}, {"author": "Eric Rescorla", "text": "

@Chairs: agree with MT

", "time": "2024-03-18T00:24:13Z"}, {"author": "Pete Resnick", "text": "

@Daniel Gillmor My comment at the mic is that this should just be done as a PRECIS profile registration and not as a separate doc.

", "time": "2024-03-18T00:24:32Z"}, {"author": "Eric Rescorla", "text": "

We could get this down to like 90 minutes if we triaged the slides

", "time": "2024-03-18T00:24:36Z"}, {"author": "Jonathan Hoyland", "text": "

Martin Thomson said:

\n
\n

again: this detail is not helping us answer the dispatch question

\n
\n

But is interesting nonetheless :grinning:

", "time": "2024-03-18T00:24:57Z"}, {"author": "Tommy Jensen", "text": "

or dispatch 2x the ideas

", "time": "2024-03-18T00:25:05Z"}, {"author": "Martin Thomson", "text": "

Well, maybe. None of the items so far have been particularly difficult to dispatch. We do occasionally need more time to discuss what to do with work.

", "time": "2024-03-18T00:25:19Z"}, {"author": "Rich Salz", "text": "

Martin Thomson said:

\n
\n

Just an observation: this process won't work if we conclude that everything resolves with a BoF.

\n
\n

Not so sure about that. We have also dispatched to \"go away\" And if it were obvious which WG, then folks would just go there.

", "time": "2024-03-18T00:25:38Z"}, {"author": "Mark McFadden", "text": "

Feedback on ALLDISPATCH: I don\u2019t think we would need such a big slot on the agenda if the presenters were told to only provide information related to answer the dispatch question(s). Part of this would be to provide a concrete list of questions the presenter needs to answer and a minimum of background information.

", "time": "2024-03-18T00:25:54Z"}, {"author": "Martin Thomson", "text": "

@Jonathan we could have saved the millions spent on this session if you were to instead read the draft

", "time": "2024-03-18T00:25:56Z"}, {"author": "John Klensin", "text": "

@Daniel: several of us have been discussing that for mostly separate reasons.
\n@Pete: That would certainly be my instinct. And I had hoped that both this presentation and the next one would start with \"why not use, or, if necessary, adapt, PRECIS\"? Have not heard an answer to that yet, despite all of the details.

", "time": "2024-03-18T00:26:23Z"}, {"author": "Andrew Campling", "text": "

@MT We also tried to dispatch to the IRTF

", "time": "2024-03-18T00:26:28Z"}, {"author": "Jonathan Hoyland", "text": "

Martin Thomson said:

\n
\n

@Jonathan we could have saved the millions spent on this session if you were to instead read the draft

\n
\n

Fair, Cost of Meeting is a terrifying metric.

", "time": "2024-03-18T00:26:30Z"}, {"author": "Pete Resnick", "text": "

@John Klensin Always happy to tag team with you at the mic

", "time": "2024-03-18T00:27:02Z"}, {"author": "Tony Li", "text": "

This meeting costs about $30,000 USD per hour.

", "time": "2024-03-18T00:27:37Z"}, {"author": "Tommy Jensen", "text": "

@Tony, + hard to measure opportunity cost of reducing other WG conflicts if we could squeeze one more session slot

", "time": "2024-03-18T00:28:17Z"}, {"author": "Carsten Bormann", "text": "

The term \"problematic character\" is terrible. Aprt from the toxic waste that surrogates are (not even characters), whether a character is problematic depends on your application.

", "time": "2024-03-18T00:28:37Z"}, {"author": "Eric Rescorla", "text": "

Or the cost of slee

", "time": "2024-03-18T00:28:39Z"}, {"author": "Carsten Bormann", "text": "

HT and CR are proudly supported by XML, but highy problematic in many applications.

", "time": "2024-03-18T00:29:32Z"}, {"author": "Jonathan Hoyland", "text": "

Carsten Bormann said:

\n
\n

The term \"problematic character\" is terrible. Aprt from the toxic waste that surrogates are (not even characters), whether a character is problematic depends on your application.

\n
\n

People often say the Right-to-Left character is problematic, but honestly it depends on your perspective :drum:

", "time": "2024-03-18T00:29:40Z"}, {"author": "Carsten Bormann", "text": "

Whether a control character is problematic is whther you have defined it!

", "time": "2024-03-18T00:29:54Z"}, {"author": "Spencer Dawkins", "text": "

This isn't just about the IETF 119 session, but at least some of proposals for new work have been about a collection of problems, and it's complicated to dispatch them AS A GROUP. To resolve the collection of problems, some parts may be \"use this protocol\", others may be \"extend that protocol\", still others may be \"invent a new protocol\", and one hopes there are only a few that are \"you should be arrested for suggesting such a thing\". :grinning_face_with_smiling_eyes:

", "time": "2024-03-18T00:30:02Z"}, {"author": "Orie Steele", "text": "

please address the dispatch comment in the Q

", "time": "2024-03-18T00:30:13Z"}, {"author": "Rohan Mahy", "text": "

Use of the word \"problematic\" considered harmful ;-)

", "time": "2024-03-18T00:30:25Z"}, {"author": "Daniel Gillmor", "text": "

considered problematic

", "time": "2024-03-18T00:30:37Z"}, {"author": "Orie Steele", "text": "

If it were a PRECIS profile, where would you send it?

", "time": "2024-03-18T00:31:36Z"}, {"author": "Martin Thomson", "text": "

I would just like to point people at the transcription, which is pretty impressive.

", "time": "2024-03-18T00:31:38Z"}, {"author": "Jonathan Hoyland", "text": "

So advertise PRECIS?

", "time": "2024-03-18T00:32:20Z"}, {"author": "A.J. Stein", "text": "

Right on, I am used to systems that use machine translation and these captions have always been top notch. I second @Martin Thomson's comment.

", "time": "2024-03-18T00:32:30Z"}, {"author": "Mike Bishop", "text": "

I think this transcript is live transcription, not AI-generated.

", "time": "2024-03-18T00:33:07Z"}, {"author": "Ted Hardie", "text": "

This is a human trasncriptionist, as I understand it.

", "time": "2024-03-18T00:33:08Z"}, {"author": "David Lawrence", "text": "

(Ugh chat reset. This network experience. Apologies if this is somehow repeating my send, but I don't see it.)

\n

In that case, Spencer, it seems the appropriate response is still \"dispatch it to a BoF to sort out what goes where.

", "time": "2024-03-18T00:33:13Z"}, {"author": "Jonathan Lennox", "text": "

It's not just that it's a human transcriptionist, it's a human who understands IETF terminology.

", "time": "2024-03-18T00:33:34Z"}, {"author": "Jonathan Hoyland", "text": "

Mike Bishop said:

\n
\n

I think this transcript is live transcription, not AI-generated.

\n
\n

That's even more impressive.

", "time": "2024-03-18T00:33:36Z"}, {"author": "John Klensin", "text": "

In case it is not clear, Pete and I are in complete agreement.

", "time": "2024-03-18T00:33:47Z"}, {"author": "Daniel Gillmor", "text": "

We just bypassed the PRECIS profile process in draft-ietf-lamps-header-protection, because none of them matched what we needed, and because we didn't see the overhead of spinning up a PRECIS profile worth the cost

", "time": "2024-03-18T00:34:00Z"}, {"author": "Daniel Gillmor", "text": "

we could revisit that decision but the draft is already years overdue.

", "time": "2024-03-18T00:35:09Z"}, {"author": "Ted Hardie", "text": "

Note: useful advice does not need to be standards track. So a question to the authors is why they believe they need a standards track doc? Is it for references from other IETF docs?

", "time": "2024-03-18T00:35:30Z"}, {"author": "Rich Salz", "text": "

Yes, when I hear \"problematic character\" in the IETF context, Unicode is not the right thing that comes to mind, specific individuals do.

", "time": "2024-03-18T00:36:26Z"}, {"author": "Daniel Gillmor", "text": "

only 2hrs into the IETF and we already got to \"wasteland of horrors\"

", "time": "2024-03-18T00:36:44Z"}, {"author": "Martin Thomson", "text": "

dkg: it's brisbane, after all

", "time": "2024-03-18T00:37:00Z"}, {"author": "John Klensin", "text": "

@Daniel If there is any difference between my position and Pete's (I suspect there isn't), it is that, if there is a problem with PRECIS that isn't solved by a new profile, we should be addressing and fixing PRECIS, not going off in a competing direction unless there is far more justification than I have seen so far.

", "time": "2024-03-18T00:37:06Z"}, {"author": "Tommy Jensen", "text": "

@Rich now there's a fun RFC idea

", "time": "2024-03-18T00:37:07Z"}, {"author": "Robert Moskowitz", "text": "

Lots of problematic characters in IETF workgroups. I know, I are one of many.... :)

", "time": "2024-03-18T00:37:19Z"}, {"author": "Marc Blanchet", "text": "

precis is the new version of stringprep. Stringprep has been implemented in many protocols, but people hate i18n and don't want to touch it again. And precis compared to stringprep, does not bring much for typical strings, so the cost is too much compared to the gain. This is the reason why precis is less used. Having said that, precis is much better than stringprep so anything should be done now based on precis.

", "time": "2024-03-18T00:37:29Z"}, {"author": "Michael Richardson", "text": "

Precis profiles are done via IANA activity, with Expert Review. new ones do not need a WG or RFC from what I read.

", "time": "2024-03-18T00:37:50Z"}, {"author": "Lucas Pardue", "text": "

all I see is: \u01ddu\u0250qs\u0131\u0279q

", "time": "2024-03-18T00:38:07Z"}, {"author": "Brian Carpenter", "text": "

It _is_ an IANA reg

", "time": "2024-03-18T00:38:29Z"}, {"author": "Shiva Raj", "text": "

PRECIS?

", "time": "2024-03-18T00:38:34Z"}, {"author": "Orie Steele", "text": "

Thanks Pete!

", "time": "2024-03-18T00:38:52Z"}, {"author": "Brian Carpenter", "text": "

https://www.iana.org/assignments/precis-parameters/precis-parameters.xhtml

", "time": "2024-03-18T00:38:53Z"}, {"author": "Michael Richardson", "text": "

Daniel Gillmor said:

\n
\n

We just bypassed the PRECIS profile process in draft-ietf-lamps-header-protection, because none of them matched what we needed, and because we didn't see the overhead of spinning up a PRECIS profile worth the cost

\n
\n

You don't have to spin up PRECIS to register a new profile, from what I just read.

", "time": "2024-03-18T00:39:07Z"}, {"author": "Michael Richardson", "text": "

Michael Richardson said:

\n
\n

Daniel Gillmor said:

\n
\n

We just bypassed the PRECIS profile process in draft-ietf-lamps-header-protection, because none of them matched what we needed, and because we didn't see the overhead of spinning up a PRECIS profile worth the cost

\n
\n

You don't have to spin up PRECIS to register a new profile, from what I just read.

\n
\n

You answer like 12 questions.

", "time": "2024-03-18T00:39:22Z"}, {"author": "John Klensin", "text": "

@Shiva: start with RFC 8264

", "time": "2024-03-18T00:39:41Z"}, {"author": "Stephen Farrell", "text": "

are all precis profiles documented in RFCs so far?

", "time": "2024-03-18T00:39:55Z"}, {"author": "Daniel Gillmor", "text": "

@stephen, they appear to be (see Brian's link above)

", "time": "2024-03-18T00:40:44Z"}, {"author": "Marc Blanchet", "text": "

@stephen see my comment on string prep vs precis. There are a lot of RFCs that are profiles of string prep.

", "time": "2024-03-18T00:40:47Z"}, {"author": "Rich Salz", "text": "

Adding profiles is ExpertReview, so while currently registered ARE in an RFC, future ones do not have to be.

", "time": "2024-03-18T00:41:28Z"}, {"author": "Rich Salz", "text": "

IT's just like registering a new mime type.

", "time": "2024-03-18T00:42:00Z"}, {"author": "Stephen Farrell", "text": "

so if the dispatch result were \"make a precis profile\" wouldn't the authors then likely want an RFC and end up back at dispatch? (despite the expert review) - IOW we seem to be asking the authors to bring us a stone

", "time": "2024-03-18T00:42:22Z"}, {"author": "Orie Steele", "text": "

^ yes

", "time": "2024-03-18T00:42:52Z"}, {"author": "Orie Steele", "text": "

seems they can register the profile with anything the expert might accept, but we don't give strong guidance on what we think the expert should accept.

", "time": "2024-03-18T00:43:26Z"}, {"author": "Brian Carpenter", "text": "

precis needs expert review, so actually an RFC would be unnecessary (technicall)

", "time": "2024-03-18T00:44:05Z"}, {"author": "Pete Resnick", "text": "

@Stephen Farrell The current profiles were in the RFC because they were useful to describe how to make one. But there was never an intention that they needed an RFC.

", "time": "2024-03-18T00:44:07Z"}, {"author": "Murray Kucherawy", "text": "

Are the PRECIS profile reviewers still around?

", "time": "2024-03-18T00:44:34Z"}, {"author": "Stephen Farrell", "text": "

@pete: good intentions are fine, but still seems like \"bring me a stone\"

", "time": "2024-03-18T00:44:35Z"}, {"author": "Michael Richardson", "text": "

Stephen Farrell said:

\n
\n

so if the dispatch result were \"make a precis profile\" wouldn't the authors then likely want an RFC and end up back at dispatch? (despite the expert review) - IOW we seem to be asking the authors to bring us a stone

\n
\n

Yes, but an I-D also works. Sure they might wind up back at dispatch, but then AD sponsor would be a far simpler answer, because there would be little additional work. The precis expert-review process would have already kicked in, I think.

", "time": "2024-03-18T00:44:49Z"}, {"author": "Brian Carpenter", "text": "

And an Info RFC would suffice

", "time": "2024-03-18T00:45:24Z"}, {"author": "Jonathan Lennox", "text": "

Or if it's something another protocol needs, the profile can be done by whatever group is doing that protocol

", "time": "2024-03-18T00:45:30Z"}, {"author": "John Klensin", "text": "

@Stephen: at least as likely, there haven't been more profiles because there has really not been a case for those already specified. And, if the authors did define a profile and wanted an RFC, I can see no reason they couldn't go to the ISE and say \"this is registered and should be published in the RFC Series for the information of the community\". No dispatch or other IETF action.

", "time": "2024-03-18T00:45:34Z"}, {"author": "Rich Salz", "text": "

You DO NOT NEED an RFC. If the PRECIS experts say that, then appeal and get them replaced.

", "time": "2024-03-18T00:45:51Z"}, {"author": "Rohan Mahy", "text": "

Daniel Gillmor said:

\n
\n

We just bypassed the PRECIS profile process in draft-ietf-lamps-header-protection, because none of them matched what we needed, and because we didn't see the overhead of spinning up a PRECIS profile worth the cost

\n
\n

from a quick skim of the draft, it just says use RFC 5322. Do you want to still allow all the obsolete forms?

", "time": "2024-03-18T00:45:55Z"}, {"author": "Andrew Campling", "text": "

Building on \u201cwasteland of horrors\u201d we can now add \u201cprotocol designers need help\u201d :-)

", "time": "2024-03-18T00:45:58Z"}, {"author": "Daniel Gillmor", "text": "

@Rohan: that's not the part i'm referring to :)

", "time": "2024-03-18T00:46:45Z"}, {"author": "Daniel Gillmor", "text": "

but if you want to provide a review, the doc is in last call, and i'd love to hear feedback

", "time": "2024-03-18T00:47:03Z"}, {"author": "Martin Thomson", "text": "

An observation here: the more material we have on the subject of helping people navigate Unicode, the more we create a strong message. That message is \"don't Unicode\".

", "time": "2024-03-18T00:47:06Z"}, {"author": "Tim Bray", "text": "

To Harald's point: In things like JSONpath we are indeed just schlepping text around without much care for what they might mean. Lots of protocol work is at that level.

", "time": "2024-03-18T00:47:13Z"}, {"author": "A.J. Stein", "text": "

\"Don't Unicode!\" is an option?

", "time": "2024-03-18T00:47:40Z"}, {"author": "A.J. Stein", "text": "

For those in that situation, lucky them. :laughing:

", "time": "2024-03-18T00:48:08Z"}, {"author": "Rohan Mahy", "text": "

Daniel Gillmor said:

\n
\n

but if you want to provide a review, the doc is in last call, and i'd love to hear feedback

\n
\n

ok, in my queue....

", "time": "2024-03-18T00:48:09Z"}, {"author": "Rich Salz", "text": "

Rich Salz said:

\n
\n

You DO NOT NEED an RFC. If the PRECIS experts say that, then appeal and get them replaced.

\n
\n

And since the experts are Peter St Andre, Pete Resnick, and Andrew Sullivan, seems like that should happen anyway.

", "time": "2024-03-18T00:48:27Z"}, {"author": "Stephen Farrell", "text": "

so 2+ hours into this mega-session I conclude there's too much dispatching going on when the answers are obvious; maybe people are shy about trusting/defending their (AD) judgements but I'd prefer a session like this be shorter and focus on stuff that's hard to figure out

", "time": "2024-03-18T00:48:41Z"}, {"author": "George Michaelson", "text": "

hard to know whats hard in advance Stephen. Good in principle but who gatekeeps?

", "time": "2024-03-18T00:49:13Z"}, {"author": "Pete Resnick", "text": "

@Stephen Farrell What Rich said. They write the profile. PSA, or me, or Andrew helps them if needed. Iterate. Register. No further dispatching. No RFC.

", "time": "2024-03-18T00:49:43Z"}, {"author": "Stephen Farrell", "text": "

\"no further dispatching\" - wanna bet a beer?

", "time": "2024-03-18T00:50:03Z"}, {"author": "Pete Resnick", "text": "

No stone.

", "time": "2024-03-18T00:50:03Z"}, {"author": "Pete Resnick", "text": "

I'll bet two beers.

", "time": "2024-03-18T00:50:23Z"}, {"author": "Stephen Farrell", "text": "

done

", "time": "2024-03-18T00:50:31Z"}, {"author": "Rich Salz", "text": "

I'll take that bet. Many things in the TLS registries come from the outside and have no dispatch at all. (I'm one of the TLS experts)

", "time": "2024-03-18T00:50:37Z"}, {"author": "Henk Birkholz", "text": "

I'd bet beer on \"dispatch\". Read it?

", "time": "2024-03-18T00:51:18Z"}, {"author": "Tommy Jensen", "text": "

I'd be happy to have easy to dispatch topics as long as we can get through them quickly, because like George said, who determines what is easy to dispatch? Leads us to the infamous SO \"closed as off topic\" effect

", "time": "2024-03-18T00:51:18Z"}, {"author": "Brian Carpenter", "text": "

I have found that the \"replace\" bit in the following Python statement is essential:

", "time": "2024-03-18T00:51:26Z"}, {"author": "Brian Carpenter", "text": "

file = open(f, \"r\",encoding='utf-8', errors='replace')

", "time": "2024-03-18T00:51:49Z"}, {"author": "Daniel Gillmor", "text": "

ugh, brian, that just kicks the failure down to some other place in my experience. you're creating detective work for your future self.

", "time": "2024-03-18T00:52:52Z"}, {"author": "Andrew Campling", "text": "

On \u201ceasy to dispatch\u201d, I recall we had two \u201cten minute\u201d items in 118 which I believe took the best part of an hour and continued on the list afterwards.

", "time": "2024-03-18T00:52:56Z"}, {"author": "Brian Carpenter", "text": "

I have found the 'replace' in what follows essential, but I don't know why:

", "time": "2024-03-18T00:53:13Z"}, {"author": "Marc Blanchet", "text": "

i18n has a lot of snakes... I'm against moving a i18n related draft to AD sponsored. It needs careful community review.

", "time": "2024-03-18T00:53:16Z"}, {"author": "Eric Rescorla", "text": "

Well we can dispatch one to /dev/null and the other to something else

", "time": "2024-03-18T00:53:36Z"}, {"author": "Henk Birkholz", "text": "

A place in art area

", "time": "2024-03-18T00:53:36Z"}, {"author": "Brian Carpenter", "text": "

(sorry, runt message)

", "time": "2024-03-18T00:53:42Z"}, {"author": "Orie Steele", "text": "

^ thanks for that comment Marc.

", "time": "2024-03-18T00:53:42Z"}, {"author": "Pete Resnick", "text": "

I must agree with @Daniel Gillmor earlier comment: \"wasteland of horrors\" and \"disaster\" I think are overdoing the mess here. Mess, no doubt, but just a mess.

", "time": "2024-03-18T00:54:27Z"}, {"author": "Brian Carpenter", "text": "

@Daniel, sure, it's lazy programming

", "time": "2024-03-18T00:55:08Z"}, {"author": "Martin D\u00fcrst", "text": "

@Brian: For data that's mostly for human readers, your suggestion is good. For protocol elements that have to round-trip, it won't work.

", "time": "2024-03-18T00:56:03Z"}, {"author": "Tara Tarakiyee", "text": "

to the isg?

", "time": "2024-03-18T00:56:03Z"}, {"author": "Daniel Gillmor", "text": "

IESG

", "time": "2024-03-18T00:56:12Z"}, {"author": "Tara Tarakiyee", "text": "

ah

", "time": "2024-03-18T00:56:16Z"}, {"author": "Daniel Gillmor", "text": "

thanks Jim and Shuping for the on-site chairing work!

", "time": "2024-03-18T00:56:26Z"}, {"author": "Bron Gondwana", "text": "

I put my hand up to speak about it NOW, and with 35 minutes left, it seems odd to me to shut the session

", "time": "2024-03-18T00:56:35Z"}, {"author": "Daniel Gillmor", "text": "

Bron, sorry :(

", "time": "2024-03-18T00:56:58Z"}, {"author": "Daniel Gillmor", "text": "

can you put your comments in the notes?

", "time": "2024-03-18T00:57:09Z"}, {"author": "Daniel Gillmor", "text": "

or you want to talk about the session structure itself?

", "time": "2024-03-18T00:57:26Z"}, {"author": "Bron Gondwana", "text": "

sure :) I'm already writing notes - I mean - most of it has been said here. But I wouldn't give people 15 minutes to pontificate

", "time": "2024-03-18T00:57:31Z"}, {"author": "Bron Gondwana", "text": "

5 minute presentation, 10 minutes to answer questions

", "time": "2024-03-18T00:57:48Z"}, {"author": "Daniel Gillmor", "text": "

yes, as chairs we should have been more aggressive about policing the slides

", "time": "2024-03-18T00:57:54Z"}, {"author": "Bron Gondwana", "text": "

I'd also say; if people hop in the queue straight away - let them start the dispatch discussion immediately

", "time": "2024-03-18T00:58:37Z"}, {"author": "Bron Gondwana", "text": "

\"it's answered in a later slide\" can be a legit response, but often the answer is clear by slide 2

", "time": "2024-03-18T00:58:52Z"}]