Merge pull request #133 from autermann/fix/115

add considerations related to DDIL

api/part1/standard/sections/clause_6_overview.adoc

@@ -24,6 +24,13 @@ Models from the {ogc-w3c-ssn} are the basis for the design of the CS API, and th
 
 The CS API defines several resource/feature types in separate requirements classes, any combination of which can be implemented by the server. This allows resources to be distributed across several servers (potentially different implementations of the CS API) and connected via hyperlinks. For example, a given implementation can choose to implement only `System` and `Deployment` features and rely on other servers to host complementary metadata such as `Procedures`, `Property Definitions` and `Features of Interest` (i.e. domain features). This is a common use cases since procedure descriptions (i.e. system datasheets) and domain features (e.g. geographical or hydrological features) can typically be shared by many different organizations.
 
+The CS API also help solve several issues for application running in Denied, Disrupted, Intermittent, and Limited (DDIL) environments, e.g. under tactical implementation conditions. This includes:
+
+- Reduction of payload sizes in contrast to predecessor standards (OGC SOS and OGC SPS) by using a resource oriented JSON API instead of remote procedure calls with XML payloads
+- SWE Common encoding supported by the OGC API - Connected Systems - Part 2: Dynamic data allows the separation of datastream schemas from actual data values which helps to reduce payload size compared to other encoding standards.
+- Pub/Sub protocols supported by OGC API - Connected Systems - Part 3: Pub/Sub will help track changes and only download changes when required, or receive new data without continuous polling.
+-  OGC API - Connected Systems - Part 5: Binary Encoding will add even more compact encodings such as FlatGeobuf for feature resources or Protobuf and FlatBuffers for observations and commands
+
 
 === Resource Types