Clarifications from review

FIPS/fip-0045.md

@@ -14,7 +14,6 @@ TODO:
 - Spec token receiver hook payload schema for allocation requests
 - Spec token receiver hook payload for extending allocations with new datacap
 - Market method for fetching allocation/claim ids for deals (needed?)
-- Consider removing provision for re-commitment of same data in new sector (defer to follow-up)
 
 
 ## Simple Summary
@@ -116,12 +115,13 @@ An allocation's maximum term must be at least as large as its minimum term.
 Due to the implementation of term enforcement (details below), clients should leave a large buffer
 between the minimum and maximum term to make the allocation practical for a provider.
 
-An allocation must expire, so that it cannot occupy non-useful DataCap indefinitely.
+Network policy limits the maximum value for an allocation's expiration,
+so that an allocation cannot occupy non-useful DataCap indefinitely.
 
 **Parameters**
-- The minimum allowed value for `TermMinimum` is 6 months.
-- The maximum allowed value for `TermMaximum` is 5 years (can be increased by a future FIP).
-- The maximum difference between `Expiration` and the epoch at which an allocation is created is 60 days.
+- `MinimumVerifiedAllocationTerm`: The minimum allowed value for `TermMinimum` is 6 months.
+- `MaximumVerifiedAllocationTerm`: The maximum allowed value for `TermMaximum` is 5 years (can be increased by a future FIP).
+- `MaximumVerifiedAllocationExpiration`: The maximum difference between `Expiration` and the epoch at which an allocation is created is 60 days.
 
 Allocations are stored in the verified registry actor's state, grouped by client address.
 Nesting by client promotes more efficient lookups at scale, 
@@ -140,13 +140,14 @@ struct State {
 }
 ```
 
-#### Operations
+#### Creation of allocations
 An allocation is created by a verified client by transferring DataCap tokens (see below)
 to the verified registry. 
 The `Allocation` metadata must be provided as transfer metadata.
 The verified registry checks the same preconditions as the existing `UseBytes` method. 
 The size of the allocation must match the number of tokens received.
 
+#### Removal of expired allocations
 An allocation may be removed after its expiration epoch has passed (by anyone). 
 When removed, the DataCap tokens are transferred back to the client.
 The verified registry provides a new method to process removals, replacing `RestoreBytes`.
@@ -165,12 +166,12 @@ fn RemoveExpiredAllocations(params: RemoveExpiredAllocationsParams)
 
 Allocations are also removed when claimed by a provider (see below).
 
-The `RemoveVerifiedClientDataCap` method invokes a privileged method of the DataCap token actor
-to burn DataCap tokens held on a client's balance. 
+#### Revocation of un-allocated data cap
+The existing `RemoveVerifiedClientDataCap` method is changed to invoke a 
+privileged method of the DataCap token actor to burn DataCap tokens held on a client's balance. 
 Only the verified registry actor is permitted to invoke this method.
 
 ### Verified Registry DataCap claims
-
 The verified registry actor is further extended to record each storage provider's commitment to a
 DataCap allocation, called a claim. A claim represents a provider's obligation to store a piece of
 data, and corresponding benefit of incentivized storage power.
@@ -208,7 +209,7 @@ struct State {
 }
 ```
 
-#### Operations
+#### Creation of claims from allocations
 An allocation is claimed when a storage miner actor proves the corresponding piece of data 
 is committed to a sector.
 Upon converting an allocation to a claim, the verified registry actor burns the associated
@@ -245,7 +246,8 @@ struct SectorClaimResult {
 fn ClaimAllocations(params: ClaimAllocationsParams) -> ClaimAllocationsResult
 ```
 
-The record of a claim may be removed by the provider after the term maximum has elapsed.
+#### Removal of expired claims
+The record of a claim may be removed after the term maximum has elapsed.
 
 ```
 struct RemoveExpiredClaimsParams {
@@ -258,8 +260,8 @@ struct RemoveExpiredClaimsParams {
 fn RemoveExpiredClaims(params: RemoveExpiredClaimsParams)
 ```
 
-The maximum term for a claim may be increased by the client which originally made the allocation,
-up to the network policy maximum.
+#### Extension of claim term by client
+A client of a claim may increase its maximum term up to `MaximumVerifiedAllocationTerm`. 
 
 ```
 struct ClaimTerm {
@@ -280,13 +282,14 @@ struct ExtendClaimTermsResult {
 // Called by allocation client to extend the maximum term of their allocations, 
 // without consuming DataCap.
 // The new TermMaximum must be no less than the current one,
-// and no greater than the maximum initial term.
+// and no greater than MaximumVerifiedAllocationTerm.
 fn ExtendClaimTerms(params: ExtendClaimTermsParams) -> ExtendClaimTermsResult
 ```
 
+#### Renewal of claim term by spending datacap
 A verified client can extend the term for a claim _beyond_ the initial maximum term by
 spending new DataCap.
-The term maximum can be extended up to the network policy maximum beyond the current epoch.
+The claim's term maximum can be extended up to `MaximumVerifiedAllocationTerm` beyond the current epoch.
 The client extending the claim need not be the one that made the original allocation.
 This is similar to issuing a new allocation/claim for the same data,
 but avoids overheads of re-sealing.
@@ -324,7 +327,7 @@ Parties will continue to interact with the built-in market actor and verified re
 The built-in account and multisig actors are changed to implement a receiver hook method, as specified by FRC-0046.
 This hook always succeeds, without inspecting the payload.
 
-#### Operations
+#### Changes to datacap operations
 The verified registry's `AddVerifiedClient` method is changed to invoke the DataCap token actor to
 mint new tokens to the client's balance.
 
@@ -341,25 +344,28 @@ DataCap tokens back to the client's balance for re-use.
 ### Simplified quality-adjusted power
 A DataCap allocation/claim is valid for a range of commitment terms, between a client-specified
 minimum and maximum, so long as the allocation is claimed before the allocation expires.
-
 The actual term for a claim begins at the epoch the data is committed into a sector,
 proven either with proof-of-replication or replica-update. 
 There is no distinct "deal start epoch".
-A sector containing a DataCap claim is immediately eligible for a power multiplier of 10 
-for that fraction of the sector's capacity occupied by the incentivized data
+The actual term for a claim ends the epoch that the sector containing the data expires,
+or that data is replaced.
+
+A sector's `DealWeight` and `VerifiedDealWeight` are calculated as simple sums of the sizes
+of the deals, with no multiplication by duration.
+The miner actor computes a sector’s power as `SectorSize + (9 * VerifedDealWeight)`.
+
+A sector containing a DataCap claim is thus immediately eligible for a power multiplier of 10 
+for that fraction of the sector's capacity occupied by `VerifiedDealWeight`
 (subject to the existing requirement to initially prove the sector in Window PoSt).
 
-The actual term for a claim ends the epoch that the sector containing the data expires, 
-or that data is replaced. 
-The term cannot end during a sector's lifetime, except by explicit replacement of data.
-If data is replaced, the sector immediately loses the power multiplier for that fraction
-of the sector's capacity.
+A claim term cannot end during a sector's lifetime, except by explicit replacement of data.
+If data is replaced, the sector's verified deal weight is reduced and it immediately 
+loses the power multiplier for that fraction of the sector's capacity.
 (Replacing non-zero data in a sector is not possible today).
 
 Aligning the claim's term with the sector's expiration exactly in this way removes the
 "spreading-out" of QA power over a sector's life in the current method of computation.
 Providers gain 10x power for each byte of verified data exactly while that data is proven.
-The miner actor computes a sector’s power as `SectorSize + (9 * VerifiedSize)`.
 
 #### Pledge
 A sector's pledge requirement is proportional to its share of power, but never decreases, just as today.
@@ -376,29 +382,27 @@ but any subsequent penalty is calculated using its current (i.e. reduced) power.
 
 ### Storage miner actor
 #### Differentiated sectors
-A new field `HasVerifiedClaims: bool` is added to `SectorOnChainInfo`. 
-This is set `false` for all existing sectors during migration (below).
+A new field `SimpleQAPower: bool` is added to `SectorOnChainInfo`. 
+During the migration activating this proposal, `SimpleQAPower` is set for each sector:
+- `true` if the sector has `VerifiedDealWeight = 0` and `DealWeight = 0`,
+- `false` otherwise
 
-A _new_ sector takes `HasVerifiedClaims = true` if it claims one or more verified allocations.
-Its `DealWeight` and `VerifiedDealWeight` will be a simple sum of the size of those claims.
-Its power is calculated in the simple way described above.
+All sectors committed after this proposal is activated take `SimpleQAPower = true`.
+The value of `SimpleQAPower` never changes for an individual sector.
 
-A _new_ sector takes `HasVerifiedClaims = false` if it claims no verified allocations.
+A sector with `SimpleQAPower = true` has its deal weights calculated as simple sums of deal size,
+and QA power calculated according to the simple method described above, with no spreading out effect.
 
-A sector with `HasVerifiedClaims = false` and `VerifiedDealWeight = 0` 
-(i.e. a committed-capacity sector) takes `HasVerifiedClaims = true` if it claims 
-one or more verified allocations by `ReplicaUpdate`.
-Its new `DealWeight` and `VerifiedDealWeight` are calculated as a sum of the size of those claims.
-Its power is re-calculated in the simple way described above.
-
-A sector with `HasVerifiedClaims = false` and `VerifiedDealWeight > 0` continues to use
-the existing QA-power calculation.
-Such a sector cannot claim a verified allocation.
+A sector with `SimpleQAPower = false` continues to use the existing QA-power calculation.
+Such a sector cannot claim any allocations.
 Such a sector may be extended, but, as today, this will result in its power being diluted
 to "spread out" the verified reward over the sector's new commitment duration.
 
+The `SimpleQAPower` field will become redundant and may be removed by a network upgrade once
+all sectors with the value `false` have expired.
+
 #### Term enforcement
-The built-in miner actor enforces the verified term and the continual storage of the data.
+The built-in miner actor enforces the term and the continual storage of the data.
 
 The miner actor requires that the sector into which a claimed piece is committed must have a
 **remaining lifespan that is sufficient to fulfil the minimum term**.
@@ -418,16 +422,9 @@ There is **no change to termination penalty** calculations.
 If a sector is terminated early (continual faults, or manual termination),
 the provider will pay a penalty related to the expected reward earned by the sector (up to some limit).
 
-The verified registry can support re-commitment of the same data in a new sector
-(even though the built-in storage market actor does not support resumption of a terminated deal).
-If a claim’s maximum term has not been reached when a sector terminates,
-the provider may commit the same piece into a new sector and regain the quality-adjusted power.
-The new sector’s committed lifespan is still constrained to fit within the claim’s term.
-The miner actor must ensure that the old sector is no longer alive. 
-
 #### Sector extension
 A sector's scheduled commitment term cannot be extended beyond the maximum term of any
-verified claim attributed to it (if `HasVerifiedClaims = true`).
+claim attributed to it.
 Thus, to extend a sector, a provider must simultaneously drop any verified claims with 
 terms that would be exceeded by the extended commitment.
 Dropping a verified claim reduces the sector's power accordingly, as well as
@@ -503,7 +500,7 @@ The built-in market specifies an allocation's minimum term to be equal to the de
 and maximum term to be some amount greater than the deal duration.
 
 **Parameters**
-- The built-in market calculates a term maximum of 90 days greater than a deal's specified duration.
+- `MarketDefaultMaximumAllocationTerm`: The built-in market calculates a term maximum of 90 days greater than a deal's specified duration.
 
 ```
 let dealAllocation = Allocation {
@@ -512,14 +509,15 @@ let dealAllocation = Allocation {
   Data: deal.PieceCID
   Size: deal.PieceSize
   TermMinimum: deal.EndEpoch - deal.StartEpoch
-  TermMaximum: deal.EndEpoch - deal.StartEpoch + EPOCHS_IN_YEAR
-  Expiration: min(deal.StartEpoch, CURRENT_EPOCH + 60 * EPOCHS_IN_DAY)
+  TermMaximum: deal.EndEpoch - deal.StartEpoch + MarketDefaultMaximumAllocationTerm
+  Expiration: min(deal.StartEpoch, CURRENT_EPOCH + MaximumVerifiedAllocationExpiration)
   AllowRanges: false
   }
 ```
 
 The market will accept verified deals with a `StartEpoch` beyond the maximum allowed allocation `Expiration`.
 If such a deal is not activated before the allocation expires, it will not confer QA power.
+However, the deal may still be activated and sector commitment should proceed (without QA power).
 
 The market stores allocation IDs for not-yet-activated deals in a new mapping, 
 and the claim ID for activated deals in deal state.
@@ -559,11 +557,12 @@ That migration must:
   and set `NextAllocationId = 1`.
 - Migrate the verified registry client balances map to DataCap token balances, 
   with appropriate unit conversion.
-- Add a new field `HasVerifiedClaim = false` to each `SectorOnChainInfo`.
+- Add a new field `SimpleQAPower` to each `SectorOnChainInfo`, 
+  taking the value `DealWeight == 0 && VerifiedDealWeight == 0`
 - Add the pending allocation mapping to market state, and claim ID field to deal states (all `0`)
 - For each pending (not yet activated) deal with `Verified = true`, create an Allocation
   - The maximum term for such allocations is 540 days, in order to support any possible sector duration
-  - The expiration for such allocations is set to the maximum allowed value after the migration epoch,
+  - The expiration for such allocations is set to `MaximumVerifiedAllocationExpiration` after the migration epoch,
     which may be before the deal's start date.
 
 ## Design Rationale