TLDR: I’ll adopt. Relevant decentralisation stats are unchanged, and there is a clear public declaration for each cordoned node (though one was missing from the proposal summary).
5 nodes removed due to cordoning, replaced with unassigned nodes in Switzerland, Belgium, Japan, Canada and Singapore. However, for one (in bold below) of the 5 removed nodes there is no reference to discussion/declaration by the NP, one with a clear reference that describes the DC in question as due for offboarding (MR1).
Motivation: The following nodes in subnet x33ed have been cordoned and need to be removed from the subnet:
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
0 km
7294.297 km
18505.029 km
PROPOSED
0 km
7359.621 km (+0.9%)
18505.029 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
Node Operator
EXISTING
5
26
34
34
34
34
PROPOSED
5
26
34
34
34
34
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
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)
*This comment references the latest comment in the Subnet Management - General Discussion thread only to generate an automated cross-link from the general thread (to improve topic navigation).
You may wish to follow D-QUORUM if you found this analysis helpful.
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.
Additional good neurons to follow:
D-QUORUM (a highly decentralized neuron that follows neurons that have been elected by the NNS)
Synapse (currently follows the LORIMER and CodeGov known neurons for Subnet Management, and is a generally well informed known neuron to follow on numerous other topics)
CodeGov (actively reviews and votes on Subnet Management proposals, and is well informed on numerous other technical topics)
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
Note that this analysis involved data provided by the IC-API, which is not open source. I’m in the process of switching over to more verifiable sources of this sort of information for future proposal reviews. See here for related discussion.
This proposal replaces 5 nodes for the stated reason of offboarding data centres TO1, MR1, AN1, SG3 and TY2 after 48 months. This matches the details given in the linked posts, although I note that the linked post for data centre MR1 does not clearly specify which data centre is involved. The details of nodes to be removed match details shown in the IC dashboard page for this subnet. As shown in the proposal, decentralisation parameters are unchanged or effectively balanced out (one country goes from 2 nodes to 3 and another from 2 nodes to 1) and remain within the requirements of the target topology.
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Reason:
The proposal replaces five cordoned nodes as follows :
healthy Active status node a2lx7 from the TO1 Data Center in Toronto,
healthy Active status node pe2iu from the MR1 Data Center in Marseille,
healthy Active status node tlv7f from the AN1 Data Center in Antwerp,
healthy Active status node xrhqb from the SG3 Data Center in Singapore,
healthy Active status node xyww7 from the TY2 Data Center in Tokyo,
with unassigned healthy Awaiting status node y7vmg from Zurich,
unassigned healthy Awaiting status node xnraq from Brussels,
unassigned healthy Awaiting status node qnn43 from Tokyo1,
unassigned healthy Awaiting status node m6pbx from Vancouver,
unassigned healthy Awaiting status node i5xgw from Singapore2,
with slight worsening change to the decentralization of the subnet.
The motivation makes sense and the provided Forum link included in the summary provides further info, also it can be checked here.
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Motivation:
The node operator gsps3 (under NP eipr5) has 11 nodes in total but currently does not have active nodes in any subnet. To gain insights into the stability of the nodes of this node operator, we propose to add one of the operator’s nodes to subnet x33ed.
Decentralization Nakamoto coefficient changes for subnet x33ed-h457x-bsgyx-oqxqf-6pzwv-wkhzr-rm2j3-npodi-purzm-n66cg-gae:
Motivation: The node operator mw64v (under NP eipr5) has 22 nodes in total but currently does not have active nodes in any subnet. To gain insights into the stability of the nodes of this node operator, we propose to add one of the operator’s nodes to subnet uzr34.
Decentralization Nakamoto coefficient changes for subnet uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe:
Motivation: The node operator tisgk (under NP 6r5lw) has 14 nodes in total but currently does not have active nodes in any subnet. To gain insights into the stability of the nodes of this node operator, we propose to add one of the operator’s nodes to subnet csyj4.
Decentralization Nakamoto coefficient changes for subnet csyj4-zmann-ys6ge-3kzi6-onexi-obayx-2fvak-zersm-euci4-6pslt-lae:
This proposal replaces node mzcnj which appears in the dashboard as “Status: Active”, for the purpose of examining the stability of another node operator’s nodes. As shown in the proposal, community-approved decentralisation parameters are unchanged and remain within the requirements of the target topology.
About CodeGov…
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralisation of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
@dmanu Your posts above for proposals 134973 and 134974 have been posted in the wrong thread. Please see the corresponding subnet management threads for my reviews.
TLDR: Decentralisation stats are slightly improved. The proposal summary is slightly inaccurate, in that the node operator gsps3 has 10 unassigned nodes (not 11). The 11th node is a boundary node, and it is currently assigned to a subnet. In any case, all of the node operator’s 10 Replica nodes are unassigned. This can be verified by performing a quick text search on the JSON returned here.
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
1.636 km
7501.344 km
19325.937 km
PROPOSED
104.032 km (+6258.9%)
7749.871 km (+3.3%)
19325.937 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
Node Operator
EXISTING
6
25
34
34
34
34
PROPOSED
6
25
34
34
34
34
Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →
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)
Black dotted line connects to a small black marker that shows where the IP address indicates the node is located (according to api.ip2location.io). This is only displayed if it conflicts with where IC records indicate the node is located. See Country Discrepancies section above for more info.
*This comment references the latest comment in the Subnet Management - General Discussion thread only to generate an automated cross-link from the general thread (to improve topic navigation).
You may wish to follow D-QUORUM if you found this analysis helpful.
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.
Additional good neurons to follow:
D-QUORUM (a highly decentralized neuron that follows neurons that have been elected by the NNS)
Synapse (currently follows the LORIMER and CodeGov known neurons for Subnet Management, and is a generally well informed known neuron to follow on numerous other topics)
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
Note that this analysis involved data provided by the IC-API, which is not open source. I’m in the process of switching over to more verifiable sources of this sort of information for future proposal reviews. See here for related discussion.
Vote: Adopted Reason:
The proposal replaces healthy Active status node mzcnj from Zurich4, with
unassigned healthy Awaiting status node oh5wh from Las Vegas, with slight improvement to the decentralization of the subnet.
The motivation is to gain insights into the stability of the nodes of this node operator.
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
The proposal replaces node mzcnj, Dashboard Status: Active, with node oh5wh, Dashboard Status: Awaiting.
The intent is to gain insights into the stability of the nodes from Node Operator gsps3 with currently no active nodes.
About CodeGov…
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
This proposal replaces node jfryc which appears in the dashboard as “Status: Active” for the stated reason “offboarding the second rack of nodes in the mb1 DC after 48 months”. As shown in the proposal, decentralisation parameters are unchanged and remain within the requirements of the target topology.
About CodeGov…
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralisation of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
Replaces cordoned node jfryc with node vcl5k on subnet x33ed.
The reason for this proposal is to offboard the second rack of nodes from the MB1 DC consistent with forum posts made on the forum thread used for posts regarding the renovation/sell of Gen-1 node machines by NPs.
Both the NP, DC and Node stated in the forum post match the ones from the node being removed in the proposal.
About CodeGov…
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
TLDR: Decentralisation stats are unchanged and there is a clear public declaration for the cordoned node which is referred to in the proposal summary. 1 cordoned node replaced with another node belonging to the same NP at the same data centre.
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)
Black dotted line connects to a small black marker that shows where the IP address indicates the node is located (according to api.ip2location.io). This is only displayed if it conflicts with where IC records indicate the node is located. See Country Discrepancies section above for more info.
*This comment references the latest comment in the Subnet Management - General Discussion thread only to generate an automated cross-link from the general thread (to improve topic navigation).
You may wish to follow D-QUORUM if you found this analysis helpful.
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.
Additional good neurons to follow:
D-QUORUM (a highly decentralized neuron that follows neurons that have been elected by the NNS)
Synapse (currently follows the LORIMER and CodeGov known neurons for Subnet Management, and is a generally well informed known neuron to follow on numerous other topics)
WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)
Note that this analysis involved data provided by the IC-API, which is not open source. I’m in the process of switching over to more verifiable sources of this sort of information for future proposal reviews. See here for related discussion.
Vote: Adopted Reason:
The proposal replaces cordoned healthy Active status node jfryc from the MB1 DC in Slovenia, with unassigned healthy Awaiting status node vcl5k from same DC and NP, without any change to decentralization.
Motivation is offboarding the second rack of nodes in the MB1 DC after 48 months, in line with the forum post.
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
