Statements in DESIGN.md are inaccurate or incorrect

[stevvooe]

Most of the statements made under "The current state of container image distribution has several issues, which this extension attempts to improve" part of DESIGN.md file are false or inaccurate. I have made some commentary in line to ensure these are corrected. For the most part, it seems the complaints are about the implementation, rather than the protocol itself. In that regard, the protocol is more capable than most implementations.

The docker:// protocol and schema are not truly state-less HTTP, and therefore cannot be implemented by a "dumb" CDN. By necessity a stateful application must be run by a distributor, which is not always reasonable or possible. It also makes caching harder to implement for something like Varnish.

Untrue. You can distribute images with a dumb, static-file registry. The protocol and URL layout are designed to make this easy. Cases where this is not true should be considered bugs to the Docker implementation. We do this in production and it is fairly straightforward to setup.

This is not necessarily the case for PUSH, as that requires active validation and hashing, albeit, using a registry as a point of origin is an effective way of making this work.

The docker:// protocol is the only "official" way of distributing such images, which makes other methods of distribution (saving an image and then distributing it via FTP, BitTorrent, etc) out-of-band and not supported. While this extension does not require that all such methods be support, it elevates their usefulness by making them much more supportable.

Again, not entirely true and this is more of a product of the implementation than anything else. In fact, the protocol can support distributing blobs through bittorrent or other p2p means. I have demonstrated this with both bittorrent and a hand-rolled p2p protocol. The only reason that Dockeer hasn't supported this is because docker does not store the artifacts unchanged, which is required for most p2p implementations to work. This changes with containerd 1.0 and will be easier to implement.

Image "naming" and distribution are linked, tying the orthogonal issues of identity and source-of-files. This further complicates the jobs of CDNs, requiring them to provide DNS round-robin style distribution rather than GNU/Linux distribution "mirroring".

Again, this is more of a matter of implementation than a limitation of the protocol. By deferring to a client-side mapping of configuration to namespaces or authorities, this problem goes away.