Address review comments

Signed-off-by: xing-yang <xingyang105@gmail.com>

Author: xing-yang

tags/tag-infrastructure/initiatives/storage-landscape/v3/topics/disaster-recovery.md

@@ -4,14 +4,14 @@ Disaster Recovery refers to the behaviour of our systems (not just the storage c
 
 At a high-level, a disaster recovery provider must ensure two things:
 
-- Client requests are resumed being processed as soon as possible in failure domains that are still available. This metrics is measured by RTO (Recovery Time Objective)
+- Client requests are resumed being processed as soon as possible in failure domains that are still available. This is measured by RTO (Recovery Time Objective)
 - The least amount of data is lost due to the disaster. This is measured by RPO (recovery point objective).
 
 That being said, the design of disaster recovery procedures focuses mainly on how to replicate the state of stateful workloads across failure domains, such that data is not lost due to a disaster.
 
-The following diagram summarises the main disaster recovery design archetypes, moving from an Active/Passive architectural style (Backup/Restore, Volume Replication, Transaction Replication) to a fully Active/Active style (Distributed Stateful Workload / CNDR), with each successive archetype trading additional architectural complexity for a tighter RTO/RPO:
+The following diagram summarises the main disaster recovery design archetypes, moving from an Active/Passive architectural style (Backup/Restore, Volume Replication, Transaction Replication) to a fully Active/Active style (Distributed Stateful Workload / Cloud Native Disaster Recovery), with each successive archetype trading additional architectural complexity for a tighter RTO/RPO:
 
-![Four disaster recovery design archetypes: Back up and restore (Active/Passive, backup to a safe location and restore into a cold failure domain), Volume Replication (Active/Passive, volume replication into a passive failure domain), Transaction Replication (Active/Passive, transaction replication over a network tunnel from a master to a slave database), and Distributed Stateful Workload / CNDR (Active/Active, state sync across a database cluster spanning three active failure domains).](images/disaster-recovery.png)
+![Four disaster recovery design archetypes: Back up and restore (Active/Passive, backup to a safe location and restore into a cold failure domain), Volume Replication (Active/Passive, volume replication into a passive failure domain), Transaction Replication (Active/Passive, transaction replication over a network tunnel from a master to a slave database), and Distributed Stateful Workload / Cloud Native Disaster Recovery (Active/Active, state sync across a database cluster spanning three active failure domains).](images/disaster-recovery.png)
 
 This table summarises the characteristics of each approach:
 
@@ -24,4 +24,6 @@ This table summarises the characteristics of each approach:
 | Disaster Recovery process ownership | Infrastructure team, particularly storage team | Infrastructure team, particularly storage team | Owner of middleware, typically developer team | Owner of middleware, typically developer team |
 | Required Capabilities | Storage: backup and restore<br>Networking: global load balancer | Storage: volume synchronising<br>Networking: global load balancer | Networking: global load balancer, east-west path | Networking: global load balancer, east-west path |
 
+The DR process ownership row above reflects a common default, but most cloud native organizations blur this split in practice. Actual ownership depends on org structure and should be clarified in your own runbooks.
+
 For a more detailed dissertation of this topic, please see the [Disaster Recovery White Paper](https://github.com/cncf/tag-storage/blob/master/cloud-native-disaster-recovery-whitepaper/Cloud%20Native%20Disaster%20Recovery%20V1.pdf).

tags/tag-infrastructure/initiatives/storage-landscape/v3/topics/streaming-and-messaging.md

@@ -16,6 +16,15 @@ However, in many cases, proprietary protocols that are owned and maintained by a
 
 Some programming languages provide their own set of standard APIs to abstract the wire-level protocol used by the messaging/streaming system (for example the Java-JMS API).
 
+The following table gives some examples of how popular systems map onto this protocol landscape:
+
+| System | Native Protocol | Also Supports |
+| --- | --- | --- |
+| Apache Kafka | Kafka protocol (binary over TCP) | AMQP/MQTT via external bridges/connectors (e.g. Kafka Connect), not native |
+| RabbitMQ | AMQP 0-9-1 | MQTT, STOMP (via bundled plugins) |
+| Amazon SQS | HTTP(S)-based AWS API | JMS 1.1 interface via the Amazon SQS Java Messaging Library |
+| Apache Pulsar | Pulsar binary protocol | Kafka protocol (KoP), AMQP (AoP), MQTT (MoP) — official Pulsar protocol handlers |
+
 ## 11.2 Availability and durability
 
 Streaming and messaging systems use different approaches to achieve availability and reliability: