Incident Handling with the New Boundary Node Architecture

Why the II subnet: The reasons are the same as the ones @Severin laid out for the cycles ledger canister. In short: system subnet, independent of NNS governance and ICP ledger.

Other approaches: In my opinion, there are only two viable approaches:

  1. Creating a new proposal that allows to install canisters on non-NNS subnets.
  2. The proposed approach of authorizing a principal, installing the canister, removing the authorization of the principal and handing the canister over to the NNS.

Installing the canister first on the NNS subnet and then migrating it is a bit of an overkill in my opinion. It has been done once for the Internet Identity canister. That canister used to be on the NNS subnet and was moved to the II subnet on October 26 2022 (see the corresponding forum thread). Migrating a canister requires altering the routing table. The routing table is a mapping of subnet IDs to canister ranges. When the II canister moved, the NNS canister range [start, end] was split into two [start, II canister ID - 1] and [II canister ID + 1, end] and the II canister ID was added as a new range to the II subnets ranges. This leads to “fragmentation” and I would try to avoid it if not absolutely necessary.