Subnet Management - 5kdm2 (Application)

[Lorimer]

This topic is intended to capture Subnet Management activities over time for the 5kdm2 subnet, providing a place to ask questions and make observations about the management of this subnet.

At the time of creating this topic the current subnet configuration is as follows:

Expand

{
  "version": 44291,
  "records": [
    {
      "key": "subnet_record_5kdm2-62fc6-fwnja-hutkz-ycsnm-4z33i-woh43-4cenu-ev7mi-gii6t-4ae",
      "version": 44291,
      "value": {
        "membership": [
          "ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae",
          "zppi4-egu2x-ylkfm-fttld-d5v43-wq7zs-hnszi-6plxh-6ol3h-ibceq-xae",
          "vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae",
          "srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe",
          "bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe",
          "zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe",
          "oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe",
          "ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe",
          "jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae",
          "wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe",
          "tyofn-r6bgb-5a533-2vptk-hgl47-xz3se-ssxyd-ws4i4-o7c4x-5zczx-gqe",
          "tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae",
          "bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe"
        ],
        "nodes": {},
        "max_ingress_bytes_per_message": 2097152,
        "max_ingress_messages_per_block": 1000,
        "max_block_payload_size": 4194304,
        "unit_delay_millis": 1000,
        "initial_notary_delay_millis": 600,
        "replica_version_id": "a3831c87440df4821b435050c8a8fcb3745d86f6",
        "dkg_interval_length": 499,
        "start_as_nns": false,
        "subnet_type": "verified_application",
        "features": {
          "canister_sandboxing": false,
          "http_requests": true,
          "sev_enabled": false
        },
        "max_number_of_canisters": 120000,
        "ssh_readonly_access": [],
        "ssh_backup_access": [],
        "ecdsa_config": null,
        "chain_key_config": null
      }
    }
  ]
}

[Lorimer]

There’s an open proposal for changing subnet membership - Proposal: 131403 - ICP Dashboard (internetcomputer.org). This information is presented below:

• red marker represents a removed node
• green marker represents an added node
• highlighted patches represent the country a node sits within

Table

	Country	Data Center	Owner	Node Provider	Node
---	Germany	Munich (mu1)	q.beyond	Staking Facilities	tyofn-r6bgb-5a533-2vptk-hgl47-xz3se-ssxyd-ws4i4-o7c4x-5zczx-gqe
+++	Korea (the Republic of)	Seoul 2 (kr2)	Gasan	Web3game	pzv3b-av4if-exyju-qfmed-zbeez-2xlcd-sj22c-zdhus-gnwmo-7cbse-aqe
	Canada	Fremont (fm1)	Hurricane Electric	1G	bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe
	Switzerland	Geneva (ge1)	HighDC	Archery Blockchain SCSp	tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae
	Switzerland	Zurich 4 (zh4)	Nine.Ch	Tomahawk.vc	jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae
	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	zppi4-egu2x-ylkfm-fttld-d5v43-wq7zs-hnszi-6plxh-6ol3h-ibceq-xae
	India	Panvel 2 (pl2)	Yotta	Krishna Enterprises	srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe
	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae
	Japan	Tokyo 3 (ty3)	Equinix	Starbase	oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe
	Romania	Bucharest (bu1)	M247	Iancu Aurel	bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe
	Slovenia	Ljubljana (lj1)	Posita.si	Fractal Labs AG	wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe
	Sweden	Stockholm 1 (sh1)	Digital Realty	DFINITY Operations SA	zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe
	United States of America (the)	Dallas (dl1)	Flexential	87m Neuron, LLC	ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe
	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Honeycomb Capital (Pty) Ltd	ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae

The removed node is replaced with a node based in South Korea. This looks positive for decentralisation. I’ve verified that this node is currently unassigned.

The proposal mentions that his change is needed due to the Munich (mu1) data centre being due for decommissioning. I have some questions about this which I’ve asked on another topic.

[Lorimer]

There’s an open proposal for removing a node from this subnet (along with 2 other subnets - uzr34 (II) and tdb26 (NNS))

• Proposal 132102

I intend to take a closer look later today after work. But for now here’s some contextual info for interested voters.

Map Description

• Red marker represents a removed node (transparent center for overlap visibility)
• Blue marker represents an unchanged node
• Highlighted patches represent the country the above nodes sit within
• 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 - plenty of nodes that the removed node could have been swapped with if this were a ‘Change Subnet Membership’ proposal)

Table

	Continent	Country	Data Center	Owner	Node Provider	Node	Status
---	Asia	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	zppi4-egu2x-ylkfm-fttld-d5v43-wq7zs-hnszi-6plxh-6ol3h-ibceq-xae	DOWN
	Europe	Switzerland	Geneva (ge1)	HighDC	Archery Blockchain SCSp	tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae	UP
	Europe	Switzerland	Zurich 4 (zh4)	Nine.Ch	Tomahawk.vc	jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae	UP
	Asia	India	Panvel 2 (pl2)	Yotta	Krishna Enterprises	srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe	UP
	Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae	UP
	Asia	Japan	Tokyo 3 (ty3)	Equinix	Starbase	oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe	UP
	Asia	Korea (the Republic of)	Seoul 2 (kr2)	Gasan	Web3game	pzv3b-av4if-exyju-qfmed-zbeez-2xlcd-sj22c-zdhus-gnwmo-7cbse-aqe	UP
	Europe	Romania	Bucharest (bu1)	M247	Iancu Aurel	bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe	UP
	Europe	Slovenia	Ljubljana (lj1)	Posita.si	Fractal Labs AG	wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe	UP
	Europe	Sweden	Stockholm 1 (sh1)	Digital Realty	DFINITY Operations SA	zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe	UP
	Americas	United States of America (the)	Dallas (dl1)	Flexential	87m Neuron, LLC	ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe	UP
	Americas	United States of America (the)	Fremont (fm1)	Hurricane Electric	1G	bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe	UP
	Africa	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Honeycomb Capital (Pty) Ltd	ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae	UP

[Lorimer]

@Lorimer

I intend to take a closer look later today after work

I’ve rejected this proposal for numerous reasons. TLDR: It doesn’t actually fix anything, and is unjustified in violating the target IC topology, even if it’s temporary (there’s insufficient information provided in the summary to explain why they’ve proposed this removal in this way):

Expand for more details

• This proposal doesn’t fix the problem of an offline node. Instead it’s removing it from the subnet for some unexplained / unjustified reason (unjustified because it’s not transactionally replacing the node with a good one)
• ‘Remove node from subnet’ proposals are for shrinking subnets (this isn’t and shouldn’t be the intention here). ‘Change Subnet Membership’ proposals are for fixing bad nodes in a subnet (by transactionally swapping them out for good nodes) - which is the proposal type that should have been proposed, and that this proposal should (in my opinion) be superseded by (after rejecting).
• This proposal has a very poor summary (historically these types of proposals have provided much more information in the summary, such as the affected subnets, and the precise set of steps are are planned to follow the proposal). Ever since the ‘Change Subnet Membership’ proposal type was implemented, ‘Remove node from subnet’ proposals have become more or less a thing of the past (at least in this sort of scenario).
  • The proposal does not clearly state what the next steps would be (which IPv6 and IPv4 enabled nodes would be deployed as a next step?)
  • Why isn’t this being done transactionally under one proposal per subnet (why is it justifiable to ask the community to vote the subnet into a state that violates the formal target topology?)
• Accepting this proposal would leave the 3 affected subnets in a state that is in violation of the formally voted in target IC topology (and in even further violation of the topology that is likely to soon be proposed - 34 nodes instead of 28 on the II subnet)

@SvenF

• There’s only one other Subnet Management proposal proposed by this neuron historically, and it was also worthy of rejection in my opinion (currently that proposal is still open).

---

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)

[Lorimer]

See below thread for further discussion regarding the above:

@Lorimer

Thanks @MalithHatananchchige, I really appreciate your reaching out and providing some clarity. This really helps, and I’m glad to see that you’re open to improving processes in the future .

Regarding the removal of the nodes from the subnet, can I ask why this was not a proposal to swap in a good node (so that the subnet topology, in terms of cardinality, is not formally modified)? I’m still of the impression that this proposal should be rejected, and replaced with a ‘Change Subnet Membership’ proposal (as highlighted there are plenty of spare nodes to swap into the network). This would then free up your CM1 nodes so that they can be removed from the wider network and redeployed with IPv4 and IPv6 addresses.

[Lorimer]

There’s currently a new open ‘Change Subnet Membership’ proposal for this subnet.

---

Proposal 132143

TLDR: I’ve rejected this proposal as it does not solve the offline node issue, and the payload parameters appear to contains errors.

• Note that node vwsvq is included in both the nodes removed and nodes added parameters of the payload. Swapping nodes is supposed to be a transactional operation (I wouldn’t be surprised if this would fail to execute).
• The other node swap in this proposal is taking the opportunity to improve subnet decentralisation (given there’s already a need for a proposal). 1 of the two nodes in the USA is proposed to be replaced with one node in Singapore. This increases the country coefficient (… but it was already within the acceptable range, and other subnets are in much more need of decentralisation).

My suggestion would be to reject this proposal and resubmit one that solves the offline node problem, and raise other proposals to address the subnets that are currently violating the target IC topology before looking to improve the topology of subnets that are not formally in need of it (unless it’s a strategic move to help free up nodes that are needed by other subnets - but this should be clearly explained).

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) →

	Smallest Distance	Average Distance	Largest Distance
EXISTING	3.534 km	7115.008 km	16955.201 km
PROPOSED	3.534 km	6874.501 km (-3.4%)	16955.201 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	4	10	13	13	13
PROPOSED	4	11 (+9.1%)	13	13	13

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	5	2	1	1	1
PROPOSED	6 (+20%)	2	1	1	1

See here for acceptable limits → Motion 125549 (note that these are due for a slight revision)

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

	Continent	Country	Data Center	Owner	Node Provider	Node	Status
---	Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae	DOWN
---	Americas	United States of America (the)	Dallas (dl1)	Flexential	87m Neuron, LLC	ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe	UP
+++	Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae	DOWN
+++	Asia	Singapore	Singapore 3 (sg3)	Racks Central	OneSixtyTwo Digital Capital	t6ads-xnmvp-nwrkg-vytby-wrqj7-5ddqe-h5a7h-jjmpa-snv7j-3pqqz-iae	UNASSIGNED
	Europe	Switzerland	Geneva (ge1)	HighDC	Archery Blockchain SCSp	tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae	UP
	Europe	Switzerland	Zurich 4 (zh4)	Nine.Ch	Tomahawk.vc	jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae	UP
	Asia	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	zppi4-egu2x-ylkfm-fttld-d5v43-wq7zs-hnszi-6plxh-6ol3h-ibceq-xae	UP
	Asia	India	Panvel 2 (pl2)	Yotta	Krishna Enterprises	srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe	UP
	Asia	Japan	Tokyo 3 (ty3)	Equinix	Starbase	oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe	UP
	Asia	Korea (the Republic of)	Seoul 2 (kr2)	Gasan	Web3game	pzv3b-av4if-exyju-qfmed-zbeez-2xlcd-sj22c-zdhus-gnwmo-7cbse-aqe	UP
	Europe	Romania	Bucharest (bu1)	M247	Iancu Aurel	bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe	UP
	Europe	Slovenia	Ljubljana (lj1)	Posita.si	Fractal Labs AG	wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe	UP
	Europe	Sweden	Stockholm 1 (sh1)	Digital Realty	DFINITY Operations SA	zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe	UP
	Americas	United States of America (the)	Fremont (fm1)	Hurricane Electric	1G	bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe	UP
	Africa	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Honeycomb Capital (Pty) Ltd	ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae	UP

---

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)

[Lorimer]

Proposal 132180

TLDR: I’ve adopted this proposal. Two dead nodes replaced with two up nodes This also has the side-effect of a slight increase in decentralisation in terms of average geographic distance between nodes and country diversity

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) →

	Smallest Distance	Average Distance	Largest Distance
EXISTING	3.534 km	7115.008 km	16955.201 km
PROPOSED	3.534 km	7231.464 km (+1.6%)	16955.201 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	4	10	13	13	13
PROPOSED	4	11 (+9.1%)	13	13	13

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	5	2	1	1	1
PROPOSED	6 (+20%)	2	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

	Continent	Country	Data Center	Owner	Node Provider	Node	Status
---	Asia	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	zppi4-egu2x-ylkfm-fttld-d5v43-wq7zs-hnszi-6plxh-6ol3h-ibceq-xae	DOWN
---	Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	vwsvq-sp3z5-kjy66-srr2f-esws7-mzchn-oeqdb-n3qvz-wrzni-4pcsy-lae	DOWN
+++	Asia	China	HongKong 1 (hk1)	Unicom	Wancloud limited	fpjx3-tfebc-csio2-hxi4u-7jomj-p4c4q-b66xe-ngut6-yi63x-keuhl-6ae	UNASSIGNED
+++	Europe	Spain	Barcelona 1 (es1)	Adam	Carbon Twelve	uao44-6xaz7-xmjyv-wxzqn-fawuf-hpz34-d7ea4-2ft3d-znzye-k246e-cqe	UNASSIGNED
	Europe	Switzerland	Geneva (ge1)	HighDC	Archery Blockchain SCSp	tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae	UP
	Europe	Switzerland	Zurich 4 (zh4)	Nine.Ch	Tomahawk.vc	jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae	UP
	Asia	India	Panvel 2 (pl2)	Yotta	Krishna Enterprises	srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe	UP
	Asia	Japan	Tokyo 3 (ty3)	Equinix	Starbase	oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe	UP
	Asia	Korea (the Republic of)	Seoul 2 (kr2)	Gasan	Web3game	pzv3b-av4if-exyju-qfmed-zbeez-2xlcd-sj22c-zdhus-gnwmo-7cbse-aqe	UP
	Europe	Romania	Bucharest (bu1)	M247	Iancu Aurel	bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe	UP
	Europe	Slovenia	Ljubljana (lj1)	Posita.si	Fractal Labs AG	wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe	UP
	Europe	Sweden	Stockholm 1 (sh1)	Digital Realty	DFINITY Operations SA	zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe	UP
	Americas	United States of America (the)	Dallas (dl1)	Flexential	87m Neuron, LLC	ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe	UP
	Americas	United States of America (the)	Fremont (fm1)	Hurricane Electric	1G	bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe	UP
	Africa	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Honeycomb Capital (Pty) Ltd	ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae	UP

---

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)

[dsharifi]

DFINITY will submit an NNS proposal today to reduce the notarization delay on the subnet, 5kdm2, similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread).

[ZackDS]

Voted to adopt proposal 133072. The initial_notary_delay_millis is set to 300 and the subnet_id is correct.

[timk11]

Voted to adopt proposal 134038, as the reasoning is sound and the proposal description matches the payload.

This proposal is intended to replace a dead node, pzv3b, which node appears as “Status: Offline” on the dashboard. As seen in the proposal (which I verified using the DRE tool), the proposed change leaves the target topology within the requirements and improves decentralisation with respect to country.

[Lorimer]

Proposal 134038

TLDR: I’ve adopted this proposal. An offline node in South Korea and a US node that’s currently up replaced with unassigned nodes in Singapore and Belgium. Note that although the US node is currently up, the proposal replaces it to improve decentralisation metrics.

---

Initially it appeared to me that the country coefficient is not improved as suggested by the proposal. The map and stats below are based on IP address geolocation that I now release is inconsistent with what the IC has on record for this node. The node appeared to me to be in Canada, but on further investigation just now I see that the true location is more likely to be the US.

• ip-api.com places it in the US
• api.ip2location.io places it in Canada
• domain WHOIS lookup places it in the US
• IC records consider this node to be in the US

Assuming the node is located in the US (and not Canada), then I agree that decentralisation is improved by this proposal in terms of country limits. I’ll look into improving my tooling when I get a chance.

@sat, @SvenF, are you aware of any plans to implement a means of IC protocol + device level geolocation, to help verify the current location of a node (rather than trusting a third party service)?

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) →

	Smallest Distance	Average Distance	Largest Distance
EXISTING	0 km	7116.246 km	14698.952 km
PROPOSED	0 km	6519.78 km (-8.4%)	15062.77 km (+2.5%)

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	Node Operator
EXISTING	4	12	13	13	13	13
PROPOSED	4	12	13	13	13	13

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

	Continent	Country	Data Center	Owner	Node Provider	Node Operator
EXISTING	6	2	1	1	1	1
PROPOSED	7 (+16.67%)	2	1	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

	Continent	Country	Data Center	Owner	Node Provider	Node Operator	Node	Status	Performance
---	Asia	Korea (the Republic of)	Seoul 2 (kr2)	Gasan	Web3game	5dwhe	pzv3b-av4if-exyju-qfmed-zbeez-2xlcd-sj22c-zdhus-gnwmo-7cbse-aqe	DOWN
---	Americas	United States of America (the)	Dallas (dl1)	Flexential	87m Neuron, LLC	sambh	ugqji-f7rfx-mbubv-44r5n-zfi3k-7ag32-qhkal-xmmyu-5fbot-r6azo-aqe	UP
+++	Europe	Belgium	Seoul 3 (kr1)	KT	Pindar Technology Limited	iubpe	ttjeo-6vece-x2hpb-lzmdg-b2fwl-7osa4-r5vb6-n4dyc-ocg5r-rztx2-eqe	UNASSIGNED
+++	Asia	Singapore	Singapore (sg1)	Telin	OneSixtyTwo Digital Capital	d4bin	ihoip-fmbnl-mm4fa-pu7hu-2sbx2-mzl2f-tgzje-unnjg-bgcac-3apmo-gqe	UNASSIGNED
	Americas	Canada	Fremont (fm1)	Hurricane Electric	1G	mlh5i	bmlxd-vohad-ymfvi-hm7id-7g3vp-236w4-n3cqd-tkwgf-wlrww-lqbcr-gqe	UP
	Europe	Switzerland	Geneva (ge1)	HighDC	Archery Blockchain SCSp	yngfj	tybza-gyple-63wq2-qsgwo-w6fqw-6trwu-awukb-skekh-67bqu-qsoeo-aae	UP
	Europe	Switzerland	Zurich 4 (zh4)	Nine.Ch	Tomahawk.vc	paxme	jtvnx-kem2o-icln6-b4oy6-n5ru5-dmksj-dfk5i-4ejvq-k3unp-47gjb-mae	UP
	Asia	China	HongKong 1 (hk1)	Unicom	Wancloud limited	z6cfb	fpjx3-tfebc-csio2-hxi4u-7jomj-p4c4q-b66xe-ngut6-yi63x-keuhl-6ae	UP
	Europe	Spain	Barcelona 1 (es1)	Adam	Carbon Twelve	gyzti	uao44-6xaz7-xmjyv-wxzqn-fawuf-hpz34-d7ea4-2ft3d-znzye-k246e-cqe	UP
	Asia	India	Panvel 2 (pl2)	Yotta	Krishna Enterprises	7rw6b	srgrm-5pwg2-225hn-fxwdd-zphpu-wwxgu-uxako-avmlx-epw7e-zwkhf-sqe	UP
	Asia	Japan	Tokyo 3 (ty3)	Equinix	Starbase	a5glg	oswv7-a355p-a5jlp-ko7pj-arrs2-rghho-dti4z-xgptn-szn55-jjr46-uqe	UP
	Europe	Romania	Bucharest (bu1)	M247	Iancu Aurel	c5ssg	bjhao-hlctl-g24ce-7hfcg-mqxbw-yxhyq-q23mj-smxsk-4o2s4-u353p-zqe	UP
	Europe	Slovenia	Ljubljana (lj1)	Posita.si	Fractal Labs AG	gl27f	wq5v7-ngito-7ztqs-zlf2v-ibk6f-e54em-t3hou-x24kz-v5j77-6vo72-kqe	UP
	Europe	Sweden	Stockholm 1 (sh1)	Digital Realty	DFINITY Operations SA	lgp6d	zos66-lmcn7-satbv-gcdzj-q3cdf-4n6zc-2hlei-gc453-uoh7r-4sj3w-vqe	UP
	Africa	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Honeycomb Capital (Pty) Ltd	3bohy	ocvcv-56eg5-gxibh-dcgpo-unhwq-4bwmo-x7q3h-stwf2-ycfex-gdr2a-kae	UP

---

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.

Another good neuron to follow is Synapse (follows the LORIMER and CodeGov known neurons for Subnet Management, and is a generally well informed known neuron to follow on numerous other topics)

[sat]

@Lorimer

are you aware of any plans to implement a means of IC protocol + device level geolocation, to help verify the current location of a node

Sounds like you already have some specific approach in mind @Lorimer ?
There is an ongoing activity to start showing geoip info, but we first have to make sure geoip info is actually reliable.

[SvenF]

@Lorimer

The map and stats below are based on IP address geolocation that I now release is inconsistent with what the IC has on record for this node.

Hey @Lorimer I also see different geo locations using different ip lookup tools, will ask the networking people have a look at it. The node is indeed in the US, and like @sat indicates, there is an ongoing activity for a geo-lookup using triangulation.

[Lorimer]

@sat

Sounds like you already have some specific approach in mind @Lorimer ?

No concrete idea - I can’t think of something that couldn’t be spoofed. But I’ve not spent any great deal of time considering this.

Perhaps it would be more practical to mandate that nodes use ISPs that allow for better public IP address precision and accuracy?

@SvenF

will ask the networking people have a look at it. The node is indeed in the US, and like @sat indicates, there is an ongoing activity for a geo-lookup using triangulation.

Sounds good, thanks. I’d be interested to follow progress on that idea. Is there a public thread anywhere yet to follow it?

[LaCosta]

Voted to adopt proposal 134038. The proposal replaces two nodes from subnet 5kdm2:
Removed Nodes:

• pzv3b, Dashboard Status Offline
• ugqji, Dashboard Status Online, replacement improves decentralization on the Country metric (reduces number of nodes in the US from 2 to 1)

Added Nodes: ihoip and ttjeo.
The proposal was verified using the DRE tool to verify the metrics stated and that they were in line with the target topology requirements.

[ZackDS]

Voted to adopt proposal #134038.

The proposal is correct in that it replaces offline dead node from Seoul2 pzv3b , and healthy Dallas node ugqji to improve decentralization.
The added nodes are from Singapore ihoip along with ttjeo from Seoul3.

[SvenF]

@Lorimer

Sounds good, thanks. I’d be interested to follow progress on that idea. Is there a public thread anywhere yet to follow it?

Hi @Lorimer not yet, this topic was actually discussed in the Technical Working Group for Node Providers and is being started up. Will make sure that a thread is added shortly on this.

[SvenF]

@Lorimer

The node appeared to me to be in Canada, but on further investigation just now I see that the true location is more likely to be the US.

Hi @Lorimer the networking team has taken a look into it, and from what they can see, the IPs are part of the 2001:470::/32 AS6939, which is registered in ARIN in US.

On the other hand, ip2location.io appears to have Canada in its database which might be an old registration. Maybe before the prefix 2001:470:1::/48 was actually in Canada. We dropped a note to the provider. IPv6 data coverage is typically less mature than IPv4 data so geolocation providers may lack complete accuracy here. All the more reason to work on triangulation as discussed above!

[Lorimer]

Thanks a lot for following up on this @SvenF, and for the extra info. I’m looking forward to hearing more about the planned path forward. Sounds promising