Some more edits

Author: normesta

articles/storage/blobs/immutable-container-level-worm-policies.md

@@ -1,59 +1,62 @@
 ---
 title: Container-level WORM policies for immutable blob data
 titleSuffix: Azure Storage
-description: Description for container-level WORM goes here.
+description: A container-level write once, read many (WORM) policy is a type of immutability policy that can be set at the container-level.
 services: storage
 author: normesta
 
 ms.service: azure-blob-storage
 ms.topic: conceptual
-ms.date: 09/14/2022
+ms.date: 03/26/2024
 ms.author: normesta
 ---
 
 # Container-level write once, read many (WORM) policies for immutable blob data
 
-Something needed here as an introduction.
+A container-level write once, read many (WORM) policy is a type of immutability policy that can be set at the container-level.
 
 ## Availability
 
-Container-level policies are available for all new and existing containers. These policies are supported for general-purpose v2, premium block blob, general-purpose v1 (legacy)*, and blob storage (legacy) accounts. This feature is supported for hierarchical namespace accounts. If hierarchical namespace is enabled, you cannot rename or move a blob when the blob is in the immutable state. Both the blob name and the directory structure provide essential container-level data that cannot be modified once the immutable policy is in place.
+Container-level WORM policies are available for all new and existing containers. These policies are supported for general-purpose v2, premium block blob, general-purpose v1 (legacy), and blob storage (legacy) accounts.
 
-There is no enablement process for this feature; it is automatically available for all containers. To learn more about how to set a policy on a new or existing container, see [Configure container-level immutability policies](immutable-policy-configure-container-scope.md).
+> [!TIP]
+> Microsoft recommends upgrading general-purpose v1 accounts to general-purpose v2 so that you can take advantage of more features. For information on upgrading an existing general-purpose v1 storage account, see [Upgrade a storage account](../common/storage-account-upgrade.md).
 
-Microsoft recommends upgrading general-purpose v1 accounts to general-purpose v2 so that you can take advantage of more features. For information on upgrading an existing general-purpose v1 storage account, see [Upgrade a storage account](../common/storage-account-upgrade.md).
+This feature is supported for hierarchical namespace accounts. If hierarchical namespace is enabled, you can't rename or move a blob when the blob is in the immutable state. Both the blob name and the directory structure provide essential container-level data that can't be modified once the immutable policy is in place.
+
+There's no enablement process for this feature; it's automatically available for all containers. To learn more about how to set a policy on a new or existing container, see [Configure container-level WORM immutability policies](immutable-policy-configure-container-scope.md).
 
 ## Deletion
 
-A container with a CLW policy set must be empty before the container can be deleted. If there is a policy set on a container with hierarchical namespace enabled, a directory must be empty before it can be deleted.
+A container with a container-level WORM policy set must be empty before the container can be deleted. If there's a policy set on a container with hierarchical namespace enabled, a directory must be empty before it can be deleted.
 
 > [!div class="mx-imgBorder"]
-> ![Diagram that shows the order of operations in deleting an account that has a container-level immutability policy.](media/immutable-version-level-worm-policies/container-level-immutable-storage-deletion.png)
+> ![Diagram that shows the order of operations in deleting an account that has a container-level WORM policy.](media/immutable-version-level-worm-policies/container-level-immutable-storage-deletion.png)
 
 ## Scenarios
 
 | Scenario | Prohibited operations | Blob protection | Container protection | Account protection |
 |----|----|----|-----|-----|
-| A container is protected by an active time-based retention policy with container scope and/or a legal hold is in effect | [Delete Blob](/rest/api/storageservices/delete-blob), [Put Blob](/rest/api/storageservices/put-blob)<sup>1</sup>, [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata), [Put Page](/rest/api/storageservices/put-page), [Set Blob Properties](/rest/api/storageservices/set-blob-properties), [Snapshot Blob](/rest/api/storageservices/snapshot-blob), [Incremental Copy Blob](/rest/api/storageservices/incremental-copy-blob), [Append Block](/rest/api/storageservices/append-block)<sup>2</sup>| All blobs in the container are immutable for content and user metadata. | Container deletion fails if a container-level policy is in effect.| Storage account deletion fails if there is a container with at least one blob present.|
-| A container is protected by an expired time-based retention policy with container scope and no legal hold is in effect | [Put Blob](/rest/api/storageservices/put-blob)<sup>1</sup>, [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata), [Put Page](/rest/api/storageservices/put-page), [Set Blob Properties](/rest/api/storageservices/set-blob-properties), [Snapshot Blob](/rest/api/storageservices/snapshot-blob), [Incremental Copy Blob](/rest/api/storageservices/incremental-copy-blob), [Append Block](/rest/api/storageservices/append-block)<sup>2</sup> | Delete operations are allowed. Overwrite operations are not allowed. | Container deletion fails if at least one blob exists in the container, regardless of whether policy is locked or unlocked. | Storage account deletion fails if there is at least one container with a locked time-based retention policy.<br>Unlocked policies do not provide delete protection.|
+| A container is protected by an active time-based retention policy with container scope and/or a legal hold is in effect | [Delete Blob](/rest/api/storageservices/delete-blob), [Put Blob](/rest/api/storageservices/put-blob)<sup>1</sup>, [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata), [Put Page](/rest/api/storageservices/put-page), [Set Blob Properties](/rest/api/storageservices/set-blob-properties), [Snapshot Blob](/rest/api/storageservices/snapshot-blob), [Incremental Copy Blob](/rest/api/storageservices/incremental-copy-blob), [Append Block](/rest/api/storageservices/append-block)<sup>2</sup>| All blobs in the container are immutable for content and user metadata. | Container deletion fails if a container-level WORM policy is in effect.| Storage account deletion fails if there's a container with at least one blob present.|
+| A container is protected by an expired time-based retention policy with container scope and no legal hold is in effect | [Put Blob](/rest/api/storageservices/put-blob)<sup>1</sup>, [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata), [Put Page](/rest/api/storageservices/put-page), [Set Blob Properties](/rest/api/storageservices/set-blob-properties), [Snapshot Blob](/rest/api/storageservices/snapshot-blob), [Incremental Copy Blob](/rest/api/storageservices/incremental-copy-blob), [Append Block](/rest/api/storageservices/append-block)<sup>2</sup> | Delete operations are allowed. Overwrite operations aren't allowed. | Container deletion fails if at least one blob exists in the container, regardless of whether policy is locked or unlocked. | Storage account deletion fails if there is at least one container with a locked time-based retention policy.<br>Unlocked policies don't provide delete protection.|
 
-<sup>1</sup>    Azure Storage permits the [Put Blob](/rest/api/storageservices/put-blob) operation to create a new blob. Subsequent overwrite operations on an existing blob path in an immutable container are not allowed.
+<sup>1</sup>    Azure Storage permits the [Put Blob](/rest/api/storageservices/put-blob) operation to create a new blob. Subsequent overwrite operations on an existing blob path in an immutable container aren't allowed.
 
-<sup>2</sup>    The [Append Block](/rest/api/storageservices/append-block) operation is permitted only for policies with the allowProtectedAppendWrites or allowProtectedAppendWritesAll property enabled. For more information, see the section below.
+<sup>2</sup>    The [Append Block](/rest/api/storageservices/append-block) operation is permitted only for policies with the **allowProtectedAppendWrites** or **allowProtectedAppendWrites**All property enabled.
 
 ## Allow protected append blobs writes
 
 Append blobs are composed of blocks of data and optimized for data append operations required by auditing and logging scenarios. By design, append blobs only allow the addition of new blocks to the end of the blob. Regardless of immutability, modification or deletion of existing blocks in an append blob is fundamentally not allowed. To learn more about append blobs, see [About Append Blobs](/rest/api/storageservices/understanding-block-blobs--append-blobs--and-page-blobs#about-append-blobs).
 
-The AllowProtectedAppendWrites property setting allows for writing new blocks to an append blob while maintaining immutability protection and compliance. If this setting is enabled, you can create an append blob directly in the policy-protected container and then continue to add new blocks of data to the end of the append blob  with the Append Block operation. Only new blocks can be added; any existing blocks can't be modified or deleted. Enabling this setting doesn't affect the immutability behavior of block blobs or page blobs.
+The **allowProtectedAppendWrites** property setting allows for writing new blocks to an append blob while maintaining immutability protection and compliance. If this setting is enabled, you can create an append blob directly in the policy-protected container and then continue to add new blocks of data to the end of the append blob  with the Append Block operation. Only new blocks can be added; any existing blocks can't be modified or deleted. Enabling this setting doesn't affect the immutability behavior of block blobs or page blobs.
 
-The AllowProtectedAppendWritesAll property setting provides the same permissions as the AllowProtectedAppendWrites property and adds the ability to write new blocks to a block blob. The Blob Storage API doesn't provide a way for applications to do this directly. However, applications can accomplish this by using append and flush methods that are available in the Data Lake Storage Gen2 API. Also, this property enables Microsoft applications such as Azure Data Factory to append blocks of data by using internal APIs. If your workloads depend on any of these tools, then you can use this property to avoid errors that can appear when those tools attempt to append data to blobs.
+The **AllowProtectedAppendWritesAll** property setting provides the same permissions as the **allowProtectedAppendWrites** property and adds the ability to write new blocks to a block blob. The Blob Storage API doesn't provide a way for applications to do this directly. However, applications can accomplish this by using append and flush methods that are available in the Data Lake Storage Gen2 API. Also, this property enables Microsoft applications such as Azure Data Factory to append blocks of data by using internal APIs. If your workloads depend on any of these tools, then you can use this property to avoid errors that can appear when those tools attempt to append data to blobs.
 
 Append blobs remain in the immutable state during the effective retention period. Since new data can be appended beyond the initial creation of the append blob, there's a slight difference in how the retention period is determined. The effective retention is the difference between append blob's last modification time and the user-specified retention interval. Similarly, when the retention interval is extended, immutable storage uses the most recent value of the user-specified retention interval to calculate the effective retention period.
 
-For example, suppose that a user creates a time-based retention policy with the AllowProtectedAppendWrites property enabled and a retention interval of 90 days. An append blob, logblob1, is created in the container today, new logs continue to be added to the append blob for the next 10 days, so that the effective retention period for logblob1 is 100 days from today (the time of its last append + 90 days).
+For example, suppose that a user creates a time-based retention policy with the **allowProtectedAppendWrites** property enabled and a retention interval of 90 days. An append blob, logblob1, is created in the container today, new logs continue to be added to the append blob for the next 10 days, so that the effective retention period for logblob1 is 100 days from today (the time of its last append + 90 days).
 
-Unlocked time-based retention policies allow the AllowProtectedAppendWrites and the AllowProtectedAppendWritesAll property settings to be enabled and disabled at any time. Once the time-based retention policy is locked, the AllowProtectedAppendWrites and the AllowProtectedAppendWritesAll property settings can't be changed.
+Unlocked time-based retention policies allow the **allowProtectedAppendWrites** and the **AllowProtectedAppendWritesAll** property settings to be enabled and disabled at any time. Once the time-based retention policy is locked, the **allowProtectedAppendWrites** and the **AllowProtectedAppendWritesAll** property settings can't be changed.
 
 ## Limits
 

articles/storage/blobs/immutable-storage-overview.md

@@ -118,11 +118,11 @@ The following table shows a breakdown of the differences between container-level
 | Feature dependencies | No other features are a prerequisite or requirement for this feature to function. | Versioning is a prerequisite for this feature to be used. |
 | Enablement for existing accounts/container | This feature can be enabled at any time for existing containers. | Depending on the level of granularity, this feature might not be enabled for all existing accounts/containers. |
 | Account/container deletion | Once a time-based retention policy is locked on a container, containers may only be deleted if they're empty. | Once version-level WORM is enabled on an account or container level, they may only be deleted if they're empty.|
-| Feature availability | This feature is available for Blob Storage and ADLS Gen2. | This feature is only available for Blob Storage. |
+| Support for Azure Data Lake Storage Gen2 (storage accounts that have a hierarchical namespace enabled)| Container-level WORM policies are supported in accounts that have a hierarchical namespace.  | Version-level WORM policies are not yet supported in accounts that have a hierarchical namespace. |
 
-To learn more about container-level WORM, see [Container-Level WORM policies](). To learn more about version-level WORM, please visit [version-Level WORM policies]().
+To learn more about container-level WORM, see [Container-Level WORM policies](immutable-container-level-worm-policies.md). To learn more about version-level WORM, please visit [version-Level WORM policies](immutable-version-level-worm-policies.md).
 
-## Considerations for using Container-level WORM vs Version-level WORM
+## Container-level vs version-level WORM
 
 The following table helps you decide which type of WORM policy to use.
 
@@ -160,7 +160,7 @@ When you enable blob inventory, Azure Storage generates an inventory report dail
 For more information about blob inventory, see [Azure Storage blob inventory](blob-inventory.md).
 
 > [!NOTE]
-> You can't configure an inventory policy in an account if support for version-level immutability is enabled on that account, or if support for version-level immutability is enabled on the destination container that is defined in the inventory policy. 
+> You can't configure an inventory policy in an account if support for version-level immutability is enabled on that account, or if support for version-level immutability is enabled on the destination container that is defined in the inventory policy.
 
 ## Pricing
 
@@ -173,7 +173,6 @@ If you fail to pay your bill and your account has an active time-based retention
 ## Feature support
 
 This feature is incompatible with point in time restore and last access tracking. 
-
 Immutability policies aren't supported in accounts that have Network File System (NFS) 3.0 protocol or the SSH File Transfer Protocol (SFTP) enabled on them.
 
 Some workloads, such as SQL Backup to URL, create a blob and then add to it.   If a container has an active time-based retention policy or legal hold in place, this pattern won't succeed. See the Allow protected append blob writes for more detail.
@@ -183,6 +182,7 @@ For more information, see [Blob Storage feature support in Azure Storage account
 ## Next steps
 
 - [Data protection overview](data-protection-overview.md)
-- 
+- [Container-level WORM policies for immutable blob data](immutable-container-level-worm-policies.md)
+- [Version-level WORM policies for immutable blob data](immutable-version-level-worm-policies.md)
 - [Configure immutability policies for blob versions](immutable-policy-configure-version-scope.md)
 - [Configure immutability policies for containers](immutable-policy-configure-container-scope.md)