Update text/0199-support-elastic-common-schema-in-opentelemetry.md

Co-authored-by: Armin Ruech <[email protected]>

text/0199-support-elastic-common-schema-in-opentelemetry.md

@@ -36,6 +36,8 @@ Adoption of OTEL logs will accelerate greatly if ECS is leveraged as the common
 Customers will benefit from turnkey logs integrations that will be fully recognized by OTEL-compatible observability products and services.
 
 OpenTelemetry logging is today mostly structured when instrumentation libraries are used. However, most of the logs which exist today are generated by software, hardware, and cloud services which the user cannot control. OpenTelemetry provides a limited set of "reference integrations" to  structure logs: primarily the [OpenTelemetry Collector Kubernetes Events Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/k8seventsreceiver) and an example of a regexp based parsing of Tomcat access logs with OpenTelemetry Collector File Receiver ([here](https://github.com/open-telemetry/opentelemetry-log-collection/blob/30807b96b2f0771e7d11452ebf98fe5e211ed6d7/examples/tomcat/config.yaml#L20)).
+By expanding the OTel semantic conventions with further namespaces already defined in ECS, a broader coverage of such mappings from different sources can be defined and implemented in the OTel collector.
+This, for example, includes logs from network appliances (mapping to the `network` and `interface` namespaces in ECS).
 
 The semantic conventions of a log are a challenge. What is a specific component defined in a log and how does it relate to other logs which have the same semantic component defined differently. ECS has already done some heavy-lifting on defining a unified set of semantic conventions which can be adopted in OTEL.