First pass at including all missing ECS Beta 2 changes...

- With the exception of http, captured in #9645
- With the exception of os, which must be updated in a bunch of places

libbeat/_meta/fields.ecs.yml

@@ -116,10 +116,23 @@
       title: Client
       group: 2
       description: >
-        A client is defined as the initiator of a network connection for events regarding sessions, connections, or bidirectional flow records. For TCP events, the client is the initiator of the TCP connection that sends the SYN packet(s). For other protocols, the client is generally the initiator or requestor in the network transaction. Some systems use the term "originator" to refer the client in TCP connections. The client fields describe details about the system acting as the client in the network event. Client fields are usually populated in conjuction with server fields.  Client fields are generally not populated for packet-level events. 
+        A client is defined as the initiator of a network connection for events regarding sessions, connections, or bidirectional flow records. For TCP events, the client is the initiator of the TCP connection that sends the SYN packet(s). For other protocols, the client is generally the initiator or requestor in the network transaction. Some systems use the term "originator" to refer the client in TCP connections. The client fields describe details about the system acting as the client in the network event. Client fields are usually populated in conjunction with server fields.  Client fields are generally not populated for packet-level events.
+    
+        Client / server representations can add semantic context to an exchange, which is helpful to visualize the data in certain situations. If your context falls in that category, you should still ensure that source and destination are filled appropriately.
       type: group
       fields:
 
+        - name: address
+          level: extended
+          type: keyword
+          description: >
+            Some event client addresses are defined ambiguously. The event will
+            sometimes list an IP, a domain or a unix socket.  You should always
+            store the raw address in the `.address` field.
+    
+            Then it should be duplicated to `.ip` or `.domain`, depending on which
+            one it is.
+
         - name: ip
           level: core
           type: ip
@@ -350,11 +363,22 @@
       title: Destination
       group: 2
       description: >
-        Destination fields describe details about the destination of a
-        packet/event. Destination fields are usually populated in conjunction with source fields.
+        Destination fields describe details about the destination of a packet/event.
+        Destination fields are usually populated in conjunction with source fields.
       type: group
       fields:
 
+        - name: address
+          level: extended
+          type: keyword
+          description: >
+            Some event destination addresses are defined ambiguously. The event will
+            sometimes list an IP, a domain or a unix socket.  You should always
+            store the raw address in the `.address` field.
+    
+            Then it should be duplicated to `.ip` or `.domain`, depending on which
+            one it is.
+
         - name: ip
           level: core
           type: ip
@@ -485,8 +509,8 @@
             different ECS versions -- this field lets integrations adjust to the
             schema version of the events.
 
-            The current version is 1.0.0-beta1 .
-          example: 1.0.0-beta1
+            The current version is 1.0.0-beta2 .
+          example: 1.0.0-beta2
 
     - name: error
       title: Error
@@ -1138,8 +1162,11 @@
           level: core
           type: keyword
           description: >
-            In the OSI Model this would be the Network Layer. IPv4, IPv6, IPSec, PIM, etc
-          example: IPv4
+            In the OSI Model this would be the Network Layer. ipv4, ipv6, ipsec, pim, etc
+    
+            The field value must be normalized to lowercase for querying. See
+            "Lowercase Capitalization" in the "Implementing ECS" section.
+          example: ipv4
 
         - name: iana_number
           level: extended
@@ -1155,8 +1182,11 @@
           type: keyword
           description: >
             Same as network.iana_number, but instead using the Keyword name of the
-            transport layer (UDP, TCP, IPv6-ICMP, etc.)
-          example: TCP
+            transport layer (udp, tcp, ipv6-icmp, etc.)
+    
+            The field value must be normalized to lowercase for querying. See
+            "Lowercase Capitalization" in the "Implementing ECS"  section.
+          example: tcp
 
         - name: application
           level: extended
@@ -1167,13 +1197,19 @@
             facebook, twitter. This would be used in situations where the vendor
             or service can be decoded such as from the source/dest IP owners,
             ports, or wire format.
-          example: AIM
+    
+            The field value must be normalized to lowercase for querying. See
+            "Lowercase Capitalization" in the "Implementing ECS" section.
+          example: aim
 
         - name: protocol
           level: core
           type: keyword
           description: >
-            L7 Network protocol name. ex. http, lumberjack, transport protocol
+            L7 Network protocol name. ex. http, lumberjack, transport protocol.
+    
+            The field value must be normalized to lowercase for querying. See
+            "Lowercase Capitalization" in the "Implementing ECS" section.
           example: http
 
         - name: direction
@@ -1571,9 +1607,22 @@
       group: 2
       description: >
         A Server is defined as the responder in a network connection for events regarding sessions, connections, or bidirectional flow records. For TCP events, the server is the receiver of the initial SYN packet(s) of the TCP connection. For other protocols, the server is generally the responder in the network transaction. Some systems actually use the term "responder" to refer the server in TCP connections. The server fields describe details about the system acting as the server in the network event. Server fields are usually populated in conjunction with client fields. Server fields are generally not populated for packet-level events.
+    
+        Client / server representations can add semantic context to an exchange, which is helpful to visualize the data in certain situations. If your context falls in that category, you should still ensure that source and destination are filled appropriately.
       type: group
       fields:
 
+        - name: address
+          level: extended
+          type: keyword
+          description: >
+            Some event server addresses are defined ambiguously. The event will
+            sometimes list an IP, a domain or a unix socket.  You should always
+            store the raw address in the `.address` field.
+    
+            Then it should be duplicated to `.ip` or `.domain`, depending on which
+            one it is.
+
         - name: ip
           level: core
           type: ip
@@ -1769,10 +1818,11 @@
       title: Source
       group: 2
       description: >
-        Source fields describe details about the source of a
-        packet/event. Source fields are usually populated in conjunction with destination fields.
+        Source fields describe details about the source of a packet/event.
+        Source fields are usually populated in conjunction with destination fields.
       type: group
       fields:
+
         - name: address
           level: extended
           type: keyword
@@ -2063,7 +2113,6 @@
         - name: original
           level: extended
           type: keyword
-          index: false
           description: >
             Unparsed version of the user_agent.
           example: "Mozilla/5.0 (iPhone; CPU iPhone OS 12_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1"