Thanks for your detailed responses @MalithHatananchchige, I plan to take a closer look at this the next time I get a chance - particularly regarding the use of regularly updated IP location databases.
In the meantime I have a proposal to adopt 
p.s. your input regarding the nodes with the same geolocation below would be useful if you get a chance 
Proposal 132178
TLDR: I’ve voted to adopt this proposal. Replaces one down node with an up node 
Replaces another node to improve decentralisation (note that this subnet is still violating the country limit though 
)
Interestingly, while reviewing this proposal...
I noticed that two nodes that already belong to this subnet (and which belong to different data centers, owners, and node providers), actually have the exact same geolocation based on their IP address (something to ponder 
) →
| Country | Data Center | Owner | Node Provider | Node | Status |
|---|---|---|---|---|---|
| India (19.1412, 73.0087) | Navi Mumbai 1 (nm1) | Rivram | Rivram Inc | 3y7fy-fd2oe-33qxg-wq7y6-zzplk-33jhm-n4glx-2c7ij-k24nn-jbsst-xae | UP |
| India (19.1412, 73.0087) | New Delhi 1 (nd1) | Marvelous Web3 DC | Marvelous Web3 | 5wzcz-mfner-c5wor-3liei-7mpao-vkult-zdds6-6n3rg-42ksv-6zzqt-vae | UP |
Using another IP location provider indicates these are both actually in Sri Lanka. I gather this provider keeps a more up-to-date database, so will use this one in the future (thanks for the tip @MalithHatananchchige). In any case, both nodes still resolve to the same location (yet are regarded as completely separate entities that would be uninclined to collude)…
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
| Smallest Distance | Average Distance | Largest Distance | |
|---|---|---|---|
| EXISTING | 0 km | 8007.1 km | 18490.237 km |
| PROPOSED | 0 km | 8073.407 km (+0.8%) | 18490.237 km |
This proposal slightly increases decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical increase in localised disaster resilience).
Subnet characteristic counts →
| Continents | Countries | Data Centers | Owners | Node Providers | |
|---|---|---|---|---|---|
| EXISTING | 5 | 19 | 28 | 28 | 28 |
| PROPOSED | 5 | 21 (+9.5%) | 28 | 28 | 28 |
This proposal slightly improves 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 | 9 | 4 | 1 | 1 | 1 |
| PROPOSED | 9 | 4 | 1 | 1 | 1 |
See here for acceptable limits → Motion 132136
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
Known Neurons to follow if you're too busy to keep on top of things like this
If you found this analysis helpful and would like to follow the vote of the LORIMER known neuron in the future, consider configuring LORIMER as a followee for the Subnet Management topic.
Other good neurons to follow:
-
CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)
-
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)