remove cc

Author: IPFSUnion

FIPS/fip-0025.md

@@ -1,6 +1,6 @@
 ---
 fip: "0025"
-title: Extend the fault period of cc sector from 2 weeks to 6 weeks
+title: Extend the fault period of sector from 2 weeks to 6 weeks
 author: IPFSUnion(@IPFSUnion)
 discussions-to: https://github.com/filecoin-project/FIPs/issues/189
 status: Draft
@@ -26,22 +26,22 @@ Filecoin needs to extend the fault period so that large storage providers have e
 
 Any country in the world is likely to face force majeure factors such as major natural disasters or social abnormal events, causing storage providers to be unable to provide services normally for a long period of time. To this end, we must plan ahead.
 In the current implementation of the protocol, the sector will be forcibly terminated if there are two consecutive weeks of faults. However, two weeks is not enough for a large storage provider to complete the data migration and restart the service. If appropriate measures are not taken, it will not only cause huge economic losses to the storage provider, but also cause large fluctuations in the storage power of the entire Filecoin network.
-Therefore, it is necessary to make some adjustments to the sector fault period. Regarding the deal sector, the current data of all transactions is about 32 PiB. It is not a big problem to complete the real data migration within two weeks, but it is far from enough for the EiB level of cc sector to complete the migration within two weeks, so we propose to extend the cc sector fault period from 2 weeks to 6 weeks.
+Therefore, it is necessary to make some adjustments to the sector fault period. Regarding the deal sector, the current data of all transactions is about 32 PiB. It is not a big problem to complete the real data migration within two weeks, but it is far from enough for the EiB level of cc sector to complete the migration within two weeks, so we propose to extend the sector fault period from 2 weeks to 6 weeks.
 
 ## Specification
 <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Filecoin implementations. -->
 
-Extend fault period of cc sector from 2 weeks to 6 weeks.
+Extend fault period of sector from 2 weeks to 6 weeks.
 
 ## Design Rationale
 <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
 
-Extend the cc sector fault period to buy time for storage providers to migrate data
+Extend the sector fault period to buy time for storage providers to migrate data
 
 ## Backwards Compatibility
 <!--All FIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The FIP must explain how the author proposes to deal with these incompatibilities. FIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
 
-The proposal extends the fault period of the cc sector, so such changes must be completed through version upgrades.
+The proposal extends the fault period of the sector, so such changes must be completed through version upgrades.
 
 
 ## Test Cases