dictionary updates

(cherry picked from commit e71c5d1)

Author: thomaskoslowski

src/common/de/cmc_differences.asciidoc

@@ -86,7 +86,7 @@ Durch dieses Verfahren ergibt sich eine Reihe von Vorteilen:
 
 * Nahezu vernachlässigbare CPU-Last durch Host-Checks: Es können selbst ohne besonders leistungsfähige Hardware Zigtausende von Hosts überwacht werden.
 * Kein Ausbremsen des Monitorings durch blockierende Host-Checks auf Abruf, falls Hosts {DOWN} sind.
-* Keine Fehlalarme von Services bei nicht aktuellem Host-Status.
+* Keine Fehlalarme von Services bei nicht aktuellem Host-Zustand.
 
 Ein Nachteil soll dabei nicht verschwiegen werden: 
 Die Host-Checks via Smart Ping erzeugen keine Performance-Daten (Paketlaufzeiten).

src/common/en/cmc_differences.asciidoc

@@ -44,7 +44,7 @@ Instead of multiple packets in rapid series that are waited upon, `icmpsender` s
 This behavior drastically reduces resource consumption and data traffic.
 
 The responses to the pings are not explicitly waited-for.
-CMC's `icmpreceiver` component is responsible for deciding whether the status of a host is {UP} or {DOWN}.
+CMC's `icmpreceiver` component is responsible for deciding whether the state of a host is {UP} or {DOWN}.
 It considers incoming ping packets from a host as a successful host check and thus marks the host as {UP}. 
 If no packet is received from a host within a defined time, this host will be flagged as {DOWN}.
 The timeout is preset to 15 seconds (2.5 intervals) and can be changed per host with the [.guihint]#Settings for host checks via Smart PING# rule set.
@@ -64,20 +64,20 @@ This mechanism can lead to flapping states of hosts in infrastructures where ICM
 
 Host checks not only serve to trigger notifications in the case of a total host failure, but also to suppress xref:notifications#state_host[notifications of service problems] during the host's down time. 
 Service problems can arise and not be responsibility of the service itself, but rather of a failure condition of the host.
-It can happen that a host is actually {DOWN} even if its last known status in {CMK} is {UP} as per the last host check result.
-In such condition multiple service checks could returns problems that depend on the hosts {DOWN} status, resulting in sending service notifications -- erroneously.
+It can happen that a host is actually {DOWN} even if its last known state in {CMK} is {UP} as per the last host check result.
+In such condition multiple service checks could returns problems that depend on the hosts {DOWN} state, resulting in sending service notifications -- erroneously.
 It is therefore important to determine a host's condition first, in the event of a service problem.
 
 The CMC solves this problem very simply:
-if a service problem arises and the host is in an {UP} status, CMC will wait for the next host check. 
+if a service problem arises and the host is in an {UP} state, CMC will wait for the next host check. 
 Due to the interval being very short at only (by default) 6 seconds, there is only a negligible delay to a notification -- if the host is still {UP} and therefore the notification needs to be sent for the service.
 
-As an example, let's take the case of a `check_http` plug-in delivering a {CRIT} status, due to a queried web server being unavailable.
+As an example, let's take the case of a `check_http` plug-in delivering a {CRIT} state, due to a queried web server being unavailable.
 In this situation, _following the start_ of the service check a TCP RST packet (_connection refused_) will be received from this server by the `icmpreceiver` component.
 The CMC therefore knows for certain that the host itself is {UP} and it can thus send the notification without delay.
 
 The same principle is utilized when calculating network outages if xref:notifications#parents[parent hosts] have been defined.
-Here as well notifications will at times be delayed briefly in order to wait for a verified status.
+Here as well notifications will at times be delayed briefly in order to wait for a verified state.
 // end proofreading
 
 
@@ -87,7 +87,7 @@ This procedure yields a number of advantages:
 
 * Virtually insignificant CPU load resulting from host checks -- even without particularly powerful hardware umpteen thousand hosts can be monitored.
 * No thwarting of monitoring by on-demand host check jams if hosts are {DOWN}.
-* No false alarms from services when a host status is not current.
+* No false alarms from services when a host state is not current.
 
 One disadvantage should not be hushed-up however: 
 the Smart Ping host checks generate no performance data (packet runtimes).