^ This proposal was rejected (DFINITY noticed that one of the proposed nodes was due to be decommissioned - the proposal for that decommissioning is now out → Proposal: 131758).
There’s now a revised open proposal for this subnet → Proposal 131789. Thanks again @sat, the proposal summary is now super informative! 
I’ve independently verified the proposal claims below. As before, one node is down and is replaced by an up node by the same node provider in Japan. The other node change is intended to optimise subnet decentralisation coefficients. This optimisation appears to be mostly positive.
Subnet node distance stats (distance between any 2 nodes in the subnet) →
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 71.122 km | 6513.222 km | 16469.974 km |
| PROPOSED | 71.122 km | 6215.817 km (-4.6%) | 16469.974 km |
This proposal slightly reduces decentralisation considered purely in terms of geographic distance (and therefore there’s a slight theoretical reduction in localised disaster resilience). 
Subnet characteristic counts →
| Continents | Countries | Data Centers | Owners | Node Providers | |
|---|---|---|---|---|---|
| EXISTING | 3 | 9 | 13 | 13 | 13 |
| PROPOSED | 3 | 10 (+10%) | 13 | 13 | 13 |
This proposal slightly increases the number of countries that constitute this subnet, improving decentralisation in terms of jurisdiction diversity. 
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
| Continent | Country | Data Center | Owner | Node Provider | |
|---|---|---|---|---|---|
| EXISTING | 7 | 4 | 1 | 1 | 1 |
| PROPOSED | 7 | 3 (-25%) | 1 | 1 | 1 |
See here for acceptable limits → Motion 125549 (note that these are due for a slight revision)
As far as I gather, this subnet is already in violation of the predefined maximum number of nodes within the same country, which is supposed to be 2 for a 13 node subnet.
This proposal brings this number closer to the acceptable limit (though I believe the outcome will still be in violation of the acceptable limit, 3 instead of 2).
The above subnet information is illustrated below, followed by a node reference table:
Map Description
- Red marker represents a removed node (transparent center for overlap visibility)
- Green marker represents an added node
- Blue marker represents an unchanged node
- Highlighted patches represent the country the above nodes sit within (red if the country is removed, green if added, otherwise grey)
- Light grey markers with yellow borders are examples of unassigned nodes that would be viable candidates for joining the subnet according to formal decentralisation coefficients (so this proposal can be viewed in the context of alternative solutions that are not being used)
Table
I’m planning to adopt this proposal as the improvements to subnet decentralisation (in terms of jurisdiction diversity) are more important than the slight increase in average node proximity. I do have some questions though. @SvenF would you be able to answer any of these? 
-
Am I correct in observing that the subnet is currently in violation of the predefined decentralisation coefficient relating to the maximum number of nodes that should belong to the same country? (and that the subnet will still be in violation of this even once this proposal passes, though it will be in a better position than it is now)
-
There are plenty of viable nodes located in South Africa and Australia (illustrated on the map). Any of these would have improved the country coefficient, as well as increasing the average geographic distance between subnet nodes, as well as increasing the number of continents that the subnet is composed of. Am I missing something, or would one of these have potentially been a better choice of node to add to the subnet?
-
When selecting nodes to add to a subnet to optimise decentralisation, is this done in a greedy fashion (considering just the subnet in question), or are redundancy requirements for other subnets also taken into account?
As a side note, there are two nodes (in Switzerland) in this subnet that are very close to one another, roughly an hours drive apart 
(but of course these belong to different node providers and data centre owners, otherwise this would also be a violation of the decentralisation coefficients).