diff --git a/FIPS/fip-0047.md b/FIPS/fip-0047.md
index 2fc871bc1..aad0a429f 100644
--- a/FIPS/fip-0047.md
+++ b/FIPS/fip-0047.md
@@ -9,8 +9,6 @@ category: Core
 created: 2022-08-31
 ---
 
-- TODO: should the existing ExtendSectorExpiration method also refresh proof, if it can?
-
 ## Simple Summary
 
 Adds a `ProofExpiration` parameter to each sector, 
@@ -192,7 +190,7 @@ and thus requires a network upgrade and sector state migration.
 Impact on tooling should be minimal beyond changes to sector management software.
 
 ## Test Cases
-(Will be) Included with implementation to be presented.
+Will be included with implementation to be presented.
 
 ## Security Considerations
 Decoupling sector proof expiration from their commitment duration allows longer commitment durations 
@@ -201,6 +199,7 @@ without compromising the network’s ability to respond to flaws in PoRep.
 If a flaw is discovered, an increased commitment duration would create the need for replacement sealing, 
 or penalties for non-replaced sectors.
 
+
 TODO: describe the cryptoecon modelling and the simulation outcome
 
 ## Incentive Considerations
@@ -208,6 +207,13 @@ This proposal does not adjust incentives for providers or clients,
 but it does make longer sector commitments possible. 
 Other proposals may then introduce incentives for such commitments.
 
+In case of an emergency response,
+charging some termination fee when a sector proof is not refreshed creates an incentive
+to seal replacement sectors vs let old sectors expired un-replaced.
+Further analysis is warranted into the _ideal_ termination penalty in this case.
+However, such analysis need not prevent us adopting this mechanism, for its other advantages,
+and policy, in order to provide greater clarity for storage provider business operations.
+
 ## Product Considerations
 If the maximum sector commitment duration is increased, 
 then a sector committed for longer than its initial proof expiration must be refreshed, 
@@ -221,7 +227,8 @@ operational risk to the provider,
 which must remember to and succeed in refreshing the proof within the refresh window.
 
 ## Implementations
-The `CommitmentExpiration` and `ProofExpiration` separation implementation is available at TBC.
+The `CommitmentExpiration` and `ProofExpiration` separation implementation is available at 
+https://github.com/filecoin-project/builtin-actors/pull/518.
 
 The replacement sealing implementation is deferred until needed.