fix(pgw): add screenshot

Author: RoRoJ

pages/public-gateways/reference-content/assets/scaleway-pgw-listing.png

@@ -19,14 +19,14 @@ This document explains what to expect and how to prepare for the upcoming change
 
 ## Summary (TL;DR)
 
-All Scaleway Public Gateways until now have been created and managed with the [v1 version](TODO-LINK) of the Public Gateways API, either explicitly via the API itself or other devtools, or implicitly behind the scenes of the Scaleway console. 
+All Scaleway Public Gateways until now have been created and managed with the v1 version of the [Public Gateways API](https://www.scaleway.com/en/developers/api/public-gateway/), either explicitly via the API itself or other devtools, or implicitly behind the scenes of the Scaleway console. 
 
-**We are now deprecating v1 of the API and transitioning to [v2](TODO-LINK).**
+**We are now deprecating v1 of the API and transitioning to v2.**
 
 After a six month deprecation period, the Public Gateways API v1 and associated developer tools will be removed. Before this time, you must:
 
-- Ensure that your Public Gateway is in [IPAM mode](/network/public-gateways/concepts/#ipam). 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 detaching them and reattaching them to their Private Networks.
+- Ensure that your Public Gateway is in [IPAM mode](/network/public-gateways/concepts/#ipam). 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 detaching them and reattaching them to their Private Networks, or using the dedicated button in the console.
 - Update any code or scripts you have that call version 1 of the Public Gateways API, so that they call version 2 instead.
 
 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.
@@ -57,9 +57,11 @@ Read on to find out more.
 
 Scaleway Public Gateways are either in **Legacy mode** or **IPAM mode**. You can see the mode of a given gateway by:
 
-- Checking its badge in the gateway listing page of the [Scaleway console](https://console.scaleway.com/public-gateway/public-gateways)
+- Checking its badge in the gateway listing page of the [Scaleway console](https://console.scaleway.com/public-gateway/public-gateways) (see screenshot below).
 - Checking the value of the `is_legacy` field via the [Public Gateways API](https://www.scaleway.com/en/developers/api/public-gateway/#path-gateways-get-a-public-gateway).
 
+<Lightbox src="scaleway-pgw-listing.webp" alt="A screen in the Scaleway console shows a listing of two Public Gateways, one of which has a badge saying IPAM, the other a badge saying Legacy." />
+
 <Message type="tip">
 All Public Gateways created via the Scaleway console since 17 October 2023 are necessarily in IPAM mode.
 </Message>
@@ -68,37 +70,41 @@ 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 **detaching and reattaching the Public Gateway from its Private Network**. 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 either: 
+- Detaching and reattaching the Public Gateway from its Private Network, or
+- Using the dedicated button in the Scaleway console. 
+
+This will update the auto-calculated `is_legacy` field and put your gateway in IPAM mode.
 
 ### Deprecation of the DHCP object
 
-This functionality was available via the API and developer tools only (not the Scaleway console).
+For some time now, this functionality has been available via the API and developer tools only (not the Scaleway console).
 
-The [DHCP object](https://www.scaleway.com/en/developers/api/public-gateway/#path-dhcp-list-dhcp-configurations) has, until now, allowed users to define a DHCP configuration, which specified how the gateway should assign IP addresses to devices on attached Private Networks (parameters including the subnet of the DHCP server, entry validity period and more). 
+The [DHCP object](https://www.scaleway.com/en/developers/api/public-gateway/#path-dhcp-list-dhcp-configurations) has allowed users to define a DHCP configuration, which specified how the gateway should assign IP addresses to devices on attached Private Networks (parameters including the subnet of the DHCP server, entry validity period and more). 
 
 When attaching a Public Gateway to a Private Network (creating a [Gateway Network](https://www.scaleway.com/en/developers/api/public-gateway/#path-gateway-networks-attach-a-public-gateway-to-a-private-network)) via the API, you can pass a DHCP object, or the ID of an existing DHCP object. 
 
-**The DHCP object will not exist in v2 of the API**. 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.
+**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.
 
 For legacy gateways using the DHCP object for custom DHCP configuration, **no automatic migration of this DHCP functionality** will take place when the gateway moves into IPAM-mode. We expect users to move to the standard set-up of IPAM and Private Networks for DHCP and private IP assignment.
 
 ### Deprecation of the address field
 
-This functionality was available via the API and developer tools only (not the Scaleway console).
+For some time now, this functionality has been available via the API and developer tools only (not the Scaleway console).
 
-When attaching a Public Gateway to a Private Network (creating a [Gateway Network](https://www.scaleway.com/en/developers/api/public-gateway/#path-gateway-networks-attach-a-public-gateway-to-a-private-network)) via the API, you can use the `address` field to define a single static IP address to assign to the Public Gateway on that Private Network.
+When attaching a Public Gateway to a Private Network (creating a [Gateway Network](https://www.scaleway.com/en/developers/api/public-gateway/#path-gateway-networks-attach-a-public-gateway-to-a-private-network)) via the API, you could use the `address` field to define a single static IP address to assign to the Public Gateway on that Private Network.
 
-**The `address` field will not exist in v2 of the API**. Instead, you can pass an `ipam_ip_id` to specify a reserved IP address to use for the Public Gateway on this Private Network, if you wish. Otherwise, IPAM will auto-assign an IP address from the Private Network's CIDR block to the Public Gateway.
+**The `address` field does not exist in v2 of the API**. Instead, you can pass an `ipam_ip_id` to specify a reserved IP address to use for the Public Gateway on this Private Network, if you wish. Otherwise, IPAM will auto-assign an IP address from the Private Network's CIDR block to the Public Gateway.
 
 TODO: will we automatically take care of this when legacy gateways transition to IPAM mode?
 
 ### Deprecation of DHCP entries
 
-This functionality was available via the API and developer tools only (not the Scaleway console).
+For some time now, this functionality has been available via the API and developer tools only (not the Scaleway console).
 
-[DHCP entries](https://www.scaleway.com/en/developers/api/public-gateway/#path-dhcp-entries-list-dhcp-entries) belong to a specified `GatewayNetwork` (Public Gateway / Private Network attachment) and can hold dynamic DHCP leases or static, user-created DHCP reservations. They effectively allow the Public Gateway to assign certain IP addresses to certain resources on the Private Network.
+[DHCP entries](https://www.scaleway.com/en/developers/api/public-gateway/#path-dhcp-entries-list-dhcp-entries) could be created, belonging to a specified `GatewayNetwork` (Public Gateway / Private Network attachment), holding dynamic DHCP leases or static, user-created DHCP reservations. They have effectively allowed the Public Gateway to assign certain IP addresses to certain resources on the Private Network.
 
-**DHCP entries will not exist in v2 of the API**. Instead, you can rely on the default IPAM/DHCP functionality as described [above](#background-dhcp-and-ipam). The default behavior will auto-assign IP addresses to resources on the Private Network from the network's CIDR block, or you can use the IP reservation functionality to specify the IP address(es) to assign to each resource.
+**DHCP entries do not exist in v2 of the API**. Instead, you can rely on the default IPAM/DHCP functionality as described [above](#background-dhcp-and-ipam). The default behavior will auto-assign IP addresses to resources on the Private Network from the network's CIDR block, or you can use the IP reservation functionality to specify the IP address(es) to assign to each resource.
 
 For custom resources, such as VMs hosted on Elastic Metal servers, you can use the IPAM API's [Attach IP to custom resource](https://www.scaleway.com/en/developers/api/ipam/#path-ips-attach-ip-to-custom-resource) method to assign IP addresses on Private Networks. This lets you associate a [reserved IP](https://www.scaleway.com/en/developers/api/ipam/#path-ips-reserve-a-new-ip) address with a resource name and MAC address.
 
@@ -110,14 +116,16 @@ TODO
 
 ## Deprecation and removal timeline
 
-1. [TODO-DATE] **21 February 2025 - V1 deprecation**: The Public Gateway v1 API will be deprecated. Deprecation means that the API will still function, but it is slated for removal and we do not recommended that you keep using it.
+TODO CHECK DATES
+
+1. **21 February 2025 - V1 deprecation**: The Public Gateway v1 API will be deprecated. Deprecation means that the API will still function, but it is slated for removal and we do not recommended that you keep using it.
 2. [TODO-DATE] **V2 release**: The Public Gateway v2 API will be released, co-existing with v1. 
 
     <Message type="note">
     You will be able to list and manage all gateways with the **Scaleway console**, which will adapt to use v1 or v2 of the API as necessary. However, all new Public Gateways created via the console after [TODO-DATE] will necessarily be v2 gateways.
     </Message>
 
-3. [TODO-DATE - TODO-DATE] **Migration period**: You have a six month migration period to complete the following actions
+3. **21 February 2025 - 2 June 2025: Migration period**: You have a six month migration period to complete the following actions
 
     - Ensure that your Public Gateway is in [IPAM-mode](/network/public-gateways/concepts/#ipam). 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 **detaching them and reattaching them to their Private Networks**.
@@ -126,7 +134,7 @@ TODO
 
     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.
 
-4. [TODO-DATE] **2 June 2025 - V1 removal**: The Public Gateway v1 API will be removed. Any code or scripts still pointing to v1 will cease to function. We will automatically put any existing legacy Public Gateways into IPAM mode.
+4. **2 June 2025 - V1 removal**: The Public Gateway v1 API will be removed. Any code or scripts still pointing to v1 will cease to function. We will automatically put any existing legacy Public Gateways into IPAM mode.
 
 ## FAQ