Apply reviewer notes

specs/deployment-repo-update.md

@@ -2,29 +2,32 @@
 
 ## Summary
 
-The GitOps driven continuous deployment cycle starts with a change in the Git repository that contains resource manifests. The [Flux] provides the
+The GitOps driven continuous deployment cycle starts with a change in the Git repository that contains resource manifests. Flux provides the
 [Automated Image Update](https://docs.fluxcd.io/en/latest/references/automated-image-update.html) feature that continuously monitors the docker registry and automatically
-updates deployment repo when a new image is released. Obviously that functionality is not available for  Argo CD users.
-Also cannot or don't want to use docker-registry monitoring and only need functionality related to the Git repository update.
+updates deployment repo when a new image is released. This functionality is not available for Argo CD users. Also, some Argo CD users need only functionality related to the
+Git repository updating and don't need docker registry monitoring.
 
 This document is meant to collect requirements for the Git repository update functionality. As a next step, we could discuss if it is possible to implement a Golang library or
 a service that can be used in combination with Argo CD and Flux.
 
+> Note: Flux already plans to split out the docker registry monitor and image updating feature into a separate component. We should consider re-using the extracted component.
+
 ## Requirements
 
-### Manifests updating.
+### Manifests updating
 
-After new images are discovered the resource manifests of each workflow referencing the image have to be updated. The manifests might be stored as raw YAML files or as the templating tool package such as Kustomize or Helm. The manifest updating functionality should take new images
+When updates are discovered for any image referenced in resource manifests in the configuration repository, new manifests that refer to the updated image tags/versions must be generated.
+The manifests might be stored as raw YAML files or as the templating tool package such as Kustomize or Helm. The manifest updating functionality should take new images
 set as an input and update manifest files or templating tool configs to use the provided set of images.
 
 ### Commit signing
 
-The user might want to use GPC signing for each commit in the deployment repo. The commit signing feature should allow to optionally
+The user might want to use GPG signing for each commit in the deployment repo. The commit signing feature should allow to optionally
 sign the commit with the image changes.
 
-### Git interaction
+### Interaction with Git
 
-The Git interaction feature provides the following basic functionalities:
+The feature provides the following basic functionalities:
 * Clone Git repo or update the local copy of a previously cloned copy
 * Configure local Git user name and email.
 * Push changes back to Git remote repo.

specs/image-update-monitoring.md

@@ -4,27 +4,26 @@
 
 Many GitOps users would like to automate Kubernetes manifest changes in the deployment repository
 (see [Deployment Repo Update Automation](./deployment-repo-update.md)). The changes might be triggered by
-the CI pipeline run or a new image in the Docker registry. The [Flux] provides the docker registry monitoring as part of
-[Automated Image Update](https://docs.fluxcd.io/en/latest/references/automated-image-update.html) feature but that functionality
-is not available for non-Flux users and cannot be leveraged in manifests are generated by a script (e.g. jsonnet).
+the CI pipeline run or a new image in the Docker registry. Flux provides docker registry monitoring as part of
+[Automated Image Update](https://docs.fluxcd.io/en/latest/references/automated-image-update.html) feature.
 
 This document is meant to collect requirements for a component that provides docker registry monitoring functionality and 
 can be used by Argo CD and potentially Flux users.
 
 ## Requirements
 
-### Configurable Event Handle
+### Configurable Event Handler
 
-When a new docker image is discovered the component should execute a pre-configured event handler and pass the docker image name/version as a parameter. The handler should be
-configured in a form of a shell script.
+When a new docker image is discovered the component should execute an event handler and pass the docker image name/version as a parameter.
+The event handler is a shell script. The user should be able to specify the handler in the component configuration.
 
 ### Docker Registry WebHooks
 
 Some Docker Registries send a webhook when a new image gets pushed. The component should provide a webhook handler which when invokes an event handler.
 
 ### Image Pulling
 
-In addition to the webhook, the component should support image pulling. The pulling should detect the new images and invoke an event handler for each new image.
+In addition to the webhook, the component should support images metadata pulling. The pulling should detect the new images and invoke an event handler for each new image.
 
 ### Image Credentials Auto-Discovering