Fix typos

Signed-off-by: Joe Nathan Abellard <contact@jabellard.com>

docs/proposals/operator-custom-crd-download-url/README.md

@@ -43,16 +43,16 @@ is identical to that of the operator's release version, which may not always be
 those components should have the same version as the operator's release version. In that scenario, the assumption is justified and holds true. However, when creating a new Karmada instance, it's possible to explicitly
 specify the version of the control plane components. In that scenario, this assumption breaks, and we encounter the risk of the operator installing the wrong CRDs for that Karmada instance.
 
-The default behavior is sensible and can be retained. However, it should not be the behavior when the intent is to create a new Karmada instance with control plane components of a different version than that of the operator's release version. 
+The default behavior is sensible and will be retained. However, it should not be the behavior when the intent is to create a new Karmada instance with control plane components of a different version than that of the operator's release version. 
 To support that scenario, we require the ability to explicitly set, as part of the Karmada resource, the URL that should be used to download the CRDs tarball for that Karmada instance.
 
 In addition to making sure required CRDs are downloaded, the Karmada operator also employs a caching strategy to avoid re-downloading CRDs it has already downloaded. It's a cache on the local file system.
-Downloaded CRDs are stored at a well-known location on the local file system based the release version of the Karmada operator. When provisioning a new Karmada instance, before attempting to download CRDs, the operator will fist check if
+Downloaded CRDs are stored at a well-known location on the local file system based the release version of the Karmada operator. When provisioning a new Karmada instance, before attempting to download the required CRDs, the operator will fist check if
 they already exist in the cache. To support custom CRD download URLs, we require this caching strategy be extended to be more generic.
 
 ## Design Details
 
-To support downloading CRDs from a custom location, we need to add a new field called `CRDRemoteURL` to the Karmada resource spec:
+To support downloading CRDs from a custom URL, we need to add a new field called `CRDRemoteURL` to the Karmada resource spec:
 ```go
 type KarmadaSpec struct {
 	HostCluster *HostCluster `json:"hostCluster,omitempty"`
@@ -75,5 +75,5 @@ The default downloading strategy is sensible and will be retained. As such, this
 release version, it should be left unspecified as part of the Karmada resource. Otherwise, it should be explicitly set to the URL from which the CRDs tarball should be downloaded when provisioning the Karmada instance.
 
 Currently, the cache for previously downloaded CRDs lives on the local file system at `/var/lib/karmada/<operator-release-version>`. To support custom CRD download URLs, we need to a new directory structure for the cache.
-The Karmada operator can potentially be managing the lifecycle of multiple Karmada instances with heterogeneous versions, and as such, may have to download CRD tarballs from multiple URLs. We need to cache the CRDs for each URL.
+The Karmada operator can potentially be managing the lifecycle of multiple Karmada instances of heterogeneous versions, and as such, may have to download CRD tarballs from multiple URLs. We need to cache the CRDs for each URL.
 Given some URL, it's cache entry will live on the local file system at path `/var/lib/karmada/cache/<cache-key>`. The cache key will be the computed MD5 hash of that URL after all leading and trailing white space has been removed.