edit pass: traffic-analytics-schema-update

Author: v-dihans

articles/network-watcher/traffic-analytics-schema-update.md

@@ -16,17 +16,17 @@ ms.date: 03/06/2020
 ms.author: vinigam
 
 ---
-# Sample queries with new fields in Traffic Analytics schema (August 2019 schema update)
+# Sample queries with new fields in the Traffic Analytics schema (August 2019 schema update)
 
-The [Traffic Analytics log schema](https://docs.microsoft.com/azure/network-watcher/traffic-analytics-schema) includes the following new fields: **SrcPublicIPs_s** , **DestPublicIPs_s**, **NSGRule_s**. The new fields provide information about source and destination IPs, and also simplify queries.
+The [Traffic Analytics log schema](https://docs.microsoft.com/azure/network-watcher/traffic-analytics-schema) includes the following new fields: **SrcPublicIPs_s** , **DestPublicIPs_s**, **NSGRule_s**. The new fields provide information about source and destination IPs, and they simplify queries.
 
 In the next few months, the following older fields will be deprecated: **VMIP_s**, **Subscription_g**, **Region_s**, **NSGRules_s**, **Subnet_s**, **VM_s**, **NIC_s**, **PublicIPs_s**, **FlowCount_d**.
 
-Review examples of how to replace the old fields with the new ones.
+The following three examples show how to replace the old fields with the new ones.
 
-## Replacing the VMIP_s, Subscription_g, Region_s, Subnet_s, VM_s, NIC_s, and PublicIPs_s fields
+## Example 1: VMIP_s, Subscription_g, Region_s, Subnet_s, VM_s, NIC_s, and PublicIPs_s fields
 
-We don't have to infer source and destination cases from the **FlowDirection_s** field for AzurePublic and ExternalPublic flows. It can also be inappropriate to use the **FlowDirection_s** field for a Network Virtual Appliance.
+We don't have to infer source and destination cases from the **FlowDirection_s** field for AzurePublic and ExternalPublic flows. It can also be inappropriate to use the **FlowDirection_s** field for a network virtual appliance.
 
 ```Old Kusto query
 AzureNetworkAnalytics_CL
@@ -68,13 +68,13 @@ SourcePublicIPsAggregated = iif(isnotempty(SrcPublicIPs_s), SrcPublicIPs_s, "N/A
 DestPublicIPsAggregated = iif(isnotempty(DestPublicIPs_s), DestPublicIPs_s, "N/A")
 ```
 
-## Replacing the NSGRules_s field
+## Example 2: NSGRules_s field
 
 The old field used the format:
 
 <Index value 0)>|<NSG_ RuleName>|<Flow Direction>|<Flow Status>|<FlowCount ProcessedByRule>
 
-We no longer aggregate data across a network security group (NSG). In the updated schema **NSGList_s** contains only one NSG. Also, **NSGRules** used to contain only one rule. We removed the complicated formatting here and in other fields as shown:
+We no longer aggregate data across a network security group (NSG). In the updated schema, **NSGList_s** contains only one NSG. Also **NSGRules** contains only one rule. We removed the complicated formatting here and in other fields as shown in the example.
 
 ```Old Kusto query
 AzureNetworkAnalytics_CL
@@ -99,22 +99,24 @@ FlowStatus = FlowStatus_s,
 FlowCountProcessedByRule = AllowedInFlows_d + DeniedInFlows_d + AllowedOutFlows_d + DeniedOutFlows_d
 ```
 
-## Replacing the FlowCount_d field
+## Example 3: FlowCount_d field
 
-Since we do not club data across the NSG, the **FlowCount_d** is simply:
+Because we do not club data across the NSG, the **FlowCount_d** is simply:
 
 **AllowedInFlows_d** + **DeniedInFlows_d** + **AllowedOutFlows_d** + **DeniedOutFlows_d**
 
-Only one of the four fields will be non-zero. The other three fields will be zero. This indicates the status and count in the NIC where the flow was captured.
+Only one of the four fields will be nonzero. The other three fields will be zero. The fields populate to indicate the status and count in the NIC where the flow was captured.
 
-- If the flow was allowed, one of the "Allowed" fields will be populated. 
-- If the flow was denied, one of the "Denied" fields will be populated.
-- If the flow was inbound, one of the "InFlows_d" fields will be populated. 
-- If the flow was outbound, one of the "OutFlows_d" fields will be populated.
+To illustrate these conditions:
 
-Depending on the above conditions, we know which one of the four fields will be populated.
+- If the flow was allowed, one of the "Allowed" prefixed fields will be populated.
+- If the flow was denied, one of the "Denied" prefixed fields will be populated.
+- If the flow was inbound, one of the "InFlows_d" suffixed fields will be populated.
+- If the flow was outbound, one of the "OutFlows_d" suffixed fields will be populated.
 
+Depending on the conditions, we know which one of the four fields will be populated.
 
-## Next Steps
-To get answers to frequently asked questions, see [Traffic Analytics FAQ](traffic-analytics-faq.md)
-To see details about functionality, see [Traffic Analytics documentation](traffic-analytics.md)
+## Next steps
+
+- To get answers to frequently asked questions, see [Traffic Analytics FAQ](traffic-analytics-faq.md).
+- To see details about functionality, see [Traffic Analytics documentation](traffic-analytics.md).