The proposal adds a new node operator ID for node provider Starbase. The node provider ID and data centre ID given in the proposal match the information for data centre TY1 in the dashboard. The document hashes given in the Wiki match the documents. The addition of the new node operator ID is consistent with the processes outlined in the current thread for reconfiguring existing Gen-1 nodes under the new remuneration structure. The current nodes for this NP in data centres TY1 and TY3 total 41, consistent with the agreed maximum of 42 and the statement of intent here.
Add 28 nodes, (migrating to the HSM-less deployment method)
The DC ID matches.
Starbase, NP ID sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae.
Previous NO ID (cqjev-4qb7l-xv373-jfmhi-73n3a-cxhst-p6okb-vywwc-a4zbi-6sf3u-bae) associated with this data center shows 28 "type1" nodes, matching the allowance proposed in this proposal.
Vote: ADOPT Review
This proposal seeks to add 28 nodes to a data center as part of the migration to the HSM-less deployment method. Once these nodes are onboarded, the old record will be deprecated, maintaining alignment with the IC target topology.
Key points of validation:
DC ID: The data center ID in the proposal is consistent with what is shown on the dashboard: ty1
Node Provider: The data center TY1 hosts nodes for the provider Starbase, with NP ID: sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae.
Previous Node Operator: The associated NO ID cqjev-4qb7l-xv373-jfmhi-73n3a-cxhst-p6okb-vywwc-a4zbi-6sf3u-bae shows 28 nodes, matching the count proposed. (check NO ID)
Node Type: The old NO ID also verifies these as Gen-1 nodes, noted as "type1": 28. This is consistent with motion proposal 132553, which governs the remuneration framework for Gen-1 nodes after 48 months.
Though this proposal appears to add 14 nodes, the proposer clarified that this is necessary for migrating to the HSM-less deployment method. They also committed to deprecating the old record once the nodes in this data center have been onboarded, keeping this aligned with the IC target topology.
The DC ID in the proposal matches what is displayed on the dashboard.
This data center also hosts nodes for the node provider Starbase, with the node provider ID sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae.
The previous Node Operator ID (a5glg-n6ul6-rkuc7-idthk-fb2fe-d5m75-4g4l7-22yko-h27pr-q3a7k-lae) associated with this data center shows 14 nodes, matching the allowance proposed in this proposal.
The old NO ID also verifies that these are Gen-1 nodes as indicated by the "type1": 14 in the image above, meaning that they are in line with motion proposal 132553 for node rewards after 48 months.
Add 14 nodes, (migrating to the HSM-less deployment method)
The DC ID matches.
Starbase, NP ID sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae.
Previous NO ID (a5glg-n6ul6-rkuc7-idthk-fb2fe-d5m75-4g4l7-22yko-h27pr-q3a7k-lae) associated with this data center shows 14 "type1" nodes, matching the allowance proposed in this proposal.
There is reference to this forum post and the proposal is in line with the declaration and statement of 87M as well as of Uvaca. The request for cordoning is based on redeploying all existing (non excess) nodes of 87M without HSM, for which new Node Operator records have been created in proposals 134506 and 134507 with reference to the previous forum post.
Other node providers like Starbase have prepared similar NO proposals submitted for HSM less deployment of there existing nodes (see 134534)
There is reference in the original proposals 134505 and 134507 to the original forum post in the New NP Proposal thread if that is what you mean, similar to what e.g. Starbase has done, and as @ZackDS referenced in his review post.
You referenced my rejection of proposal 134619, but you’re referring to other proposals now. The proposal in question (the one I rejected) was submitted without a reference to a forum post by the NP to backup the claims in the proposal. You previously agreed that this is how things should be done.
The proposal adds a new node operator ID for node provider Starbase. The node provider ID and data centre ID given in the proposal match the information for data centre TY3 in the dashboard. The addition of the new node operator ID is consistent with the processes outlined in the current thread for reconfiguring existing Gen-1 nodes under the new remuneration structure. The current nodes for this NP in data centres TY1 and TY3 total 41, consistent with the agreed maximum of 42 and the statement of intent here.
The self-declaration and Proof of Identity documents were uploaded on the IC Wiki
The hashes of the Self declaration and Proof of Identity documents match the hashes in the proposal
Currently the NP has a total of 42 Gen-1 nodes, proposal 134534 added a NO with a node_allowance of 28 nodes from ty1 DC and this proposal added a NO with a node_allowance of 14 nodes from ty3 matching the maximum of 42 Gen-1 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.
The DC ID ty3 aligns with the information presented on the dashboard.
The data center hosts nodes for the node provider Starbase, with the node provider ID: sixix-2nyqd-t2k2v-vlsyz-dssko-ls4hl-hyij4-y7mdp-ja6cj-nsmpf-yae.
The previous Node Operator ID: a5glg-n6ul6-rkuc7-idthk-fb2fe-d5m75-4g4l7-22yko-h27pr-q3a7k-lae in this data center confirms 14 nodes of “type1”, matching the allowance proposed in the current proposal:
Hi Tim - we have several severs with hardware issues that the aftermarket warranty company has been struggling to diagnose and fix. There is no LT intention to drop any nodes from the network.
Hi Tim, I misunderstood. To clarify, there is no intention to drop the nodes from the network, however, as I am currently doing the HSM less migration, the nodes do need to be removed from the registry in order for me to transfer them to the new NO principal. (See this proposal: 134506 and 134507).
I have already done this for the majority of the nodes as you can see on the dashboard, they now have the new and update NO ID. These remaining ones I must have missed and so I guess DFINITY(?) has submitted this proposal.
Just a heads up that I just removed the following node myself “z6jp6-245uu-gh3cs-sblcy-f3jmj-s4ngl-v3z4u-lafz2-qudjr-6mbqx-vqe” earlier today whilst working with the data center remote hands - not sure if this affects this proposal.
