Mobile basebands already get the local time and UTC offset when connecting to a tower, there's no need to power up the GPS antenna and receiver separately.
Although Google did come up with the original specification their influence over the IETF specifications is not overarching nor absolute; gQUIC is substantially different from IETF QUIC which has caused Google themselves to have implementation and interop issues in their deployments. OS vendors, CDNs, academic researchers, and individuals have all contributed to the resulting specifications that have emerged in a standards body that is by far the most open as the requisite to participate is a functioning email address. All matters and decision making are publicly available for observation and scrutiny.
There is no requirement for people to implement this protocol and it won't be appropriate to every use case that exists today. TCP, UDP, HTTP/1.1, and HTTP/2 are not going away - all continue to undergo standardisation, research, and new implementations.
(Disclosure: I'm not a Google employee, but I have participated in the QUIC and httpbis working groups)
I don't think nuclear explosions belong in that list. They have tremendous power, but very limited energy on a planetary scale. Do you have a source that says otherwise?
There are multiple implementations and their interoperability is tested [1], with some implementations already having bindings to higher level languages (aioquic) or into existing servers (nginx).
ntpd is now looked after by the Network Time Foundation, but more importantly many distributions use other implementations of the protocol like chronyd.
iPhone 7 onwards[1], Qualcomm Snapdragon 610 onwards[2], and Intel Skylake and later CPUs[3] can all encode and decode H.265 in hardware to varying profile levels.
QUIC is already getting those optimisations as the existing large deployments are incentivised to do so, as one example Kazuho Oku from Fastly made changes to their TLS implementation that showed improvements to AEAD and header encryption[1]. I suspect we will see improvements to QUIC's performance at a pace faster than the optimisations to TLS were made to make ubiquitous use of it trivial.
Every time a new AWS region is made public, it continues to highlight the disparity in services availability across the regions, as well as making information about services available. Many regions are "discovered" because the ip-regions.json file is updated long before the press release, but it will be some weeks to months before key information needed to spin up infrastructure appears in documentation, for example things like the ELB hosted zone identifier, which at time of writing is not documented.
To extend what I'm trying to say is that customers shouldn't have to do this and that updating of this data (which ideally should be in a machine readable format, much like ip-ranges.json) is just another step. I would like to hope that AWS already has playbooks for taking a region out of closed-beta and making it GA. If the listing of af-south-1 is already present on other sections of documentation this may already be the case.
Show me that magic unicorn company that spins data centres like that with 0 documentation bugs and I’ll join you criticising them. As it stands with limited resources I am pretty impressed with the speed AWS keeps adding capacity around the world.
Screw-ups will happen no matter how much wishful thinking and effort is spent preventing them. If you assume perfection in things then you will be sorely disappointed by most everything.
The AWS SDKs I've dissected contain the information needed to talk to each (service, region) tuple as machine-readable data. They seem to converge at boto:
This is incredibly useful, thanks! Whist it has some region information and endpoints, boto's lacking other useful information - availability zone count, hosted zones IDs for services like S3, etc. This data publicly lives in a variety of tables across their documentation, and is painful to scrape.
As a followup, I've found that the Terraform AWS provider needs information that boto doesn't – specifically, it needs region-specific details which can only be found in the documentation. They have a checklist for what to do when a new region gets announced:
I too am disappointed that AWS doesn't publish this information in a convenient way. On the other hand, well… source code _is_ a machine readable data format, and Go ASTs aren't that scary:
Terraform follows AWS changes better than CloudFormation, so tracking Terraform might be a reasonable solution. One could even build a process to automatically retrieve the Terraform AWS provider source code, extract the necessary identifiers, and update the relevant data file living in an internal repository. Don't ask me how I know :-/
