diff --git a/Amazon-S3-API.md b/Amazon-S3-API.md
index 03c1e74..26ae9ce 100644
--- a/Amazon-S3-API.md
+++ b/Amazon-S3-API.md
@@ -60,7 +60,7 @@ To be sure, you can look at the function defined in the files `weed/s3api/s3api_
 * GetObject / HeadObject (returns x-amz-meta-* headers)
 * CopyObject (with metadata directive)
 
-// Server-Side Encryption (NEW)
+// Server-Side Encryption
 * PutObject (with SSE-KMS, SSE-C, SSE-S3)
 * GetObject (with automatic decryption)
 * HeadObject (with encryption metadata)
@@ -68,7 +68,7 @@ To be sure, you can look at the function defined in the files `weed/s3api/s3api_
 * Multipart uploads with encryption
 * Bucket default encryption
 
-// Conditional Operations (NEW)
+// Conditional Operations
 * All object operations support conditional headers:
   - If-Match
   - If-None-Match
@@ -114,10 +114,17 @@ To be sure, you can look at the function defined in the files `weed/s3api/s3api_
 * GetObjectLegalHold
 * PutObjectLegalHold
 * BypassGovernanceRetention (via x-amz-bypass-governance-retention header)
+
+// Bucket Policies
+* PutBucketPolicy
+* GetBucketPolicy
+* DeleteBucketPolicy
+* Supported Conditions:
+  - s3:ExistingObjectTag
 ```
 
 Not included:
-* Policy
+
 
 # User Metadata (Custom Attributes)
 
diff --git a/Erasure-Coding-for-warm-storage.md b/Erasure-Coding-for-warm-storage.md
index 71071a8..9d286f5 100644
--- a/Erasure-Coding-for-warm-storage.md
+++ b/Erasure-Coding-for-warm-storage.md
@@ -12,6 +12,7 @@ However, data can become warm or cold after a period of time. They are accessed
 * **Memory Efficiency** Minimum memory usage. The volume server does not load index data into memory.
 * **Fast Startup** Startup time is much shorter by skip loading index data into memory.
 * **Rack-Aware** data placement to minimize impact of volume server and rack failures.
+* **Disk-Aware** data placement to ensure shards are distributed across different physical disks within a server, protecting against individual disk failures in JBOD setups.
 * **Flexible Server Layout** There are no minimum number of servers, or racks. SeaweedFS manages erasure coding data via volumes. If the number of servers is less than 4, EC can protect against hard drive failures. If the number of servers is greater than or equal to 4, EC can protect against server failures. If the number of racks is greater than 4, EC can protect against rack failures.
 
 The downside:
@@ -21,9 +22,8 @@ The downside:
 * Compaction would require converting back to normal volumes first.
 
 Side Note:
-* The 10+4 can be easily adjusted via `DataShardsCount` and `ParityShardsCount` in 
-https://github.com/seaweedfs/seaweedfs/blob/master/weed/storage/erasure_coding/ec_encoder.go#L17
-* If you are considering these enterprise-level customizations, please consider supporting SeaweedFS first.
+* The 10+4 configuration is the default for the open source version.
+* The SeaweedFS Enterprise version supports custom EC ratios.
 
 ## Architecture
 SeaweedFS implemented 10.4 Reed-Solomon Erasure Coding (EC). The large volumes are split into chunks of 1GB, and every 10 data chunks are also encoded into 4 parity chunks. So a 30 GB data volume will be encoded into 14 EC shards, each shard is of size 3 GB and has 3 EC blocks.
diff --git a/Security-Configuration.md b/Security-Configuration.md
index d7bb16e..36505cc 100644
--- a/Security-Configuration.md
+++ b/Security-Configuration.md
@@ -1,6 +1,7 @@
 
 
 For an overview of SeaweedFS security architecture and communication layers, see [[Security-Overview]].
+For FIPS 140-3 compliance information, see [[Cryptography-and-FIPS-Compliance]].
 
 The first step is generating `security.toml` file via `weed scaffold -config=security`: