Technically, this proposal meets the usual criteria.
However, it references the same documentation used for a prior proposal to add a node provider, so the fact it meets this criteria is to be expected.
I am voting to reject this proposal because, while not explicitly outlined in any guidelines, I believe there should be a one-to-one relationship between an NP self-declaration and the node provider ID.
Allowing a new NP to be added to the NNS with the same self-declaration effectively enables the same entity to have multiple NP principals.
The consequence is that, despite being the same entity, having multiple principals would allow said entity to operate more than 42 nodes, circumventing the node cap.
To avoid setting a precedent for this, I vote to reject the proposal.
This proposal does not meet the criteria, specifically the requirement that self-declaration documents must be posted on the IC Wiki.
Initially, I would have voted to accept if the documents were uploaded to the IC Wiki toward the end of the voting period. However, the provided links do not currently point to the IC Wiki at all.
To maintain consistency and ensure long-term accessibility, a new proposal is necessary. If this proposal is referenced later, the proposer’s external links may no longer be available, which could lead to issues (not suggesting this is intentional, but it must be considered).
Recommendation:
@yannick.endrion Kindly wait until your self-declaration documents are visible on the IC Wiki and have been approved by moderators.
To avoid similar mistakes in the future, this goes for other prospective node providers, I highly recommend using proposals.network to submit your proposal. This platform:
Ensures all required fields are included.
Validates that links provided point to the correct Forum and Wiki locations.
Confirms the proper hash format is used.
This cool project was developed by @peterparker! He helped me add this specific proposal type to the platform as we saw that a lot of mistakes can be made with this initial proposal. Let me if you would like to see other NP related proposal types to get added
Hey @ZackDS , thanks for pointing that out - you’re right!
My suggestion is to use another command - propose-to-update-node-operator-config so that the node allowance can be added to the same NO record in the same DC.
$ NODE_PROVIDER_PRINCIPAL=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
$ NODE_OPERATOR_PRINCIPAL=xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxxxx-xxx
$ NODE_PROVIDER_NAME="My Company"
$ NEW_NODE_ALLOWANCE=5
$ DC_ID=xx
$ FORUM_POST_URL=https://forum.dfinity.org/...
$ ./ic-admin \
--nns-url https://ic0.app \
-s ~/.config/dfx/identity/node-provider-hotkey/identity.pem \
propose-to-update-node-operator-config \
--node-provider-id $NODE_PROVIDER_PRINCIPAL \
--node-operator-id $NODE_OPERATOR_PRINCIPAL \
--summary "Node provider '$NODE_PROVIDER_NAME' is adjusting the node allowance $NODE_ALLOWANCE to nodes in the $DC_ID data center. Link to the forum post for: $FORUM_POST_URL" \
--proposer $NEURON_ID \
$NEW_NODE_ALLOWANCE
This should be the command that is run in IC-admin. Like you pointed out, the NEW_NODE_ALLOWANCE is the number of nodes you will add. So in @bitmoon 's case, this field should = 1. More info can be found here.
@sat@SvenF please confirm incase I am misinterpreting.
Vote: REJECT Review:
After discussing this with Louise, I agree with his reasoning and vote to REJECT. Maintaining a one-to-one relationship between NP self-declaration and node provider ID is crucial to prevent any circumvention of the node cap.
The required self-declaration documents have not been posted on the IC Wiki. While the documents are available via external links, maintaining consistency and long-term accessibility requires that they be uploaded to the IC Wiki. This ensures proper referencing in the future, as external links may become inaccessible.
To align with best practices, a new proposal should be submitted once the documents are appropriately hosted on the IC Wiki.
Hi Philip @Protocol16 can you clarify why a second Node Provider proposal is submitted, as the community rightly points out that a previous node provider proposal is already approved and registered under Protocol 16. Also, please note that currently there are no new node machines being onboarded (see this wiki message here) and even after the onboarding of new node machines is possible again, adding additional node machines in Singapore probably will not help the decentralization of the IC.
Appreciate if you could clarify the background of your proposal further in this forum thread.
This proposal reuses documentation from a prior accepted proposal to add a node provider, here.
I am rejecting this proposal because the NP self-declaration has the purpose the identify the ultimate owner of the nodes. Allowing the same self-declaration to support multiple NP principals enables an entity to circumvent the 42-node cap by operating under different IDs.
To safeguard the integrity of the node cap, I vote to reject this proposal.
@yannick.endrion I took the liberty of adding all your documents under a new wiki link, in line with the other proposals. @quint@louisevelayo please indicate whether you see any other reasons for rejecting this proposal.
@yannick.endrion please note that currently there are no new node machines being onboarded (see this wiki message here) and you message indicates your intention to immediately onboard a node machine in Lausanne. This will not be possible as target topology is reached, so proposals to onboard nodes machines will for now not be approved.
Hi @louisevelayo@bitmoon yes node_allowance is the number of additional nodes that can be onboarded, it is not the total node allowance. So it should be set to 1.
Thank you @SvenF .
Too bad… Hopefully I didn’t yet validated the order of hardware. Have you any vision on when new nodes may be joining ? based on current usage if you have this kind of information on your side.
If you want to continue decentralizing, please ping me, would be glad to help.
Thanks
Hi @yannick.endrion whether new nodes can be onboarded really depends on how quickly the IC grows, and of course when the community decides that this requires additional node machines. So it’s difficult to predict. Currently, there are a large number of spare nodes with which additional application subnets are being created. Once these are fully used, it seems logical that new nodes need to be onboarded to create new subnets.
Your node proposal by the way can still be approved, pending onboarding of any new nodes once that is possible again. You can see in this forum thread that several other node providers have done the same, i.e. submitting a node provider proposal but not onboarding any nodes, in order to be ready to onboard node machines once that is allowed/required.
Hi all, my apologies for the confusion. Proposal 134358 was submitted in error—please reject it. I was trying to address the name mismatch flagged previously but realized this proposal might cause additional confusion.
Vote: ADOPT Reason to adopt: following the addition of the self-declaration documents to the wiki here, the proposal satisfies all necessary review criteria. It is worth noting having these documents posted on the forum before submitting the proposal is advised as others probably won’t step in every time to add these during the proposal voting period. Thanks Sven for doing so!
Review: Forum introduction was posted here. Self-declaration and identity documents were posted here, thanks @SvenF for moving them there. The entity was found in an official registry here. The hashes of the documents match the hashes in the proposal: checked with Appdevtools’ Checksum Calculator and proof below:
Hi @SvenF , thanks for moving the documents to the right part of the wiki!
I would still vote to reject this proposal. The primary reason is that, despite the discussions on the Forum, the proposal itself must include accurate and complete information, as the NNS serves as the definitive source of truth for the community.
While linking to a Forum discussion allows for further verification, setting a precedent where proposals with incorrect or incomplete information are submitted, later corrected, but still adopted with inaccuracies introduces inconsistencies in the NNS records. This undermines the reliability and integrity of the information presented on the NNS.
I understand that the process may not be straightforward, but several proposals in the past have successfully followed the correct procedure. I believe we should aim to maintain this standard.
That said, this is my personal view on this matter - I am just one of three reviewers for the Aviate Labs Neuron, which is only one of many Neurons the community can follow. If the broader community sees no issue with this approach, then I suppose it will proceed.
I think it’s a good point, the NNS and thus proposals should be the single source of truth.
In this case, I’m able to verify the documents as long as we trust the external hosting site “e-y.io” to stay online, which we shouldn’t.
This raises the questions:
is the current wiki hosted on the Internet Computer?
would it be possible to directly store these proofs in a proposal?
Voted to reject proposal 134358. As pointed out allowing the same self-declaration on multiple NP principals allows the owner to not follow the 42 node cap. Also the @Protocol16 as come forward asking for the rejection of the proposal.
Forum introduction was posted 
