Subnet Management - uzr34 (II)

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)
  • 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)
2 Likes