This topic is intended to capture Subnet Management activities over time for the brlsh 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:
DFINITY will submit a proposal today to reduce the notarization delay on the subnet, brlsh, similar to what has happened on other subnets in recent weeks (you can find all details in this forum thread ).
Thanks @dsharifi! Looks good, and the URL link has been super useful for jumping from the proposal, to the forum, and then from the forum to the subnet dashboard
Voted to adopt proposal 134041, as the reasoning is sound and the proposal description matches the payload.
This proposal is intended to replace one node with another, in order to gain insights into the stability of nodes of the node operator of the new node, given that this node operator does not yet have nodes in any subnet. As seen in the proposal (which I verified using the DRE tool), the proposed change leaves the target topology parameters unchanged and within the requirements.
TLDR I’ve vote to adopt. The proposal summary appears to be accurate, and the change seems reasonable.
… a node operator 5njak currently does not have nodes in any subnet. To get insights into the stability of the nodes of this node operator, we propose to add one of the operator’s nodes to subnet brlsh
Claims made in the proposal summary can be validated via the IC API. Reviewing the returned JSON shows that the node operator 5njak operates a single node, which is indeed currently unassigned.
An UP node in the US is removed and replaced with this new US 5njak node. Relevant decentralisation metrics are unaffected by this change.
Decentralisation Stats
Subnet node distance stats (distance between any 2 nodes in the subnet) →
Smallest Distance
Average Distance
Largest Distance
EXISTING
443.007 km
7099.094 km
15062.77 km
PROPOSED
443.007 km
7124.993 km (+0.4%)
15939.092 km (+5.8%)
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
3
12
13
13
13
13
PROPOSED
3
12
13
13
13
13
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)
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)
Voted to adopt proposal 134041. The proposal replaces one node from subnet brlsh:
Removed Node: icbco, Added Node: qjcai.
The proposal was verified using the DRE tool to verify the metrics stated and there was no impact on decentralization. The motivation behind this proposal is to get insights into the stability of the nodes under the node operator 5njak. Using the ic-admin tool as follows:
I was able to verify the node_provider_principal_id, chnsu, which matches with the one from the proposal and currently has only the node added under it’s control.
The proposal makes sense in that it replaces one healthy node from Atlanta 2, US icbco , with Atlanta, US node poyg5 while not afecting decentralization in order “To get insights into the stability of the nodes of this node operator”. brlsh has a State of 61.19 GiB with 32,510 Canisters so it should be a good choice.
Voted to adopt proposal 134274. The proposal seeks to remove 2 cordoned nodes from the subnet and specifies that the associated data centre is being offboarded “after 48 months”. Decentralisation parameters are improved with respect to country. The necessary context is provided by this forum post and associated discussion. For future proposals of this type I recommend that the background context be included in the proposal text for ease of verification.
Voted to adopt proposal 134274. This proposal is part of a sequence of steps to remove cordoned nodes from subnets as the associated data centeres are being offboarded after 48 months of their respective DC contracts that are still private and were signed up before the Genesis. There is a great and detailed explanation of this changes in this forum post and the forum thread it is in. In the wiki there is a series of Steps for Gen-1 Node onboarding after 48 months that need to be followed in order for the nodes to continue earning rewards which starts by making a forum post in the following thread. As we can verify no one as come forward with nodes from the DCs in this proposals so I don’t see any issues with the removal of this nodes.
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.
The proposal replaces two cordoned healthy Active status node ciujb from the ZH5 Data Center in Zurich 5, Switzerland and cordoned healthy Active status node mxan5 from the AN1 Data Center in Belgium, with unassigned healthy Awaiting status node pvo54 from Zurich6 and with unassigned healthy Awaiting status node kdldi from Brussels, without any 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.
This proposal replaces 2 nodes, due to offboarding ZH5 and AN1 data centres. Decentralisation parameters are unchanged and remain within the requirements of the target topology. Data centre details are consistent with the links provided in the proposal.
Replaces cordoned nodes ciujb and mxan5 with nodes pvo54 and kdldi on subnet brlsh.
The reason for this proposal is to offboard ZH5 and AN1 DCs 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 and DC stated in the forum post match the ones from the node being removed in the proposal.
Voted to reject proposal 134566 as this is part of a large batch of non-critical proposals timed such that the voting period clashes with national holidays, thereby allowing insufficient time for an appropriately detailed review to take place.
can be validated via the 
