Correct grammar and formatting

Correct acronym defined first for each document
Use Alliance instead of CSA (two terms: Alliance and CSA were
used for the Connectivity Standard Alliance)
Correct grammar mistakes
Correct formatting
Apply uniform formatting of lists with dot at the end

content/Alliance/_index.md

@@ -5,12 +5,10 @@ weight = 2
 pre = "<b>2. </b>"
 +++
 
-
-# The Connectivity Standards Alliance
+# The Connectivity Standards Alliance (The Alliance)
 
 Our wide-ranging global membership is on a mission. That mission is to ignite creativity and collaboration in the Internet of Things, by developing, evolving, and promoting universal open standards that enable all objects to securely connect and interact. We believe all objects can work together to enhance the way we live, work, and play. [Learn more](https://csa-iot.org/about/)
 
 The Alliance is the owner of the Matter specification and its associated marks. We are responsible for the continued development of the specification, the certification of products, and the promotion of Matter.
 
 The Alliance is a **member driven** organization. The majority of the work on Matter is done by members with the support of their companies, and the Alliance employs a relatively small full time staff to facilitate, co-ordinate and support this work.
-

content/Alliance/howwework.md

@@ -5,6 +5,7 @@ weight = 15
 +++
 
 ### Working Groups
+
 The Alliance has a number of Working Groups responsible for each of the different standards that we manage.
 
 Matter is one such Working Group, the WG is governed by a Steering Committee. The SC manages overall activities, priorities, scope & budget of the Working Group.
@@ -17,14 +18,18 @@ The Marketing and Product Sub Group (MPSG) is responsible for capturing use case
 They also develop branding, positioning and external communications materials relating to Matter.
 
 ### Technical Sub Group
+
 The Technical Sub Group (TSG) develops the technical aspects of the Matter from the requirements given to them and takes this through specification release.
 The Matter TSG also has an active Software Development Tiger Team who maintain and develop the open source Matter SDK.
 
 ### Certification Sub Group
+
 The Certification Sub Group (CSG) develops methods to test for specification conformance, from test cases & scripts, to test events leading up to specification release.
 
 ### Tiger Teams
+
 Additionally each Sub Group forms a number of Tiger Teams to focus on a specific topic or item and feed this work up into the sub group. Some teams are ongoing, others are formed for the purpose of a specific deliverable and then dissolved.
 
 ### Joining
-Membership of each working group is open to a member company holding participant or promoter level membership. Once a member company has formally joined a WG then employees of that company can participate in the sub groups and tiger teams.
+
+Membership of each working group is open to a member company holding participant or promoter level membership. Once a member company has formally joined a WG then employees of that company can participate in the sub groups and tiger teams.

content/Alliance/membership.md

@@ -9,6 +9,7 @@ weight = 20
 Work with the world’s most innovative companies to create, evolve, and promote universal open standards that connect all IoT devices – regardless of country, network, brand, or function – for a unifying wireless experience that inspires new possibilities for people everywhere.
 
 ### Membership at a Glance
+
 Curious about which level is right for your company? Below is an overview of the four types of membership available:
 
 **Associate Members** use standards-based IoT products but do not directly build or manufacture them. To join at the Associate level and certify white-label products, a company must partner with an Alliance Participant or Promoter member through our Certification Transfer Program.

content/Alliance/resources.md

@@ -9,19 +9,21 @@ weight = 30
 If you are already a member of the Alliance, here are some helpful links found in Causeway (you'll need to log in with your member credentials).
 
 ### New Member Orientation
+
 - [Slides](https://groups.csa-iot.org/wg/members-all/document/30359)
 
 ### Group Links
+
 - [Matter Working Group](https://groups.csa-iot.org/wg/matter-wg/dashboard)
 - [How to Join the Matter Working Group and Subgroups (pg. 32-35)](https://groups.csa-iot.org/wg/members-all/document/folder/2817)
 - [Meeting Calendar for Matter Working Groups and Subroups](https://groups.csa-iot.org/wg/matter-wg/calendar) _Not seeing a calendar for a specific group? Make sure you’re a member of that group for visibility_
 
 ### Subgroups
+
 - [Matter CSG](https://groups.csa-iot.org/wg/matter-csg/dashboard)
 - [Matter MPSG](https://groups.csa-iot.org/wg/matter-mpsg/workgroup)
 - [Matter TSG](https://groups.csa-iot.org/wg/matter-tsg/dashboard)
 
 ### Tools
-- [Collaboration Tools (pg. 43-48)](https://groups.csa-iot.org/wg/members-all/document/folder/2817)
-
 
+- [Collaboration Tools (pg. 43-48)](https://groups.csa-iot.org/wg/members-all/document/folder/2817)

content/Alliance/whatwedo.md

@@ -4,13 +4,14 @@ chapter = false
 weight = 10
 +++
 
-
 ### Develop
+
 We create, evolve, and manage IoT technology standards through a well-established, collaborative process. We empower companies with practical, usable assets and tools to ease and accelerate development, freeing them to focus on new areas of IoT innovation.
 
 ### Certify
+
 Our strong certification programs help Members avoid unnecessary development cycles, ensure compliance, and validate interoperability. Certification and our stamp of approval tell the world they can buy and use Alliance-certified products and platforms with confidence.
 
 ### Promote
-We are allies for a connected future. Our membership, spanning the globe and the IoT value chain, actively seeks to promote the benefits of global, open standards, the value of the IoT to customers and consumers, and to break down the barriers to broad access and adoption of IoT technologies and solutions.
 
+We are allies for a connected future. Our membership, spanning the globe and the IoT value chain, actively seeks to promote the benefits of global, open standards, the value of the IoT to customers and consumers, and to break down the barriers to broad access and adoption of IoT technologies and solutions.

content/HowItWorks/Attestation.md

@@ -6,14 +6,16 @@ weight = 45
 
 Certified Devices are Devices that have gone through the Connectivity Standards Alliance (Alliance) Matter Certification Process.
 
-During the commissioning process, a device cryptographically proves (attests) to the commissioner that:
+During the commissioning process, a device cryptographically proves (attests) to the Commissioner that:
+
 - it is a genuine product
-- it is a product that passed Matter compliance tests and has been thus certified by CSA.
+- it is a product that passed Matter compliance tests and has been thus certified by the Alliance.
 
 In order to accomplish those goals, the device carries:
-- A Device Attestation Certificate (DAC) that conveys device's manufacturer ID (VID) and product ID (PID). The DAC chains up to a set of trusted roots, approved by CSA members.
+
+- A Device Attestation Certificate (DAC) that conveys device's manufacturer ID (VID) and product ID (PID). The DAC chains up to a set of trusted roots, approved by the Alliance members.
 - A securely-stored, private key associated with the public key stored in the DAC that proves the device owns this unique certificate.
-- Certificate declaration is a statement cryptographically signed by CSA that states that a tuple (VID,PID) has passed Matter compliance tests.
+- Certificate declaration is a statement cryptographically signed by the Alliance that states that a tuple (VID,PID) has passed Matter compliance tests.
 
 During the development phase, the manufacturer is able test their Devices without the full Attestation process. Testers should be explicitly informed that the Device is under testing, and it hasn't yet been certified and launched. Once a manufacturer enters a production phase, the ecosystem of the provisioner should enforce all Attestation requirements.
 
@@ -29,13 +31,13 @@ The DAC is a X.509 v3 certificate. The first version of X.509 was published in 1
 - Certificate Serial Number
 - Validity, where expiration can be indeterminate
 - Signature
-- Vendor ID and Product ID are attributes of the MatterDACName in the DAC subject.
+- Vendor ID and Product ID, which are attributes of the MatterDACName in the DAC subject.
 
-The DAC is unique per device and associated with the unique attestation key pair within the product. It is issued by a CA associated with the Device manufacturer.
+The DAC is unique per device and associated with the unique attestation key pair within the product. It is issued by a Certificate Authority (CA) associated with the Device manufacturer.
 
-The DAC's signature is validated against the Product Attestation Intermediate Certificate (PAI), which is also issued by a PAA. However, a vendor might choose to create one PAI per product (PID-specific), group of products, or for all its products.
+The DAC's signature is validated against the Product Attestation Intermediate Certificate (PAI), which is also issued by a Product Attestation Authority (PAA). However, a vendor might choose to create one PAI per product (PID-specific), group of products, or for all its products.
 
-At the root of the chain of trust, the Product Attestation Authority (PAA) Certificate Authority (CA) public key validates signatures from the PAI. Note that the Matter trust store is federated and the set of PAA certificates trusted by commissioners is maintained in a central trusted database (the Distributed Compliance Ledger). Entry of a PAA within the trusted set requires meeting a certificate policy managed by the Alliance.
+At the root of the chain of trust stands the PAA CA's public key, which validates signatures from the PAI. Note that the Matter trust store is federated and the set of PAA certificates trusted by commissioners is maintained in a central trusted database (the Distributed Compliance Ledger). Entry of a PAA within the trusted set requires meeting a certificate policy managed by the Alliance.
 
 ![Matter Attestation Public Key Infrastructure](../../primer-attestation-pki.png)
 
@@ -47,7 +49,7 @@ The PAI is also a X.509 v3 certificate that includes:
 - Certificate Serial Number
 - Validity, where expiration can be indeterminate
 - Signature
-- Vendor ID and Product ID (optionally) are attributes of the MatterDACName in the DAC subject.
+- Vendor ID and Product ID (optionally), which are attributes of the MatterDACName in the DAC subject.
 
 Lastly, the PAA is the root certificate in the chain and it is self-signed. It includes:
 
@@ -56,7 +58,7 @@ Lastly, the PAA is the root certificate in the chain and it is self-signed. It i
 - Issuer
 - Subject
 - Certificate Serial Number
-- Validity
+- Validity.
 
 ## Additional Attestation Documents & Messages
 
@@ -65,44 +67,50 @@ The attestation process has several documents and messages. The following items
 ![Attestation Document Hierarchy](../../primer-attestation-document-hierarchy.png)
 
 ### Certification Declaration (CD)
-The CD allows the Matter product to prove its compliance with the Matter protocol. When a product has been certified by the CSA, the product maker can request a CD from the Alliance which can then be included in the product firmware. The CD includes among other information:
+
+The CD allows the Matter product to prove its compliance with the Matter protocol. When a product has been certified by the Alliance, the product maker can request a CD from the Alliance which can then be included in the product firmware. The CD includes among other information:
+
 - VID
 - PID (one or more)
 - Server Category ID
 - Client Category ID
 - Security Level
 - Security Information
 - Certification Type (development, provisional, or official)
-- Signature
+- Signature.
 
 ### Firmware Information (optional)
+
 The Firmware Information contains the CD Version Number and one or more digests of components in the firmware, such as the OS, filesystem, bootloader. The digests may be either a hash of the software components or a hash of the signed manifests of the software components.
 
 The vendor might as well choose to include in Firmware Information only the "hash-of-hashes" of its components, instead of an array of individual hashes.
 
 Firmware Information is an optional element in the Attestation Process and applicable when a vendor has a secure boot environment which handles the Attestation key pair.
 
 ### Attestation Information
-Message sent from the Commissionee to the Commissioner. The Attestation Information combines a TLV containing the Attestation Elements and a Attestation Signature.
-Attestation Elements
 
-### This is a TLV containing:
+Message sent from the Commissionee to the Commissioner. The Attestation Information combines a Tag-Length-Value (TLV) containing the Attestation Elements and an Attestation Signature. The Attestation Elements contain the metadata related to attestation, encoded in Matter TLV, with the following fields:
+
 - Certificate Declaration
 - Timestamp
 - Attestation Nonce
 - Firmware Information (optional)
-- Vendor Specific information (optional)
+- Vendor Specific information (optional).
 
 ### Attestation Challenge
+
 Out-of-band challenge derived during Passcode Authenticated Session Establishment (PASE)/ Certificate Authenticated Session Establishment (CASE) session establishment and used to further secure the procedure and avoid replayed signatures. Comes from either CASE session, PASE session or a resumed CASE session.
 
 ### Attestation TBS (to be signed)
+
 Message containing the Attestation Elements and Attestation Challenge.
 
 ### Attestation Signature
+
 Signature of the Attestation TBS, signed using the Device Attestation Private Key.
 
 ## Attestation Procedure
+
 The Commissioner is responsible for validating attestation information from the Commissionee. It executes the following steps:
 
 1. Commissioner generates a random 32 byte attestation nonce. In cryptography jargon, a nonce (number used once) is a random number generated in the cryptographic procedure and meant to be used once.
@@ -118,4 +126,4 @@ The Commissioner is responsible for validating attestation information from the
     - Firmware Information (if present and supported by Commissioner) matches an entry in the Distributed Compliance Ledger.
     - Additional VID/PID validations also take place between the Device Basic Information Cluster, Certification Declaration and the DAC.
 
-_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_
+_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_

content/HowItWorks/Commisioning.md

@@ -14,36 +14,46 @@ At a high-level, the commissioning flow can be broken down into multiple stages:
 
 Prior to start of the Commissioning flow, the Commissionee must start advertising itself. The Commissionee may advertise itself using any of the three [Commissionable Discovery](/howitworks/discovery/#commissionable-discovery) methods. The Commissionee must also provide the onboarding payload.
 
-## 2 Connect to device (PASE)
+## 2 Connect to device using PASE
+
 Once the Commissioner has seen the advertisement and matches up the Discriminator, the Commissioner uses the passcode from the onboarding payload to do Passcode Authenticated Session Establishment (PASE) to connect to the device. This is the method to securely establish keys that both devices will be able to use to establish communication. At this step, the Commissioner also arms a fail-safe. A fail-safe provides a way to roll back the device to its original state if commissioning doesn't complete successfully.
 
 ## 3 Get Commissionee information
+
 The Commissioner reads all the descriptors from the Commissionee. The `DescriptorCluster` is on endpoint 0 of the device and describes all the other endpoints. Commissioner also reads the Basic Information Cluster which includes information like the Vendor ID, Product ID, Product Name and the Serial Number. At this step, the Commissioner also reads the device type of the Commissionee which helps drive the UX on the Commissioner side.
 
 ## 4 Regulatory config
+
 The Commissioner configures regulatory information on the Commissionee using the `SetRegulatoryConfig` command. Regulatory information includes information like configuring the location (indoor/outdoor/both) of the device or setting up the country code.
 
 ## 5 Commissionee attestation
+
 The goal of the Commissionee attestation procedure is to determine whether a device has been certified and is a genuine Matter device. Commissioner extracts the Device Attestation Certificate (DAC) and the Product Attestation Intermediate (PAI) certificate from the Commissionee. These certificates contain the Vendor ID, Product ID and Attestation Public Key. Once the certificates are received, the Commissioner does a challenge request that should be signed by the Attestation Private Key and uses that to establish the authenticity of the Commissionee.
 
 ## 6 Certificate Signing Request (CSR)
+
 The Commissioner sends a Certificate Signing Request (CSR) to the Commissionee. The Commissionee creates a unique operational key pair that will be used in a Certificate Authenticated Session Establishment (CASE) later. The Commissionee returns the resulting CSR information back to the Commissioner.
 
 ## 7 Add Node Operational Certificate (NOC)
-The Commissioner uses the CSR information received from the Commissionee and passes it to the Administrative Domain Manager (ADM) to generate a trusted Node Operational Certificate (NOC). The Commissioner installs the Root Certificate on the Commissionee using the `AddTrustedRootCertReq` command and then installs the Node Operational Certificate using the `AddNOC` command.
+
+The Commissioner uses the CSR information received from the Commissionee and passes it to the Administrative Domain Manager (ADM) to generate a trusted NOC. The Commissioner installs the Root Certificate on the Commissionee using the `AddTrustedRootCertReq` command and then installs the Node Operational Certificate using the `AddNOC` command.
 
 ## 8 Network provisioning
+
 The Commissioner configures the operational network on the Commissionee. This step is needed for Thread or Wi-Fi devices. This step is not needed for Ethernet Devices where the device is already connected to the network. It uses `ScanNetworks`, `AddOrUpdateWifiNetwork` and `ConnectNetwork` commands.
 
 ## 9 Operational discovery
+
 Once the newly commissioned node is connected to the network, the Commissioner uses [Operational Discovery](/howitworks/discovery/#operational-discovery) to find the node on the operational network. Operational discovery is the process by which commissioned nodes are found on the operational network using DNS-SD. If the Commissionee is a Wi-Fi device, it will use mDNS to discover the device.
 
 Operational discovery helps the Commissioner and other Nodes in the network know which IP address and port the Commissionee is using.
 
 ## 10 CASE session establishment
+
 Once the newly commissioned node has been discovered, a CASE session is established between the Commissioner and the device. This session is initiated by the Commissioner and is responded to by the device. In this step, operational certificates are exchanged and a shared trust is established by validating they're in the same logical fabric.
 
 ## 11 Commissioning complete
+
 The Commissioner uses CASE to send the `CommissioningComplete` command to the newly commissioned device. This is the last step in the commissioning process. `CommissioningComplete` also automatically disarms the fail-safe timer. Once commissioning is successfully completed, the device operates like any other Node on the operational network.
 
-_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_
+_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_