This topic is intended to act as a place to ask general Subnet Management questions and share answers.
Here are a list of subnet-specific forum topics that capture Subnet Management activities over time for each subnet, providing a place to ask questions and make observations about the management of that particular subnet (I’ll endeavour to keep this list updated as more topics are added).
Hi @andrea, @bitdivine, can I ask if you’re aware of a reliable way of associating a specific historic CreateSubnet proposal with the subnet that it created. Many recent ones include ‘Motivation’ information in the proposal summary that unambiguously reveals the subnet that it refers to. However this isn’t always the case. Here is an example Proposal: 35948 - ICP Dashboard (internetcomputer.org)
Motivation: Increase the capacity of the network
I can think of some heuristic approaches to mapping these historic proposals to the relevant subnet, but I haven’t come up with a reliable approach. Are you aware of information stored anywhere that records the proposal that was used for creating each subnet (defining the config that the subnet started out with)?
By looking inside the registry, it should be possible to determine the registry version at which the subnet was created, and then possibly the time. But maybe @msumme has better ideas on how to do this?
If you have all subnet creation proposals, one thing you could do is to sort them by execution time and then match them with the list of subnets in the registry, which is sorted by creation time. You can obtain this from the registry, e.g. by using ic-admin:
$ ./ic-admin --nns-url https://ic0.app get-subnet-list
Using NNS URLs: ["https://ic0.app/"]
[
"tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe",
"snjp4-xlbw4-mnbog-ddwy6-6ckfd-2w5a2-eipqo-7l436-pxqkh-l6fuv-vae",
"qxesv-zoxpm-vc64m-zxguk-5sj74-35vrb-tbgwg-pcird-5gr26-62oxl-cae",
"pae4o-o6dxf-xki7q-ezclx-znyd6-fnk6w-vkv5z-5lfwh-xym2i-otrrw-fqe",
"4zbus-z2bmt-ilreg-xakz4-6tyre-hsqj4-slb4g-zjwqo-snjcc-iqphi-3qe",
"w4asl-4nmyj-qnr7c-6cqq4-tkwmt-o26di-iupkq-vx4kt-asbrx-jzuxh-4ae",
"io67a-2jmkw-zup3h-snbwi-g6a5n-rm5dn-b6png-lvdpl-nqnto-yih6l-gqe",
"5kdm2-62fc6-fwnja-hutkz-ycsnm-4z33i-woh43-4cenu-ev7mi-gii6t-4ae",
"shefu-t3kr5-t5q3w-mqmdq-jabyv-vyvtf-cyyey-3kmo4-toyln-emubw-4qe",
"ejbmu-grnam-gk6ol-6irwa-htwoj-7ihfl-goimw-hlnvh-abms4-47v2e-zqe",
"eq6en-6jqla-fbu5s-daskr-h6hx2-376n5-iqabl-qgrng-gfqmv-n3yjr-mqe",
"csyj4-zmann-ys6ge-3kzi6-onexi-obayx-2fvak-zersm-euci4-6pslt-lae",
"lspz2-jx4pu-k3e7p-znm7j-q4yum-ork6e-6w4q6-pijwq-znehu-4jabe-kqe",
"lhg73-sax6z-2zank-6oer2-575lz-zgbxx-ptudx-5korm-fy7we-kh4hl-pqe",
"gmq5v-hbozq-uui6y-o55wc-ihop3-562wb-3qspg-nnijg-npqp5-he3cj-3ae",
"pjljw-kztyl-46ud4-ofrj6-nzkhm-3n4nt-wi3jt-ypmav-ijqkt-gjf66-uae",
"brlsh-zidhj-3yy3e-6vqbz-7xnih-xeq2l-as5oc-g32c4-i5pdn-2wwof-oae",
"mpubz-g52jc-grhjo-5oze5-qcj74-sex34-omprz-ivnsm-qvvhr-rfzpv-vae",
"qdvhd-os4o2-zzrdw-xrcv4-gljou-eztdp-bj326-e6jgr-tkhuc-ql6v2-yqe",
"jtdsg-3h6gi-hs7o5-z2soi-43w3z-soyl3-ajnp3-ekni5-sw553-5kw67-nqe",
"k44fs-gm4pv-afozh-rs7zw-cg32n-u7xov-xqyx3-2pw5q-eucnu-cosd4-uqe",
"opn46-zyspe-hhmyp-4zu6u-7sbrh-dok77-m7dch-im62f-vyimr-a3n2c-4ae",
"6pbhf-qzpdk-kuqbr-pklfa-5ehhf-jfjps-zsj6q-57nrl-kzhpd-mu7hc-vae",
"e66qm-3cydn-nkf4i-ml4rb-4ro6o-srm5s-x5hwq-hnprz-3meqp-s7vks-5qe",
"4ecnw-byqwz-dtgss-ua2mh-pfvs7-c3lct-gtf4e-hnu75-j7eek-iifqm-sqe",
"yinp6-35cfo-wgcd2-oc4ty-2kqpf-t4dul-rfk33-fsq3r-mfmua-m2ngh-jqe",
"w4rem-dv5e3-widiz-wbpea-kbttk-mnzfm-tzrc7-svcj3-kbxyb-zamch-hqe",
"cv73p-6v7zi-u67oy-7jc3h-qspsz-g5lrj-4fn7k-xrax3-thek2-sl46v-jae",
"o3ow2-2ipam-6fcjo-3j5vt-fzbge-2g7my-5fz2m-p4o2t-dwlc4-gt2q7-5ae",
"fuqsr-in2lc-zbcjj-ydmcw-pzq7h-4xm2z-pto4i-dcyee-5z4rz-x63ji-nae",
"3hhby-wmtmw-umt4t-7ieyg-bbiig-xiylg-sblrt-voxgt-bqckd-a75bf-rqe",
"nl6hn-ja4yw-wvmpy-3z2jx-ymc34-pisx3-3cp5z-3oj4a-qzzny-jbsv3-4qe",
"x33ed-h457x-bsgyx-oqxqf-6pzwv-wkhzr-rm2j3-npodi-purzm-n66cg-gae",
"uzr34-akd3s-xrdag-3ql62-ocgoh-ld2ao-tamcv-54e7j-krwgb-2gm4z-oqe",
"2fq7c-slacv-26cgz-vzbx2-2jrcs-5edph-i5s2j-tck77-c3rlz-iobzx-mqe",
"pzp6e-ekpqk-3c5x7-2h6so-njoeq-mt45d-h3h6c-q3mxf-vpeq5-fk5o7-yae",
"bkfrj-6k62g-dycql-7h53p-atvkj-zg4to-gaogh-netha-ptybj-ntsgw-rqe"
]
Thanks @andrea, this sounds like a good approach if the list of subnets can be depended on to be ordered by creation time. Thanks for pointing this out!
Thanks again @andrea. This appears to have largely done the trick, except for a minor limitation. There appear to be 32 executed CreateSubnet Subnet Management proposals historically (and a few others that either failed or were rejected). This means there are 5 subnets unaccounted for in terms of CreateSubnet proposals. It definitely makes sense that the NNS subnet wouldn’t be created this way, but that leaves 4 Verified Application subnets unaccounted for.
The first executed CreateSubnet proposal appears to be Proposal: 20 - ICP Dashboard (internetcomputer.org)
Add verified_application subnet number 5 (commit 8a560f9510b0df9e747ffaede3b731f2ade9c0b7)
Do you know how these four Verified Application subnets would have been created?
This may be related to the fact that some historic proposal are not retrievable (or the ID was skipped for some reason) - e.g. Proposal: 19 - ICP Dashboard (internetcomputer.org)
@msumme are you able to explain this?
Ah right, good catch I forgot about that.
This has to do with the bootstrapping the Internet Computer. At a high level bootstrapping the IC involved 3 steps toward launching a decentralized network:
The Internet Computer officially launched on May 10 when the ICP ledger went live and tokens became tradable, but the above bootstrapping steps took several days to complete. Here’s a video explaining the bootstrapping process if you are interested in knowing a bit more about it.
Pre-launch, in between step 2 and 3 there was a short period of time where governance was not yet decentralized, which is when those four app subnets were created. The process was exactly the same as it is today, however those proposals are not visible because in step 3 the governance canister was reinstalled and its initial decentralized state was set. Thus proposals predating the reinstallation are no longer available. However, the registry has never been reinstalled since the creation of the NNS subnet and its state contains all the mutations to the IC configurations since bootstrapping. So if you want to dig out the initial configurations of those subnets you can look inside the registry and see when the subnet records were added. I am not sure what’s the best way to do that, probably using the registry client from the monorepo to fetch all the deltas (@msumme may have better suggestions here).
This may be related to the fact that some historic proposal are not retrievable (or the ID was skipped for some reason) - e.g. Proposal: 19 - ICP Dashboard (internetcomputer.org)
I think those are just “private” neuron management proposals that are not indexed by the dashboard.
This is really useful and interesting info, thanks @andrea! I’ll enjoy that video later after work.
This sounds promising, thank you. I’ll take a look when I next get a chance 
There’s currently an open proposal for removing a node from multiple subnets at once. More info below:
That works. You might also look at the get_value method on the Registry canister, as it allows you to look at particular registry keys at given versions. So you could start at Registry version 1, and then maybe do a simple binary search for early versions until you find where those subnets show up.
I wasn’t present during Genesis, but I do know some configuration was preloaded into the first IC because it couldn’t be done by proposal.
Thanks @msumme, this is much appreciated. I’ll give this a go when I get a chance 
Hi Everyone!
First off, I want to say that the subnet management forum posts are a fantastic idea—they really help make the voting process much more transparent. As we’re going through this for the first time, I also want to acknowledge that, as a Node Provider (NP), I wasn’t initially aware of the importance of communicating certain updates through the forum. Up until now, we’ve been relying mainly on the Matrix channel for maintenance updates. As per my matrix post in July
as shown here : Subnet Management - tdb26 (NNS) - #10 by MalithHatananchchige
I realize now that this wasn’t the best approach, and I’ll be updating the Wiki with this information to help future NPs avoid the same oversight.
For example, here are two Wiki pages that I plan to update with my learnings:
The main reasons an NP might request to remove a node from a subnet usually involve:
In my case, the proposals to migrate the CM1 nodes from an issue where our ISP assigned IP addresses that are not recognized as local, even though latency remains unchanged. To resolve this, we’ve taken steps to obtain our own local IPv4 and IPv6 subnets.
As you can see in the screenshot @Lorimer posted,
the CM1 IP addresses are currently geolocated in India. This presents a challenge for us in proving that we are indeed operating out of Colombo, Sri Lanka. To address this, we decided to purchase a local IP subnet, as we anticipate audits from Dfinity in the near future. This migration will not only correct the geolocation data in the GeoDB but also provide us with access to a larger IPv4 subnet, which will be beneficial as the Internet Computer (IC) begins encouraging NPs to incorporate IPv4 in their node clusters.
I hope this migration makes sense, and once again, I sincerely apologize for not communicating this on the forum earlier and only using the Matrix channel. I appreciate your understanding—it’s my first time handling ongoing maintenance as an NP, and I’m learning as I go.
Thank you for your support and patience!
Thanks @MalithHatananchchige! I hope you’ll consider announcing future proposals on these threads in the future (in addition to linking to the forum post from your proposal summary - this way everyone knows where to look for the discussion)
I’ve provided more of a response below:
As per our discussion here: Subnet Management Discussion, using the ‘Change Subnet Membership’ proposal requires replacing node IDs, which I believe should be decided by Dfinity or an independent reviewer, not by NPs.
For reference based on this proposal, the parameters might look like this:
./ic-admin --nns-url https://ic0.app \
propose-to-change-subnet-membership \
--summary "" \
--proposer <NEURON_ID> \
--subnet-id <SUBNET_ID> \
--node_ids_add <NODE_ID_TO_ADD> \
--node_ids_remove <NODE_ID_TO_REMOVE>
I disagree that NPs should decide on replacement nodes.
The simple steps for redeploying a node should be:
@Lorimer If you can kindly let me know which nodes I can use to replace that also would be great
Proposals that formally modify the topology of a subnet should be performed or guided by those that are able to do so in a way that does not violate the formally voted in target topology (motion proposal). I agree.
Im afraid I’m too busy today to assist with this until later this evening. In the meantime I highlighted what I consider to be four appropriate replacement nodes in this post → Subnet Management - 4zbus (Application) - #13 by Lorimer (scratch that, wrong context)
If you’re unsure of how to modify the subnet topology for the best, I would reach out to DFINITY for a hand, and/or review unassigned nodes for an appropiate replacement.
Hi @Lorimer @MalithHatananchchige, I think it’s a good suggestion that all proposal types (e.g. also subnet management and node admin proposals) are announced on the Forum as well, just like Node Provider proposals. This will help the review by the community. In particular because these proposals are less “deterministic” than NNS proposals where commits can be checked, hashes recalculated etc, whereas in for node provider, node and subnet proposals considerations like decentralization rate, target topology, identity verification and other items are relevant to be reviewed.
I will add some comments in the wiki pages for node providers on this (you could do as well of course, since the wiki is accessible for updates). My suggestion would be to have the formal announcements of proposals prior to submission on the forum, and keep any technical discussion on the Matrix/Element channel.
I’ve voted to reject proposal 132141.
The proposal improves most of the parameters (nodes per country, etc) but overlooks some. There is still one country with 6 nodes as well as 2 nodes that have the same data centre and node provider. However, main reasons for rejecting are:
It replaces a dead node with itself.
In one case, a node provider goes from having 1 node on this subnet to having 2, which appears to be a failure of the algorithm.
Good observations @timk11 I concur
There are 3 other proposals with the same sorts of issues:
There are 2 more which mostly seem good, but I have some outstanding questions about them:
@sat and/or @SvenF would you be up for announcing future Subnet Management proposals on this thread and/or on the relevant subnet-specific thread?
It would be great if you could then also provide a link to the post in the proposal that’s raised. Otherwise it’s hard for most voters to see and understand the context and discussion relating to the proposal (which is surely very important).
You are right @timk11 , this was a bug in the DRE tool, fixed here: fix(dre): dre heal should not consider unhealthy nodes as replacement candidates by sasa-tomic · Pull Request #794 · dfinity/dre · GitHub
This does not necessarily mean that decentralization got worse. For instance, you might be improving in other features (dimensions) such as Country, Continent, etc., while not making the decentralization worse.
@SvenF and I had a chat about this and yes, this is a known deficiency in the DRE tool, and it’s now fixed in fix(dre): dre heal should not consider unhealthy nodes as replacement candidates by sasa-tomic · Pull Request #794 · dfinity/dre · GitHub. Thanks for flagging!
@Lorimer It’s expected that unassigned nodes run on a different version. Nodes will automatically upgrade to the subnet’s version when they join the new subnet.
Thanks @sat, but the upgrade path guarantees are strictly +1/-1 (in terms of version steps). All 6 of the above proposals seek to add unassigned nodes to a subnet that is 2 replica versions above the version currently deployed on the unassigned nodes, which is outside of the support guarantees that replica versions are developed to adhere to.
Specificially, Release: 94fd38099f0e63950eb5d5673b7b9d23780ace2d - ICP Dashboard (internetcomputer.org) is being skipped, and as far as I understand, it shouldn’t be.