Apply suggestions from code review

Co-authored-by: Dan Kenigsberg <danken@gmail.com>

enhancements/network/baremetal-ipi-network-configuration.md

@@ -166,19 +166,19 @@ TODO - this will rely on metal3 image-building proposal https://github.com/metal
 
 ### Use Kubernetes-NMState NodeNetworkConfigurationPolicy custom resources
 
-If we were able to install the NNCP CRD at day-1 then we could use that as the configuration interface. This has the advantage of matching the configuration syntax and objects used for day-2 network configuration via the operator.
+If we were able to install the (NNCP CRD)[https://nmstate.io/kubernetes-nmstate/user-guide/102-configuration] at day-1 then we could use that as the configuration interface. This has the advantage of matching the configuration syntax and objects used for day-2 network configuration via the operator.
 
 However, we have been unable to get agreement on a method to deliver the operator on day-1, which makes this problematic. It's possible we could implement some way to pull just the NNCP CRD from the operator payload and isntall it on day-1, but at this point we likely don't have time to do that and it's not clear we even want to if the operator can't be installed on day-1 too. This would essentially orphan the CRs after the initial deployment completes.
 
 ### Provide raw nmstate data
 
 We could expose an interface to the user which accepts raw nmstate data (not a CR wrapper).  This would mean a common DSL to the NodeNetworkConfigurationPolicy resource, but not directly reusing that API, so there is risk of drift between the two APIs.
 
-The user would have to pass the nmstate data via the install-config, and also as a Secret for use on scale-up, then also define a NNCP resource if day-2 management of the configuration is required (which could be risky if the configuration isn't exactly the same...)
+The user would have to pass the nmstate data via the install-config, and also as a Secret for use on scale-out, then also define a NNCP resource if day-2 management of the configuration is required (which could be risky if the configuration isn't exactly the same...)
 
 #### Create a net-new NMState Wrapper CR
 
-The [assisted-service](https://github.com/openshift/assisted-service/blob/master/docs/crds/nmstate.yaml) has created a new NMState wrapper CR.
+The [assisted-service](https://github.com/openshift/assisted-service/blob/0b0e3677ae83799151d11f1267cbfa39bb0c6f2e/docs/hive-integration/crds/nmstate.yaml) has created a new NMState wrapper CR.
 
 We probably want to avoid a proliferation of different CR wrappers for nmstate
 data, but one option would be to convert that (or something similar) into a common