fix(pgw): update

RoRoJ · RoRoJ · commit 386cce8c9048 · 2025-02-03T17:35:54.000+01:00
diff --git a/pages/public-gateways/concepts.mdx b/pages/public-gateways/concepts.mdx
@@ -66,8 +66,7 @@ Private Networks attached to legacy Public Gateways must stay in the gateway's a
 **IPAM** Public Gateways are fully and natively integrated with the Scaleway IPAM without any workaround. Your gateway is in IPAM mode if:
 - You created it via the Scaleway console on or after 17 October 2023 
 - You created it via the Scaleway API or devtools using the `ipam_config` object, and the auto-calculated `is_legacy` [Gateway parameter](https://www.scaleway.com/en/developers/api/public-gateway/#path-gateways-create-a-public-gateway) has a value of `false`. 
-
-You cannot "migrate" a legacy Public Gateway to become an IPAM-mode gateway. While legacy Public Gateways continue to function thanks to our [workaround](/vpc/reference-content/vpc-migration/#public-gateways-and-vpc), you cannot modify them to become natively integrated IPAM networks. If you wish to have an IPAM-mode Public Gateway, for example to benefit from IP management via Scaleway's [IPAM](https://www.scaleway.com/en/developers/api/vpc/) API as more features become available, or to use Kapsule with full isolation, you must create a new gateway.
+- You moved it from legacy mode to IPAM mode using the dedicated button in the console, or the dedicated API call.
 
 <Message type="note">
 When creating a Kubernetes Kapsule cluster with [full isolation](/kubernetes/reference-content/secure-cluster-with-private-network/#can-i-use-a-public-gateway-with-my-private-network-to-exit-all-outgoing-traffic-from-the-nodes) you are required to attach a Public Gateway to the cluster's Private Network, and this **cannot** be a legacy Public Gateway - it must be an IPAM-mode gateway.
diff --git a/pages/public-gateways/reference-content/assets/scaleway-pgw-table.webp b/pages/public-gateways/reference-content/assets/scaleway-pgw-table.webp
diff --git a/pages/public-gateways/reference-content/understanding-v2.mdx b/pages/public-gateways/reference-content/understanding-v2.mdx
@@ -13,22 +13,37 @@ categories:
   - network
 ---
 
+TODO CHECK CONSOLE MENTIONS
+TODO CHECK DATE - NOT JUNE
+
 Scaleway's VPC offering is evolving, and with this comes changes for the Public Gateway product.
 
 This document explains what to expect and how to prepare for the upcoming changes.
 
 ## Summary (TL;DR)
 
-<Lightbox src="scaleway-pgw-table.webp" alt="A visual graphic shows in table form what is explained in text below" />
-
-All Scaleway Public Gateways until now have been created and managed with the version 1 of the [Public Gateways API](https://www.scaleway.com/en/developers/api/public-gateway/), either explicitly via the API itself, or implicitly behind the scenes of the Scaleway console / devtools. 
+All Scaleway Public Gateways until now have been created and managed with the version 1 of the [Public Gateways API](https://www.scaleway.com/en/developers/api/public-gateway/), either explicitly via the API itself, or implicitly behind the scenes of the Scaleway console or other developer tools. 
 
 **We are now deprecating v1 of the API and transitioning to v2.**
 
-After a six month deprecation period ending on 2 June 2025, the Public Gateways API v1 and associated developer tools will be removed. Before this time, you must:
+|  | **PGW API v1** | **PGW API v2** |
+|---|---|---|
+| Supports [legacy-mode PGWs](/public-gateways/concepts/#ipam) | Yes ✅ | No ❌|
+| Supports [IPAM-mode PGWs](/public-gateways/concepts/#ipam) | Yes ✅ | Yes ✅|
+| Supports custom DHCP via PGW | Yes ✅ | No ❌|
+| Supports SSH bastion allowed IPs, and future new features | No ❌| Yes ✅ |
+| Deprecated? | Yes ✅ | No ❌|
+| Removal date | 2 June 2025 | --- |
+| Compatible with PGW management via Scaleway console? | Only until 2 June 2025 | Yes ✅ |
+
+After a deprecation period ending on 2 June 2025, the Public Gateways API v1 and associated developer tools will be removed. 
+
+**What you need to do before 2 June 2025:**
 
 - Ensure that your Public Gateway is in [IPAM mode](#ipam-mode-becomes-default). Only IPAM-mode gateways are compatible with v2.
+
 - Put any non-IPAM mode ([legacy](/network/public-gateways/concepts/#ipam)) Public Gateways in IPAM mode, by using the **Move to IPAM mode** button in the console, or the [dedicated API call](TODO).
+
 - Update any code or scripts you have that call version 1 of the Public Gateways API, so that they call version 2 instead, and do not refer to [removed functionalities](#introducing-public-gateways-api-v2).
 
 If your Public Gateway is already in IPAM mode, and you only manage it via the console, you will not be affected by these changes and you do not need to take any action.
@@ -72,9 +87,7 @@ Legacy Public Gateways use a [workaround](/network/vpc/reference-content/vpc-mig
 
 Legacy mode will be deprecated going forward, and will not be compatible with v2 of the Public Gateway API. It will no longer be possible to create legacy-mode Public Gateways, all gateways will necessarily be in IPAM mode.
 
-If you still have a legacy gateway, you must transition it to IPAM mode so that it is compatible with v2 of the API. Do this by using the **Move to IPAM mode** button in the console, or the [dedicated API call](TODO).
-
-This will update the auto-calculated `is_legacy` field and put your gateway in IPAM mode.
+If you still have a legacy gateway, you must transition it to IPAM mode so that it is compatible with v2 of the API. Do this by using the **Move to IPAM mode** button in the console, or the [dedicated API call](TODO). This will update the auto-calculated `is_legacy` field and put your gateway in IPAM mode.
 
 ### Removal of the DHCP object
 
@@ -86,7 +99,7 @@ When attaching a Public Gateway to a Private Network (creating a [Gateway Networ
 
 **The DHCP object does not exist in v2 of the API**. After v1 is removed, it will no longer be possible to create or attach DHCP objects to Gateway Networks. Instead, IPAM configuration, where auto-configuration of `GatewayNetwork` is managed by IPAM, will become default, and replace any need for DHCP configuration via the Public Gateway.
 
-Going forward, we expect users who were previously using a custom DHCP object to move to the standard set-up of IPAM and Private Networks' inbuilt DHCP for private IP assignment. Remember that you can define a [custom CIDR block](/vpc/how-to/create-private-network/#how-to-configure-cidr) for a Private Network at the time of creation, and use [reserved IP addresses](/ipam/how-to/reserve-ip/#how-to-reserve-a-private-ip-address) with IPAM when attaching both standard and custom resources.
+When you move your gateway to IPAM mode, any existing custom DHCP objects will become defunct. Going forward, we expect users who were previously using a custom DHCP object to move to the standard set-up of IPAM and Private Networks' inbuilt DHCP for private IP assignment. Remember that you can define a [custom CIDR block](/vpc/how-to/create-private-network/#how-to-configure-cidr) for a Private Network at the time of creation, and use [reserved IP addresses](/ipam/how-to/reserve-ip/#how-to-reserve-a-private-ip-address) with IPAM when attaching both standard and custom resources.
 
 ### Removal of the address field
 
@@ -141,11 +154,15 @@ TODO CHECK DATES
 ### How do I know if I have to take action?
 
 - Consider whether you mange your Public Gateway uniquely via the Scaleway console, or via calls to the API/devtools in code and scripts:
+
   - **Code and scripts**: If you have any code or scripts that call v1 of the API, or use devtool functionality that is removed from v2 such as DHCP object or entries, **you must take action before 2 June 2025**. Update your code and scripts so they point to v2 of the API. [Follow the examples provided for tools such as Terraform](TODO) to rewrite your devtool templates so they do not refer to removed functionalities. Do this in synchronization with moving your gateway to IPAM mode (if necessary).
+
   - **Console-only**: You do not need to take any action, except ensuring that your gateway is in IPAM mode.
 
-- Check in the [Scaleway console](https://console.scaleway.com/public-gateway/public-gateways) whether your Public Gateway is in IPAM mode or legacy mode.
+- Check in the [Scaleway console](https://console.scaleway.com/public-gateway/public-gateways) whether your Public Gateway is in IPAM mode or legacy mode:
+
   - **Legacy mode**: you must move the gateway to IPAM mode. Only IPAM mode gateways are compatible with v2. Use the **Move to IPAM mode** button in the console, or the [dedicated API call](TODO).
+
   - **IPAM mode**: you do not have any action to take, except updating any code and scripts that you have (see above).
 
 ### How do I move my legacy Public Gateway to IPAM mode?
