Merge pull request #711 from Abdulbois/#703-Conformance-with-matter-spec-Model-module

Achieve conformance against Matter spec - Model and Compliance modules

Author: Abdulbois

README-DEV.md

@@ -131,7 +131,7 @@ Have a look at [How To](docs/how-to.md) and [transactions](docs/transactions.md)
 
 Start a local pool as described above.
 
-Every node exposes a REST API at `http://<node-host>:1317` (see <https://docs.cosmos.network/v0.45/core/grpc_rest.html>).
+Every node exposes a REST API at `http://<node-host>:1317` (see <https://docs.cosmos.network/sdk/v0.47/learn/advanced/grpc_rest>).
 
 Have a look at [transactions](docs/transactions.md) for a full list of REST endpoints.
 

README.md

@@ -141,7 +141,7 @@ See [Run Light Client Proxy](docs/running-light-client-proxy.md) for details how
 
 - **There are no state proofs in REST, so REST queries should be sent to trusted Validator or Observer nodes only.**
 - OpenAPI specification: <https://zigbee-alliance.github.io/distributed-compliance-ledger/>.
-- Any running node exposes a REST API at port `1317`. See <https://docs.cosmos.network/v0.47/learn/advanced/grpc_rest>.
+- Any running node exposes a REST API at port `1317`. See <https://docs.cosmos.network/sdk/v0.47/learn/advanced/grpc_rest>.
 - See [transactions](docs/transactions.md) for a full list of endpoints.
 - REST HTTP(S) queries can be directly used for read requests.
   See [How to read from the Ledger](docs/transactions.md#how-to-read-from-the-ledger).
@@ -152,14 +152,14 @@ See [Run Light Client Proxy](docs/running-light-client-proxy.md) for details how
 ### gRPC
 
 - **There are no state proofs in gRPC, so gRPC queries should be sent to trusted Validator or Observer nodes only.**
-- Any running node exposes a REST API at port `9090`. See <https://docs.cosmos.network/v0.47/learn/advanced/grpc_rest>.
+- Any running node exposes a REST API at port `9090`. See <https://docs.cosmos.network/sdk/v0.47/learn/advanced/grpc_rest>.
 - A client code can be generated for all popular languages from the proto files [proto](proto), see <https://grpc.io/docs/languages/>.
 - The generated client code can be used for read and write requests, i.e. generation and signing of transactions
   See [How to read from the Ledger](docs/transactions.md#how-to-read-from-the-ledger) and [How to write to the Ledger](docs/transactions.md#how-to-write-to-the-ledger) for details.
 
 ### CometBFT RPC and Light Client
 
-- CometBFT RPC is exposed by every running node  at port `26657`. See <https://docs.cosmos.network/v0.47/learn/advanced/grpc_rest#cometbft-rpc>.
+- CometBFT RPC is exposed by every running node  at port `26657`. See <https://docs.cosmos.network/sdk/v0.47/learn/advanced/grpc_rest#cometbft-rpc>.
 - CometBFT RPC supports state proofs. CometBFT's Light Client library can be used to verify the state proofs.
     So, if Light Client API is used, then it's possible to communicate with non-trusted nodes.
 - Please note, that multi-value queries don't have state proofs support and should be sent to trusted nodes only.
@@ -232,4 +232,4 @@ the following instructions from [how-to.md](docs/how-to.md) can be used for ever
 - [CometBFT](https://cometbft.com/)
 - [Cosmos SDK](https://cosmos.network/sdk)
 - [Ledger Nano Support](docs/ledger-nano.md)
-- [Schema Mappings against CHIP/Matter Specification](docs/mapping_against_matter_spec.md)
+- [Mapping DCL Entities to Matter Specification](docs/mapping_against_matter_spec.md)

docs/advanced/running-node-in-existing-network.md

@@ -143,4 +143,4 @@ Possible options when adding Validator, Observer, Sentry or Seed nodes to existi
   - Probably error-prone (if at least one migration has a bug, catchup fails)
 
 - References:
-  - <https://docs.cosmos.network/v0.45/core/upgrade.html#syncing-a-full-node-to-an-upgraded-blockchain>
+  - <https://docs.cosmos.network/sdk/v0.47/learn/advanced/upgrade#syncing-a-full-node-to-an-upgraded-blockchain>

docs/cometbft-rpc.md

@@ -127,7 +127,7 @@ dcld tx auth propose-add-account \
 
 ### Decoding The Transaction String 
 
-The details of transaction payload encoding can be found [here](https://docs.cosmos.network/main/core/encoding#transaction-encoding). Thus, the transaction payload/string in the example above can be decoded as follows:
+The details of transaction payload encoding can be found [here](https://docs.cosmos.network/sdk/v0.47/learn/advanced/encoding#transaction-encoding). Thus, the transaction payload/string in the example above can be decoded as follows:
 
 ```bash
 dcld tx decode CocCCoQCCkgvemlnYmVlYWxsaWFuY2UuZGlzdHJpYnV0ZWRjb21wbGlhbmNlbGVkZ2VyLmRjbGF1dGguTXNnUHJvcG9zZUFkZEFjY291bnQStwEKLWNvc21vczE0cG1nMnhnMzd0enI2a3VxNHV4dnp3a3p1ZnRldGQ3dDhhMnN1dRItY29zbW9zMXNkZzV2a3B6OXVyY2VtbXc2N2xueHZ6aGh1dmVxZTZ2NzBleDJsGkYKHy9jb3Ntb3MuY3J5cHRvLnNlY3AyNTZrMS5QdWJLZXkSIwohA4m98FT/tgsMWZuVBlavWmawwXrvv/nUMhDlU8QsHlOMIglOb2RlQWRtaW44lo/YoAYSWApQCkYKHy9jb3Ntb3MuY3J5cHRvLnNlY3AyNTZrMS5QdWJLZXkSIwohApEHaI8+Wj64IQdR/WZDMaWHNd53+9G19zNcWjrAiXMbEgQKAggBGAISBBDAmgwaQJCg0T8phCo70H7VpL2M1C0kQix4LeVOjkXWgK3EHmFobXkBGLH2jJiKTHakVWUO2yj2Tdpc4YoTDw2eKe6UZj8=

docs/design/benchmarking.md

@@ -42,9 +42,9 @@ The following ones makes sense to track:
 
 ### Cosmos SDK metrics
 
-Starting from `v0.40.0` Cosmos SDK provides [telemetry](https://docs.cosmos.network/v0.45/core/telemetry.html) package as a server-side support for application performance and behavior explorations.
+Starting from `v0.40.0` Cosmos SDK provides [telemetry](https://docs.cosmos.network/sdk/v0.47/learn/advanced/telemetry) package as a server-side support for application performance and behavior explorations.
 
-The following [metrics](https://docs.cosmos.network/v0.45/core/telemetry.html#supported-metrics) make sense to track:
+The following [metrics](https://docs.cosmos.network/sdk/v0.47/learn/advanced/telemetry#supported-metrics) make sense to track:
 
 - `tx_count`: Total number of txs processed via DeliverTx (tx)
 - `tx_successful`: Total number of successful txs processed via DeliverTx  (tx)
@@ -67,7 +67,7 @@ Notes:
 
 - For the moment it's not clear enough what production setup will look like, in particular:
   - number of validators
-  - type of external endpoints, options are [Cosmos SDK / Tendermint endpoints](https://docs.cosmos.network/v0.45/core/grpc_rest.html)
+  - type of external endpoints, options are [Cosmos SDK / Tendermint endpoints](https://docs.cosmos.network/sdk/v0.47/learn/advanced/grpc_rest)
   - type and number of proxies for validator-validator and client-validator connections
 
 Current assumptions for production:
@@ -94,7 +94,7 @@ Current assumptions for production:
 
 **ToDo** define which client endpoints are considered in production
 
-As long as CosmosSDK (Tendermint) provides multiple client [endpoints](https://docs.cosmos.network/v0.45/core/grpc_rest.html) makes sense to benchmark all of them (separately and in a combination), in particular:
+As long as CosmosSDK (Tendermint) provides multiple client [endpoints](https://docs.cosmos.network/sdk/v0.47/learn/advanced/grpc_rest) makes sense to benchmark all of them (separately and in a combination), in particular:
 
 - http RPC
 - websocket RPC
@@ -114,7 +114,7 @@ As long as CosmosSDK (Tendermint) provides multiple client [endpoints](https://d
 
 ## Load Generation Framework
 
-As long as DCledger based on Cosmos SDK and Tendermint which provide standard HTTP/websocket RPC and REST  [endpoints](https://docs.cosmos.network/v0.45/core/grpc_rest.html) to perform both read & write txns generic production ready tools like [jMeter](https://jmeter.apache.org/), [Locust](https://locust.io/), [K6](https://k6.io/) may be used.
+As long as DCledger based on Cosmos SDK and Tendermint which provide standard HTTP/websocket RPC and REST  [endpoints](https://docs.cosmos.network/sdk/v0.47/learn/advanced/grpc_rest) to perform both read & write txns generic production ready tools like [jMeter](https://jmeter.apache.org/), [Locust](https://locust.io/), [K6](https://k6.io/) may be used.
 
 [Locust](https://locust.io/) looks like the most easy-to-go option:
 

docs/design/schema-compatibility.md

@@ -50,7 +50,7 @@ While offering a robust solution for handling radical changes, this method requi
 **Strategy steps:**
 
 - One time actions:
-  - Create a more flexible, generic schema structure to hold a wide range of data formats (Can be used [Any](https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/any.proto) as described in [ADR-19](https://docs.cosmos.network/v0.47/build/architecture/adr-019-protobuf-state-encoding#usage-of-any-to-encode-interfaces))
+  - Create a more flexible, generic schema structure to hold a wide range of data formats (Can be used [Any](https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/any.proto) as described in [ADR-19](https://docs.cosmos.network/sdk/v0.53/build/architecture/adr-019-protobuf-state-encoding#usage-of-any-to-encode-interfaces))
   - Migrate old states to the newer, generic schema.
   - Remove the states associated with the older schema versions.
   - Optioanlly can be implemented queries for requesting schemas with any return type

docs/mapping_against_matter_spec.md

@@ -1,14 +1,42 @@
-# Mapping DCL Schemas to Matter Specification
+# Mapping DCL Entities to Matter Specification
 
-This document describes how DCL records and entities map to the CHIP/Matter [specification](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#ref_DistributedComplianceLedger).
+This document describes how DCL records and entities map to the Matter [specification](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#ref_DistributedComplianceLedger).
 
-In DCL, different schemas and respective endpoints are used for write(txn messages) and read(query calls) requests, but the CHIP/Matter specification describes only what was written and assumes that
-read requests are the same. To know about how write and read requests maps to spec please follow below sections for more details.
+In DCL, different schemas and respective endpoints are used for write (txn messages) and read (query calls) requests, but the Matter specification describes only what was written and assumes that read requests are the same. To know about how write and read requests map to spec, please follow the sections below for more details.
 
 ## PKI Module
 
-1. **Device Attestation (DA):** The Product Attestation Authority (PAA) and Intermediate (PAI) certificate [schemas](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#ref_PAAAndPAICertificateSchema) correspond to the [DA certificate types section](transactions.md#x509-pki).
-2. **Operational Trust Anchors:** The [schemas](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#5-operational-trust-anchors-schema) for Operational Certificates correspond to the [NOC certificate types section](transactions.md#x509-pki).
+1. DCL uses a single [Certificate](../proto/zigbeealliance/distributedcomplianceledger/pki/certificate.proto) entity for all(`PAA`,`PAI`,`RCAC` and `ICAC`) certificate types mentioned in the Matter specification.
+2. Associated `write/read` requests regarding the Product Attestation Authority (PAA) and Intermediate (PAI) certificate [schemas](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#ref_PAAAndPAICertificateSchema) can be found in the [DA certificate types section](transactions.md#x509-pki).
+3. Associated `write/read` requests regarding the Operational Certificates [schemas](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#5-operational-trust-anchors-schema) can be found in the [NOC certificate types section](transactions.md#x509-pki).
     *   **Note:** DCL uses the terms **NOC** and **ICA**, which map to **RCAC** and **ICAC** in the Matter specification, respectively.
-3. **Unified Schema:** DCL uses a single [Certificate](../proto/zigbeealliance/distributedcomplianceledger/pki/certificate.proto) schema for all certificate types mentioned in the Matter specification.
-4. **Revocation:** Device Attestation PKI Revocation Distribution Points [schema](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#9-device-attestation-pki-revocation-distribution-points-schema) are implemented within the PKI Module as described in the [revocation points section](transactions.md#x509-pki).
+4. Device Attestation PKI Revocation Distribution Points [schema](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#9-device-attestation-pki-revocation-distribution-points-schema) correspond to [PKI Revocation Distribution Point](../proto/zigbeealliance/distributedcomplianceledger/pki/pki_revocation_distribution_point.proto) entity and the associated `write/read` requests can be found in the [revocation points section](transactions.md#x509-pki).
+
+## Model Module
+
+In DCL, the [Model module](transactions/model.md) is responsible to handle records regarding device and device software version models.
+
+1. The [Device Model schema](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#ref_DeviceModelSchema) corresponds to the [Model](../proto/zigbeealliance/distributedcomplianceledger/model/model.proto) entity, and the associated `write/read` requests can be found in the [Model and Model Version section](transactions.md#model-and-model-version).
+2. The [Device Software Version Model schema](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#7-devicesoftwareversionmodel-schema) corresponds to the to [Model Version](../proto/zigbeealliance/distributedcomplianceledger/model/model_version.proto) entity, and the associated `write/read` requests can be found in the [Model and Model Version section](transactions.md#model-and-model-version).
+
+## Compliance Module
+
+In DCL, the [Compliance module](transactions/compliance.md) is responsible to handle certification status of particular software version(`Model Version` in DCL term) for given product(`Model` in DCL term).
+
+Below is the list of notes to consider while mapping DCL Compliance module to Matter specification:
+1. The [Device Software Compliance schema](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#8-devicesoftwarecompliance--compliance-test-result-schema) corresponds to the [Compliance Info](../proto/zigbeealliance/distributedcomplianceledger/compliance/compliance_info.proto) entity, and the associated `write/read` requests can be found in the [Compliance section](transactions.md#compliance)
+2. In DCL, specific endpoints are used (by CSA) to handle [certification status](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#82-softwareversioncertificationstatusenum-type) of the device software version according to the provided `certificatType`(ZB/Matter):
+   - [Provision](transactions/compliance.md#PROVISION_MODEL) endpoint is used to register that particular device software is in `provisional` (going into certification testing phase) state
+      * **Note:** This endpoint **cannot** be used for device software versions that are already in `compliant` or `revoked` state
+   - [Certify](transactions/compliance.md#CERTIFY_MODEL) endpoint is used to register that particular device software version is in `compliant` state
+      * **Note:** This endpoint **can** be used for device software versions that are already in `provisional` or `revoked` state (e.g. re-certification)
+   - [Revoke](transactions/compliance.md#REVOKE_MODEL_CERTIFICATION) endpoint is used to register that particular device software version is `revoked`
+     * **Note:** This endpoint **can** be used for device software versions that are already in `provisional` or `compliant` state
+   - [Update](transactions/compliance.md#UPDATE_COMPLIANCE_INFO) endpoint is used to update the additional-info/metadata of a particular device software version
+     * **Note:** This endpoint **cannot** be used to change the certification status
+3. In DCL, there are several query endpoints can be used for specific reading purposes.
+   - [Provisional Model](transactions/compliance.md#GET_PROVISIONAL_MODEL) can be used to retrieve/check the software version certification of particular device is in `provisional` state
+   - [Certified Model](transactions/compliance.md#GET_CERTIFIED_MODEL) can be used to retrieve/check the software version certification of particular device in `compliant` state
+   - [Revoked Model](transactions/compliance.md#GET_REVOKED_MODEL) can be used to retrieve/check the software version certification of particular device in `revoked` state
+   - [Compliance Info](transactions/compliance.md#GET_COMPLIANCE_INFO) can be used to get the full compliance(including certification state) information of a particular device software version, bypassing state check query calls mentioned above
+   - [Device Software Compliance](transactions/compliance.md#GET_DEVICE_SOFTWARE_COMPLIANCE) can be used to get all compliance records associated with [CD Certificate ID](https://github.com/CHIP-Specifications/connectedhomeip-spec/blob/master/src/service_device_management/DistributedComplianceLedger.adoc#83-cdcertificateid)

docs/monitoring.md

@@ -5,7 +5,7 @@
 As long as DCLedger is built on top of Cosmos SDK and Tendermint their monitoring abilities can be considered for DCLedger as well.
 
 * Starting from `v0.21.0` Tendermint provides Prometheus compatible [metrics](https://docs.tendermint.com/v0.34/tendermint-core/metrics.html).
-* Starting from `v0.40.0` Cosmos SDK provides [telemetry](https://docs.cosmos.network/v0.45/core/telemetry.html) package as a server-side support for application performance and behavior explorations.
+* Starting from `v0.40.0` Cosmos SDK provides [telemetry](https://docs.cosmos.network/sdk/v0.47/learn/advanced/telemetry) package as a server-side support for application performance and behavior explorations.
 
 ## Installation & Configuration
 

docs/static/openapi.yml

@@ -8804,7 +8804,7 @@ paths:
                     enhancedSetupFlowTCFileSize:
                       type: integer
                       format: int64
-                    maintenanceUrl:
+                    enhancedSetupFlowMaintenanceUrl:
                       type: string
                     discoveryCapabilitiesBitmask:
                       type: integer
@@ -9058,7 +9058,7 @@ paths:
                   enhancedSetupFlowTCFileSize:
                     type: integer
                     format: int64
-                  maintenanceUrl:
+                  enhancedSetupFlowMaintenanceUrl:
                     type: string
                   discoveryCapabilitiesBitmask:
                     type: integer
@@ -23539,7 +23539,7 @@ definitions:
       enhancedSetupFlowTCFileSize:
         type: integer
         format: int64
-      maintenanceUrl:
+      enhancedSetupFlowMaintenanceUrl:
         type: string
       discoveryCapabilitiesBitmask:
         type: integer
@@ -23700,7 +23700,7 @@ definitions:
             enhancedSetupFlowTCFileSize:
               type: integer
               format: int64
-            maintenanceUrl:
+            enhancedSetupFlowMaintenanceUrl:
               type: string
             discoveryCapabilitiesBitmask:
               type: integer
@@ -23808,7 +23808,7 @@ definitions:
           enhancedSetupFlowTCFileSize:
             type: integer
             format: int64
-          maintenanceUrl:
+          enhancedSetupFlowMaintenanceUrl:
             type: string
           discoveryCapabilitiesBitmask:
             type: integer