I think the spec is supposed to be one ball per second, but I guess that's not really adhered to.
Tangentially, I think it'd be interesting to use something like this to explain the networking concepts of throughout, latency, jitter, baud vs bits per second, symbol rate and bits per symbol.
You can find analogous examples in the main video to compare to all of those concepts.
Nothing in IPv6 says you have to stop dividing at the /64 level.
There has been some hardware that takes a bit of a performance hit when doing route lookups that are longer than /64 in the past, but if you're doing this all in software on an end host, that's not an issue.
Go ahead and divide up that /64 to smaller blocks for your classification purposes, you'll still have plenty.
The client obtains the network prefix from the RA, and then the client tries to generate unique host address.
""
The IPv6 stateless autoconfiguration mechanism requires no manual
configuration of hosts, minimal (if any) configuration of routers,
and no additional servers. The stateless mechanism allows a host to
generate its own addresses using a combination of locally available
information and information advertised by routers. Routers advertise
prefixes that identify the subnet(s) associated with a link, while
hosts generate an "interface identifier" that uniquely identifies an
interface on a subnet. An address is formed by combining the two.
In the absence of routers, a host can only generate link-local
addresses. However, link-local addresses are sufficient for allowing
communication among nodes attached to the same link.
""
Basically it explains that SLAAC RFC itself does not define the /64 limitation, but other RFCs that are relevant to network operation do.
"""
The addressing architecture [RFC4291] [RFC7136] sets the IID length
at 64 bits for all unicast addresses and therefore for all media
supporting SLAAC. An immediate effect of fixing the IID length at 64
bits is, of course, that it fixes the subnet prefix length also at 64
bits, regardless of the aggregate prefix assigned to the site
concerned, which in accordance with [RFC6177] should be /56 or
shorter.
"""
The highway=street_lamp tag indicates that there is a lamppost (which can be a navigational aid), but is a much more detailed form of mapping that should be used in addition to the lit-key on the ways themselves.
As others have mentioned, the poles in Louisville are owned mostly by a mix of AT&T (about 40%) and our local power utility (Louisville, Gas & Electric; LG&E) (about 60%).
But pole ownership really isn't relevant, here. The right for new companies to attach to the poles isn't in doubt, and isn't part of this dispute.
The dispute here is part of the make ready process...who has the right to rearrange the wires already on the pole to make space for the new attacher? Even the right to have the space made available isn't in doubt...it's merely who does the actual work of making it available.
Having worked at a CLEC in the mid-2000s, I can well imagine the pain involved in ATT "making ready" a utility pole. If they have a 60-day window, then in the typical case, on day 58 they'll bounce your work order with some nonsensical reason code. So you hurry to follow up with your service rep that day, but she'll have to "investigate", which will take until the weekend, and then you'll get a "just resubmit it" on next Tuesday. Then if you're lucky the made_ready status in the database will change sometime in the next 60 days. At no point will a tech actually visit the pole in question. They just figure that it's right and proper for a competitor of theirs to have to wait three months to serve a customer.
While you're not wrong...all of the issues you mention are, in general, issues that have to be dealt with. Those issues are, however, all addressed as part of the permitting process to be allowed to attach to the poles.
What's at issue in Louisville is the make ready process after the permit has been issued (after it has been determined that the poles have enough room and are strong enough to handle the new wires).
Tangentially, I think it'd be interesting to use something like this to explain the networking concepts of throughout, latency, jitter, baud vs bits per second, symbol rate and bits per symbol.
You can find analogous examples in the main video to compare to all of those concepts.