[{"author": "\u00c9ric Vyncke", "text": "

don't jinx the meeting

", "time": "2023-11-07T12:03:46Z"}, {"author": "George Michaelson", "text": "

More drafts is NOT good metric. The metric is CLOSED drafts to charter and not charter extension

", "time": "2023-11-07T12:07:05Z"}, {"author": "George Michaelson", "text": "

Ie direction of line should be down and to the right not up and to the rigjt

", "time": "2023-11-07T12:07:56Z"}, {"author": "\u00c9ric Vyncke", "text": "

You are a data scientist ;-)

", "time": "2023-11-07T12:08:16Z"}, {"author": "Ryo Yanagida", "text": "

I wonder if we have a good 'rough numbers' that we can use based on population or some stats to gain some confidence in the prefix size needed.

", "time": "2023-11-07T12:15:19Z"}, {"author": "Ryo Yanagida", "text": "

We don't have crystal ball but... We have some numbers out there...

", "time": "2023-11-07T12:16:04Z"}, {"author": "George Michaelson", "text": "

Arguably that's what delegation stats is telling us: few /19 and larger have been handed out so a /20 encompasses most of what we expected to have to document by example

", "time": "2023-11-07T12:16:27Z"}, {"author": "Ole Tr\u00f8an", "text": "

If I want to \"document\" IPv6, I need to be able to represent the whole IPv6 address space in documentation... :-)

", "time": "2023-11-07T12:16:31Z"}, {"author": "Ryo Yanagida", "text": "

George Michaelson said:

\n
\n

Arguably that's what delegation stats is telling us: few /19 and larger have been handed out so a /20 encompasses most of what we expected to have to document by example

\n
\n

I wonder if we could use population number/projection and device usage as a function to see what sort of size is needed in not-yet-present size of network? Maybe if you try to be future proof for 20-years ahead or so, that's the kind of size you want to think about.

", "time": "2023-11-07T12:18:44Z"}, {"author": "Ryo Yanagida", "text": "

At least that's where this thought came from

", "time": "2023-11-07T12:18:57Z"}, {"author": "Greg Choules", "text": "

I'm taking the Hollywood approach and using something impossible. greg:: sounds like a highly vain idea. :troll:

", "time": "2023-11-07T12:19:18Z"}, {"author": "Anthony Somerset", "text": "

TBH if we come back to this in 20 years and needing more then i don't see a specific issue - Geoff's comment about we learned as we deployed is very relevant i do like the idea of reserving a whole /3 e.g. d0c0::/3 as mentioned by Warren

", "time": "2023-11-07T12:21:09Z"}, {"author": "Ray Bellis", "text": "

why use d0c0:: when we could use 0d0c:: abbreviated as d0c::

", "time": "2023-11-07T12:21:12Z"}, {"author": "\u00c9ric Vyncke", "text": "

I love d0c::/16 even but this is perhaps too much and is not unicast block

", "time": "2023-11-07T12:21:54Z"}, {"author": "Ole Tr\u00f8an", "text": "

That's a /16. doc::/16. Could also be documentation::/16 of course.

", "time": "2023-11-07T12:22:02Z"}, {"author": "Ray Bellis", "text": "

even better then, it's fundamentally unroutable! :D

", "time": "2023-11-07T12:22:22Z"}, {"author": "Ryo Yanagida", "text": "

Anthony Somerset said:

\n
\n

TBH if we come back to this in 20 years and needing more then i don't see a specific issue - Geoff's comment about we learned as we deployed is very relevant i do like the idea of reserving a whole /3 e.g. d0c0::/3 as mentioned by Warren

\n
\n

Sure, and my thoughts were purely on if we could do any better, and document more concretely how we came to that number, that could be useful. But obviously, not a critical point of this document/approach at all.

", "time": "2023-11-07T12:22:38Z"}, {"author": "\u00c9ric Vyncke", "text": "

better would be 2d0c::/20

", "time": "2023-11-07T12:23:00Z"}, {"author": "\u00c9ric Vyncke", "text": "

Bike shedding for now ;)

", "time": "2023-11-07T12:23:18Z"}, {"author": "Ray Bellis", "text": "

although 0800::/5 is just listed as \"reserved\"

", "time": "2023-11-07T12:23:22Z"}, {"author": "Ole Tr\u00f8an", "text": "

rtfm::/16 ?

", "time": "2023-11-07T12:23:38Z"}, {"author": "XiPeng Xiao", "text": "

Hi George, heard you. It's true that quality of drafts is more important than quantity but quality is difficult to measure. You are welcome to suggest some KPIs

", "time": "2023-11-07T12:25:01Z"}, {"author": "Erik Nygren", "text": "

Somewhat related to the examples topic: while it probably doesn't belong in a draft, I've been trying to encourage people to NOT use \"dead:beef\" in examples from an inclusive language perspective. Some of our colleagues may not be comfortable with it.

", "time": "2023-11-07T12:26:55Z"}, {"author": "Anthony Somerset", "text": "

my favourite is actualle 1c3:c01d:bee4

", "time": "2023-11-07T12:28:45Z"}, {"author": "Warren Kumari", "text": "

bad:c0ff:ee

", "time": "2023-11-07T12:29:47Z"}, {"author": "\u00c9ric Vyncke", "text": "

:cafe: with a French accent ;-)

", "time": "2023-11-07T12:30:05Z"}, {"author": "Justin Iurman", "text": "

Erik Nygren said:

\n
\n

Somewhat related to the examples topic: while it probably doesn't belong in a draft, I've been trying to encourage people to NOT use \"dead:beef\" in examples from an inclusive language perspective. Some of our colleagues may not be comfortable with it.

\n
\n

Too bad for the good old 'dead:beef'. How about 'f00d:c0de' or 'cafe:c0ca' (joking of course)

", "time": "2023-11-07T12:30:20Z"}, {"author": "Anthony Somerset", "text": "

so on IPREF - whats new compared to previous presentations on this topic?
\ni am failing to see it

", "time": "2023-11-07T12:30:41Z"}, {"author": "\u00c9ric Vyncke", "text": "

No more in intarea but in v6ops

", "time": "2023-11-07T12:31:21Z"}, {"author": "Momoka Yamamoto", "text": "

no twitter is sad...

", "time": "2023-11-07T12:31:41Z"}, {"author": "Anthony Somerset", "text": "

isn't it traversing NAT by doing its own type of NAT?

", "time": "2023-11-07T12:33:04Z"}, {"author": "Erik Nygren", "text": "

+1 to Lorenzo's comment that this (IPREF) might have been more interesting a decade or two ago, but not now. At this point managing overlapping uses of rfc1918 / private address space is painful enough that having yet some more complexity to prolong that seems more painful than just doing more with IPv6-only.

", "time": "2023-11-07T12:38:13Z"}, {"author": "\u00c9ric Vyncke", "text": "

@meetecho there is an annoying echo heard from the stage (unsure whether the echo is heard in the room though)

", "time": "2023-11-07T12:44:01Z"}, {"author": "Erik Nygren", "text": "

Another reason to race the full handshake is that when PMTUD fails it often shows up with the TLS handshake failing but TCP connection succeeding.

", "time": "2023-11-07T12:44:19Z"}, {"author": "Lorenzo Miniero", "text": "

Eric: we'll notify the AV team

", "time": "2023-11-07T12:44:59Z"}, {"author": "\u00c9ric Vyncke", "text": "

thanks

", "time": "2023-11-07T12:45:22Z"}, {"author": "Doug Montgomery", "text": "

+1 broken web proxies causing HEB pain is often experienced in USG enterprises.

", "time": "2023-11-07T12:47:03Z"}, {"author": "Eric Orth", "text": "

Queue was full before the presentation finished and Tommy called for questions. This is a popular one.

", "time": "2023-11-07T12:49:05Z"}, {"author": "Ryo Yanagida", "text": "

I suspect the echo in the room is purely acoustic, if not, wrong delay set on the speaker arrays

", "time": "2023-11-07T12:50:28Z"}, {"author": "Ryo Yanagida", "text": "

at least that's the impression I have onsite

", "time": "2023-11-07T12:50:40Z"}, {"author": "\u00c9ric Vyncke", "text": "

Does the room also hear the echo or is it only the stage N

", "time": "2023-11-07T12:50:55Z"}, {"author": "\u00c9ric Vyncke", "text": "

s/N/?/

", "time": "2023-11-07T12:51:00Z"}, {"author": "Momoka Yamamoto", "text": "

+1 to Lorenzo

", "time": "2023-11-07T12:51:04Z"}, {"author": "\u00c9ric Vyncke", "text": "

+1 to Lorenzo

", "time": "2023-11-07T12:51:17Z"}, {"author": "Antoine Fressancourt", "text": "

we don't get echo online

", "time": "2023-11-07T12:51:18Z"}, {"author": "Ryo Yanagida", "text": "

I am on the stage right, front but I do hear the echo

", "time": "2023-11-07T12:51:21Z"}, {"author": "Eric Orth", "text": "

+1. The biggest IPv6 expertise needed here is to agree that IPv6 is preferred over IPv4.

", "time": "2023-11-07T12:51:42Z"}, {"author": "Momoka Yamamoto", "text": "

Eric Orth said:

\n
\n

+1. The biggest IPv6 expertise needed here is to agree that IPv6 is preferred over IPv4.

\n
\n

which is already done a long time ago.

", "time": "2023-11-07T12:52:20Z"}, {"author": "Eric Orth", "text": "

Right. The biggest thing is decided and not controversial.

", "time": "2023-11-07T12:52:58Z"}, {"author": "\u00c9ric Vyncke", "text": "

one draft can be adopted by WG but be reviewed/presented by several WG.

", "time": "2023-11-07T12:53:28Z"}, {"author": "Ole Tr\u00f8an", "text": "

Will the chairs do a hum for adoption here?

", "time": "2023-11-07T12:54:17Z"}, {"author": "Erik Nygren", "text": "

When doing SVCB/HTTPS RR we talked about having a SvcParam indicating a strong preference for IPv6 (eg, \"this service is IPv6-only\"). Would there be interest in that for influencing this behavior? It would fit well into a HappyEyeballsV3 spec.

", "time": "2023-11-07T12:54:21Z"}, {"author": "\u00c9ric Vyncke", "text": "

@ole (w/o any hat) how many have read the draft ? (and I am afraid that we are running out of time)

", "time": "2023-11-07T12:55:11Z"}, {"author": "Anthony Somerset", "text": "

Happy Eyeballs Working Group?

", "time": "2023-11-07T12:55:24Z"}, {"author": "Ryo Yanagida", "text": "

More BoF? More WG?

", "time": "2023-11-07T12:55:54Z"}, {"author": "Erik Nygren", "text": "

Would TAPS be an appropriate place for this?

", "time": "2023-11-07T12:55:56Z"}, {"author": "Ryo Yanagida", "text": "

More slot?

", "time": "2023-11-07T12:55:58Z"}, {"author": "Eric Orth", "text": "

Maybe send to dispatch?

", "time": "2023-11-07T12:56:07Z"}, {"author": "Eric Orth", "text": "

(Assuming it wasn't already dispatched here.)

", "time": "2023-11-07T12:56:18Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

As someone with an ISP that's just hnding me a /56 always, yes please.

", "time": "2023-11-07T13:09:41Z"}, {"author": "Anthony Somerset", "text": "

+100 for adopt

", "time": "2023-11-07T13:10:19Z"}, {"author": "Erik Nygren", "text": "

As someone who would rather not to have to rely on bridge mode to adopt, +100 to adopt

", "time": "2023-11-07T13:10:38Z"}, {"author": "\u00c9ric Vyncke", "text": "

Ole's proposal smells somehow to the SNAC WG work (at first sight)

", "time": "2023-11-07T13:22:34Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

I notice the in room echo when facing the back of the room.

", "time": "2023-11-07T13:26:24Z"}, {"author": "Anthony Somerset", "text": "

lots of hard reflective surfaces on side and rear - recipe for pain - much like NAT

", "time": "2023-11-07T13:27:07Z"}, {"author": "\u00c9ric Vyncke", "text": "

@alejandro, if facing the screen do you hear the echo ? If echo is only heard from the stage, then it is OK

", "time": "2023-11-07T13:27:28Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

I had not noticed it until Iwas looking back; just reporting since there was talk of echo earlier.

", "time": "2023-11-07T13:28:06Z"}, {"author": "Erik Nygren", "text": "

I keep not being fast enough for the queue. :)

\n

One place I'd really like to see this would be for us to come up with some better standards for how cloud providers can provide extensible IPv6 addresses to guest VMs in some consistent ways, especially with the desire to extend down to containers, child VMs, VPCs, etc.

", "time": "2023-11-07T13:29:00Z"}, {"author": "\u00c9ric Vyncke", "text": "

+1 Erik

", "time": "2023-11-07T13:29:15Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

It's not only heard from the stage, but the stage would be where folks are facing te back of the room all of the time, so they would notice it more up there.

", "time": "2023-11-07T13:30:08Z"}, {"author": "Lorenzo Miniero", "text": "

The AV team explained that it's caused by the nature of this room (plain walls, marble floor, \"empty\" hall effect)

", "time": "2023-11-07T13:30:26Z"}, {"author": "Lorenzo Miniero", "text": "

(it=echo)

", "time": "2023-11-07T13:30:34Z"}, {"author": "Nick Buraglio", "text": "

Agreed, Erik. I didn't make the queue but I am in favor and believe we should work on this in order to provide guidance otherwise, like Tim said, it will get creative and go poorly.

", "time": "2023-11-07T13:30:52Z"}, {"author": "Anthony Somerset", "text": "

also vote to adopt and continue work on this

", "time": "2023-11-07T13:31:10Z"}, {"author": "Markus Stenberg", "text": "

+1 on Erik too (you probably said it here before me, and Lorenzo was in that direction somewhat too)

", "time": "2023-11-07T13:33:06Z"}, {"author": "\u00c9ric Vyncke", "text": "

Sad to see a IPv6 over IPv4 tunnel

", "time": "2023-11-07T13:35:35Z"}, {"author": "Anthony Somerset", "text": "

assuming thats just for testing but yes sad

", "time": "2023-11-07T13:35:56Z"}, {"author": "\u00c9ric Vyncke", "text": "

everyone needs to start somewhere

", "time": "2023-11-07T13:36:14Z"}, {"author": "Anthony Somerset", "text": "

its massively impressive for such a student led initiative - i think some ISP's could learn from this team :)

", "time": "2023-11-07T13:37:44Z"}, {"author": "Ryo Yanagida", "text": "

very unique and exciting project for this team of students! Quite nice how this could be facilitated at an institution.

", "time": "2023-11-07T13:38:44Z"}, {"author": "\u00c9ric Vyncke", "text": "

+1 to the above

", "time": "2023-11-07T13:39:01Z"}, {"author": "\u00c9ric Vyncke", "text": "

they deserve applause at the end (even if unusual at IETF WG meeting)

", "time": "2023-11-07T13:39:27Z"}, {"author": "Ryo Yanagida", "text": "

+1

", "time": "2023-11-07T13:39:43Z"}, {"author": "Markus Stenberg", "text": "

Pessimist hat on.

\n

I wonder if the cloud provider case is getting too late to change though - given e.g. current infra relies on auditing by addresses (not prefixes), the keenness to hand out prefixes at this point might not be high.

\n

(Some cloud providers make it available as an option even now, but changing the rest or making it a default might be challenging by now.)

", "time": "2023-11-07T13:42:58Z"}, {"author": "Daniel Havey", "text": "

I would love to turn off IPv4 in Windows, but, I am afraid that a billion and a half people will yell at me.

", "time": "2023-11-07T13:46:16Z"}, {"author": "Mohit Tahiliani", "text": "

Hi Eric, Yes, the tunnel is only for the testbed.

", "time": "2023-11-07T13:47:34Z"}, {"author": "\u00c9ric Vyncke", "text": "

thx

", "time": "2023-11-07T13:47:46Z"}, {"author": "Nick Buraglio", "text": "

The USG would be very happy, Daniel =)

", "time": "2023-11-07T13:48:00Z"}, {"author": "Nick Buraglio", "text": "

(although we'd be happy with 464XLAT in windows)

", "time": "2023-11-07T13:48:43Z"}, {"author": "Eduard V", "text": "

If you wait additional 5 years - the migration would be even more smooth.

", "time": "2023-11-07T13:54:53Z"}, {"author": "Nick Buraglio", "text": "

We're in the midst of doing an option 108 deployment for the SC24 supercomputing conference wifi right now. The experience has been pretty much the same.

", "time": "2023-11-07T13:56:43Z"}, {"author": "Ole Tr\u00f8an", "text": "

Looks like the IETF NAT64 network isn't doing 108. But it looks equally fine to not have 108. I.e my host sends DHCPv4 discovery messages forever, but with exponential backoff, do I care? What am I missing regarding 108?

", "time": "2023-11-07T13:57:54Z"}, {"author": "Nick Buraglio", "text": "

108 lets the hosts decide and run at their level of evolution. Windows systems happily ignore 108 (currently) and run dual stacked, which makes it a much more seamless experience than a NAT64/DNS64. It also allows legacy devices to operate as IPv4 only without having to create a \"kids table\" network for them

", "time": "2023-11-07T14:00:13Z"}, {"author": "Ole Tr\u00f8an", "text": "

Right, so essentially allows you to share legacy devices on the same link. thanks

", "time": "2023-11-07T14:01:06Z"}, {"author": "Nick Buraglio", "text": "

Yes. Basically if a device does 464XLAT it does, which is a far better experience from an application experience.

", "time": "2023-11-07T14:01:30Z"}]