address review feedback

EIPS/eip-7742.md

@@ -28,12 +28,6 @@ This EIP also changes how the EL sources the current blob target value for two r
 
 2) Uncouple development and deployment of the CL and EL layers in the event it is desirable to change the blob target value.
 
-## Specification
-
-| constants                    | value                                        |
-|---                           |---                                           |
-| `FORK_TIMESTAMP`             | TBD                                          |
-
 ### Background
 
 The data facility introduced via EIP-4844 adds blobs to Ethereum blocks, which are simply fixed sets of data that can be
@@ -67,7 +61,7 @@ to preserve the security of optimistic sync.
 
 ### Block structure and validity
 
-Beginning at the execution timestamp `FORK_TIMESTAMP`, execution clients **MUST** extend the header schema with an
+Upon activation of this EIP, execution clients **MUST** extend the header schema with an
 additional 64-bit field: the `target_blob_count`. This value is set to the current target blob count. The Engine API
 is modified along with this EIP to provide the `target_blob_count` with each payload and implementations can use this
 value to correctly set the block header field.
@@ -82,7 +76,7 @@ target blob count given by that genesis block's protocol rule set.
 
 ### Block processing
 
-At the start of processing any execution block where `block.timestamp >= FORK_TIMESTAMP` (i.e. before processing any transactions),
+Upon activating this EIP (i.e. before processing any transactions),
 the verification of the blob maximum as given in EIP-4844 can be skipped. Concretely, this means any logic relating
 to `MAX_BLOB_GAS_PER_BLOCK` as given in EIP-4844 can be deprecated.
 Additionally, any reference to `TARGET_BLOB_GAS_PER_BLOCK` from EIP-4844 can be derived by taking the `target_blob_count` from the CL and multiplying by `GAS_PER_BLOB` as given in EIP-4844.