Minor adjustments to the wording: 'the perimeter' not your, nor their

elastic · Oct 2, 2020 · f41def5 · f41def5
1 parent 0796cc3
commit f41def5
Show file tree

Hide file tree

Showing 6 changed files with 14 additions and 14 deletions.
diff --git a/code/go/ecs/network.go b/code/go/ecs/network.go
diff --git a/docs/field-details.asciidoc b/docs/field-details.asciidoc
@@ -3344,9 +3344,9 @@ Recommended values are:
 
 When mapping events from a host-based monitoring context, populate this field from the host's point of view, using the values "ingress" or "egress".
 
-When mapping events from a network or perimeter-based monitoring context, populate this field from the point of view of your network perimeter, using the values "inbound", "outbound", "internal" or "external".
+When mapping events from a network or perimeter-based monitoring context, populate this field from the point of view of the network perimeter, using the values "inbound", "outbound", "internal" or "external".
 
-Note that "internal" is not crossing perimeter boundaries, and is meant to describe communication between two hosts within the perimeter. Note also that "external" is meant to describe traffic between two hosts that are external to their perimeter. This could for example be useful for ISPs or VPN service providers.
+Note that "internal" is not crossing perimeter boundaries, and is meant to describe communication between two hosts within the perimeter. Note also that "external" is meant to describe traffic between two hosts that are external to the perimeter. This could for example be useful for ISPs or VPN service providers.
 
 type: keyword
 

diff --git a/generated/beats/fields.ecs.yml b/generated/beats/fields.ecs.yml
@@ -2598,12 +2598,12 @@
         \  * unknown\n\nWhen mapping events from a host-based monitoring context,\
         \ populate this field from the host's point of view, using the values \"ingress\"\
         \ or \"egress\".\nWhen mapping events from a network or perimeter-based monitoring\
-        \ context, populate this field from the point of view of your network perimeter,\
+        \ context, populate this field from the point of view of the network perimeter,\
         \ using the values \"inbound\", \"outbound\", \"internal\" or \"external\"\
         .\nNote that \"internal\" is not crossing perimeter boundaries, and is meant\
         \ to describe communication between two hosts within the perimeter. Note also\
         \ that \"external\" is meant to describe traffic between two hosts that are\
-        \ external to their perimeter. This could for example be useful for ISPs or\
+        \ external to the perimeter. This could for example be useful for ISPs or\
         \ VPN service providers."
       example: inbound
     - name: forwarded_ip

diff --git a/generated/ecs/ecs_flat.yml b/generated/ecs/ecs_flat.yml
@@ -3988,12 +3988,12 @@ network.direction:
     \nWhen mapping events from a host-based monitoring context, populate this field\
     \ from the host's point of view, using the values \"ingress\" or \"egress\".\n\
     When mapping events from a network or perimeter-based monitoring context, populate\
-    \ this field from the point of view of your network perimeter, using the values\
+    \ this field from the point of view of the network perimeter, using the values\
     \ \"inbound\", \"outbound\", \"internal\" or \"external\".\nNote that \"internal\"\
     \ is not crossing perimeter boundaries, and is meant to describe communication\
     \ between two hosts within the perimeter. Note also that \"external\" is meant\
-    \ to describe traffic between two hosts that are external to their perimeter.\
-    \ This could for example be useful for ISPs or VPN service providers."
+    \ to describe traffic between two hosts that are external to the perimeter. This\
+    \ could for example be useful for ISPs or VPN service providers."
   example: inbound
   flat_name: network.direction
   ignore_above: 1024

diff --git a/generated/ecs/ecs_nested.yml b/generated/ecs/ecs_nested.yml
@@ -4736,12 +4736,12 @@ network:
         \  * unknown\n\nWhen mapping events from a host-based monitoring context,\
         \ populate this field from the host's point of view, using the values \"ingress\"\
         \ or \"egress\".\nWhen mapping events from a network or perimeter-based monitoring\
-        \ context, populate this field from the point of view of your network perimeter,\
+        \ context, populate this field from the point of view of the network perimeter,\
         \ using the values \"inbound\", \"outbound\", \"internal\" or \"external\"\
         .\nNote that \"internal\" is not crossing perimeter boundaries, and is meant\
         \ to describe communication between two hosts within the perimeter. Note also\
         \ that \"external\" is meant to describe traffic between two hosts that are\
-        \ external to their perimeter. This could for example be useful for ISPs or\
+        \ external to the perimeter. This could for example be useful for ISPs or\
         \ VPN service providers."
       example: inbound
       flat_name: network.direction

diff --git a/schemas/network.yml b/schemas/network.yml
@@ -97,13 +97,13 @@
         field from the host's point of view, using the values "ingress" or "egress".
 
         When mapping events from a network or perimeter-based monitoring context,
-        populate this field from the point of view of your network perimeter,
+        populate this field from the point of view of the network perimeter,
         using the values "inbound", "outbound", "internal" or "external".
 
         Note that "internal" is not crossing perimeter boundaries, and is meant
         to describe communication between two hosts within the perimeter. Note also
         that "external" is meant to describe traffic between two hosts that are
-        external to their perimeter. This could for example be useful for ISPs or
+        external to the perimeter. This could for example be useful for ISPs or
         VPN service providers.
       example: inbound