Audio volume is very low - could you please increase it?
", "time": "2023-07-27T16:31:59Z"}, {"author": "Lorenzo Miniero", "text": "Uri: do you mean for remotes? It sounds fine to us
", "time": "2023-07-27T16:32:32Z"}, {"author": "Anna Brunstrom", "text": "i hear well remotely
", "time": "2023-07-27T16:33:19Z"}, {"author": "Jason Livingood", "text": "Volume level is fine for me remotely.
", "time": "2023-07-27T16:33:22Z"}, {"author": "Martin Horneffer", "text": "audio is good here - remotely.
", "time": "2023-07-27T16:33:35Z"}, {"author": "Ira McDonald", "text": "remote volume is fine for me remotely too
", "time": "2023-07-27T16:33:40Z"}, {"author": "Reese Enghardt", "text": "It might be good for Marten to get a bit closer to the mic
", "time": "2023-07-27T16:33:54Z"}, {"author": "Uri Blumenthal", "text": "Yes, remote. Yes, it must be Marten talking too far from the mike.
", "time": "2023-07-27T16:34:14Z"}, {"author": "Shigeya Suzuki", "text": "seems no problem. (I'm attending from Hilton's room..)
", "time": "2023-07-27T16:34:16Z"}, {"author": "Christian Huitema", "text": "I think Marten is speaking quietly, he should be careful to speak close to the mike.
", "time": "2023-07-27T16:34:22Z"}, {"author": "Uri Blumenthal", "text": "Would somebody please inform Marten...?
", "time": "2023-07-27T16:34:39Z"}, {"author": "Christian Huitema", "text": "Works well now for this remote attendee
", "time": "2023-07-27T16:34:49Z"}, {"author": "Marten Seemann", "text": "Got it. Will move closer to the mic
", "time": "2023-07-27T16:38:03Z"}, {"author": "Ira McDonald", "text": "These \"hums\" are not in the recording or remotely accessible - please use the Meetecho polling mechanism for transparency - thanks
", "time": "2023-07-27T17:11:02Z"}, {"author": "John Preu\u00df Mattsson", "text": "Do we need to know more than that we need > 16 kB...
", "time": "2023-07-27T17:19:22Z"}, {"author": "John Preu\u00df Mattsson", "text": "Most security requirements are just taken from current IPsec deployments which this is a repleacement/complement for.
", "time": "2023-07-27T17:23:29Z"}, {"author": "Christian Huitema", "text": "Someone should explain me why there is a need for DTLS over SCTP instead of merely SCTP over DTLS...
", "time": "2023-07-27T17:24:20Z"}, {"author": "Marten Seemann", "text": "@Christian, want to get in queue to ask that question?
", "time": "2023-07-27T17:26:09Z"}, {"author": "John Preu\u00df Mattsson", "text": "Doing changes to a DTLS stack is bad from a security perspective as you then cannot easily do security patches. Much nices to do implementations outside of the DTLS stack.
", "time": "2023-07-27T17:29:21Z"}, {"author": "Christian Huitema", "text": "That's kinda what Hannes is doing: DTLS normally comes bundled with UDP, so off the shelf stack is kinda easier if you port DTLS over SCTP, per RFC 6083. But I have no horse in this race. I am just curious.
", "time": "2023-07-27T17:30:12Z"}, {"author": "Kazuho Oku", "text": "In thought we are kind of deprecating TLS/1.2?
", "time": "2023-07-27T17:30:29Z"}, {"author": "John Preu\u00df Mattsson", "text": "TLS WG is currently discussing deprecating 1.2 and recommending phasing it out. Making something published in 2024 1.2 only would be odd. Our suggestion to focus on DTLS 1.3 got objections last time it was discussed...
", "time": "2023-07-27T17:32:05Z"}, {"author": "Christian Huitema", "text": "What Magnus just said makes the point: if you decrypt below the transport, the transport ignores the bad packets. If you put decryption after transport, injecting a bad chunk pretty much closes the connection.
", "time": "2023-07-27T17:32:32Z"}, {"author": "Martin Duke", "text": "Contrary to Hannes, I think not having to mess with DTLS is very important
", "time": "2023-07-27T17:34:29Z"}, {"author": "Martin Duke", "text": "I find Magnus's nomenclature for the options to be very confusing, making it hard to follow
", "time": "2023-07-27T17:38:09Z"}, {"author": "Tom Herbert", "text": "Does sctp checksum have pseudo header covering addresses?
", "time": "2023-07-27T17:45:02Z"}, {"author": "C. Heard", "text": "The SCTP common header, which is protected by the CRC32c SCTP checksum includes the port numbers but not the IP addresses (RFC9260) There is an encapsulation in UDP (RFC6951), and the UDP checksum would be non-zero if operating over IPv6.
", "time": "2023-07-27T17:57:09Z"}, {"author": "Jason Livingood", "text": "In terms of gaming tests - yes a lot of qualitative. Some games can also report latency stats or the developers can look at QoE in the backend.
", "time": "2023-07-27T18:02:55Z"}, {"author": "Sebastian Moeller", "text": "I would hum for not doing WGLC as this should not be published.
", "time": "2023-07-27T18:12:26Z"}, {"author": "Christian Huitema", "text": "Process complaint: chairs should use the Meetecho hand tool, not the hum in the room. Room only hum is disempowering for remote users.
", "time": "2023-07-27T18:13:36Z"}, {"author": "Roland Bless", "text": "+1
", "time": "2023-07-27T18:14:01Z"}, {"author": "Christian Huitema", "text": "+1 Sebastian: absence of reply to a hum is not approval!
", "time": "2023-07-27T18:14:15Z"}, {"author": "Sebastian Moeller", "text": "Martin, Thanks!
", "time": "2023-07-27T18:15:05Z"}, {"author": "Uri Blumenthal", "text": "I assume somebody is tracking remote attendees?
", "time": "2023-07-27T18:15:09Z"}, {"author": "Christian Huitema", "text": "This kind of draft is exactly why we should not standardize UDP options!
", "time": "2023-07-27T18:17:09Z"}, {"author": "Roland Bless", "text": "I agree with Christian here, this is a layer violation
", "time": "2023-07-27T18:26:28Z"}, {"author": "Martin Duke", "text": "I actually thought this was going to be something else, a new IP protocol number-equivalent since everything runs over UDP now
", "time": "2023-07-27T18:27:59Z"}, {"author": "Martin Duke", "text": "Regarding the hum, the old way is to have a \"jabber scribe\" as we just rehearsed. As AD, there is no policy on using him vs the new tools, and I am disinclined to preemptively micromanage chairs. But please email the chairs with your concerns!
", "time": "2023-07-27T18:30:27Z"}, {"author": "Christian Huitema", "text": "Kazuho is right. These kind of ideas amount to saying that the path is congested, and priority data should be moved first. using ECN is a fine way to solve the issue: network uses ECN to signal congestion, application receives ECN and selects to only use the priority data.
", "time": "2023-07-27T18:32:44Z"}]