style/cosmetics

Author: paullatzelsperger

README.md

@@ -60,7 +60,7 @@ It must be stated in the strongest terms that this is **NOT** a production grade
 production-grade developments be based on it. [Shortcuts](#10-other-caveats-shortcuts-and-workarounds) were taken, and
 assumptions were made that are potentially invalid in other scenarios.
 
-It merely is a playground for developers wanting to kick the tires in the EDC and DCP space, and its purpose is to
+It is merely a playground for developers wanting to kick the tires in the EDC and DCP space, and its purpose is to
 demonstrate how DCP works to an otherwise unassuming audience.
 
 ### 2.1 Version stability and backwards compatibility guarantees
@@ -88,19 +88,19 @@ anything, then you'll get the absolute latest version of MVD. This is suitable f
 frequently and with the occasional breakage. The upshot is that this branch will always contain the latest features and
 fixes of all upstream components.
 
-> We have monitoring systems im place that inform us about broken builds. No need to raise issues about this.
+> We have monitoring systems in place that inform us about broken builds. No need to raise issues about this.
 
 More conservative developers may fall back
 to [releases of MVD](https://github.com/eclipse-edc/MinimumViableDataspace/releases) that use release versions of all
 upstream components. If this is you, then remember to check out the appropriate tag after cloning the repo.
 
 Either download the ZIP file and use sources therein, or check out the corresponding tag.
 
-An MVD release version is typically created shortly after a release of the upstream components was released.
+An MVD release version is typically created shortly after an upstream components release.
 
 ## 3. The Scenario
 
-_In this example, we will see how two companies can share data using DSP and DCP. Each company deploys its own
+In this example, we will see how two companies can share data using DSP and DCP. Each company deploys its own
 connector, IdentityHub, and base infrastructure.
 
 ### 3.1 Participants
@@ -132,7 +132,7 @@ In this fictitious dataspace there are two types of VerifiableCredentials:
   the holder is allowed to manufacture. This is defined in the `"part_types"` field in the credential subject. The
   following variants exist:
     - `"part_type": "non_critical"`: means, the holder can manufacture non-critical parts
-    - `"part_type" : "all"`: means, the holder can manufacture everything including saftey critical parts
+    - `"part_type" : "all"`: means, the holder can manufacture everything including saftey-critical parts
 
   The information about the level of the holder is stored in the `credentialSubject` of the
   ManufacturerCredential.
@@ -210,7 +210,7 @@ is required. It is assumed that the following tools are installed and readily av
 - Git
 - a POSIX compliant shell
 - Bruno (to comfortably execute REST requests)
-- not needed, but recommended: Kubernetes monitoring tools like K9s
+- optional, but recommended: Kubernetes monitoring tools like K9s
 
 All commands are executed from the **repository's root folder** unless stated otherwise via `cd` commands.
 
@@ -307,7 +307,7 @@ The provider company has a control plane, a dataplane, plus an IdentityHub, a po
 
 In addition, there is the Issuer service, which is responsible for issuing Verifiable Credentials.
 
-It is possible that pods need to restart a number of time before the cluster becomes stable. This is normal and
+It is possible that pods need to restart a number of times before the cluster becomes stable. This is normal and
 expected. If pods _don't_ come up after a reasonable amount of time, it is time to look at the logs and investigate.
 
 Remote Debugging is possible, but Kubernetes port-forwards of port 1044 are necessary.
@@ -410,14 +410,13 @@ similar to this:
 },
 ```
 
-for the purposes of this tutorial we'll focus on the offers from the Provider's Q&A department, so the associated
-service entry should be:
+the associated service entry for the Provider's asset should be:
 
 ```json
 {
   "dcat:service": {
     // ...
-    "dcat:endpointUrl": "http://provider-qna-controlplane:8082/api/dsp",
+    "dcat:endpointUrl": "http://controlplane.provider.svc.cluster.local:8082/api/dsp/2025-1",
     "dcat:endpointDescription": "dspace:connector"
     // ...
   }
@@ -435,7 +434,7 @@ into the `policy.@id` field of the `ControlPlane Management/Initiate Negotiation
 ```json
 //...
 "counterPartyId": "{{PROVIDER_ID}}",
-"protocol": "dataspace-protocol-http",
+"protocol": "dataspace-protocol-http:2025-1",
 "policy": {
 "@type": "Offer",
 "@id": "bWVtYmVyLWFuZC1wY2YtZGVm:YXNzZXQtMQ==:MThhNTgwMzEtNjE3Zi00N2U2LWFlNjMtMTlkZmZlMjA5NDE4",
@@ -553,7 +552,7 @@ These are:
 ### 7.2 Regenerating key pairs
 
 Participant keys are dynamically generated by IdentityHub, so there is no need to pre-generate them. In fact,
-everytime the dataspace is re-deployed and the seed jobs are executed, a new key pair is generated for each participant.
+every time the dataspace is re-deployed and the seed jobs are executed, a new key pair is generated for each participant.
 To be extra-precise, the keys are regenerated when a new `ParticipantContext` is created.
 
 At runtime, a participant's key pair(s) can be regenerated and revoked using