Fixing links

Author: iriark01

docs/api/networkinterfaces/MeshInterface.md

@@ -10,7 +10,7 @@ Mbed OS provides three types of IPv6 based mesh networks:
 - Wi-SUN, following the specification from Wi-SUN alliance.
 - Thread, following the specification from Thread Group.
 
-Nanostack is the networking stack that provides these protocols. For more information on the stack internals, please refer to the [Thread](../reference/thread.html), [Wi-SUN](../reference/wi-sun.html) and [6LowPAN](../reference/mesh-tech.html) sections. Application developers use Nanostack through the Mbed Mesh API.
+Nanostack is the networking stack that provides these protocols. For more information on the stack internals, please refer to the [Thread](../reference/thread-tech.html), [Wi-SUN](../reference/wisun-tech.html) and [6LowPAN](../reference/mesh-tech.html) sections. Application developers use Nanostack through the Mbed Mesh API.
 
 The application can use the `LoWPANNDInterface`, `WisunInterface` or `ThreadInterface` object for connecting to the mesh network. When successfully connected, the application can use the Mbed [C++ socket APIs](network-socket.html) to create a socket to start communication with a remote peer.
 
@@ -46,8 +46,8 @@ To learn how to use mesh, please see our [light control tutorial](../tutorials/l
 
 ### Related content
 
-- [Thread](../reference/thread.html) technology reference material.
-- [Wi-SUN](../reference/wi-sun.html) technology reference material.
+- [Thread](../reference/thread-tech.html) technology reference material.
+- [Wi-SUN](../reference/wisun-tech.html) technology reference material.
 - [6LowPAN](../reference/mesh-tech.html) technology reference material.
 - [6LoWPAN, Wi-SUN and Thread Mesh configuration documentation](../reference/configuration-mesh.html).
 - [Light control tutorial](../tutorials/light-control.html).

docs/api/security/psa_lifecycle.md

@@ -13,7 +13,7 @@ The following is a state machine depiction of the PSA lifecycle:
 
 You can specify the lifecycle value during build time using the `MBED_CONF_LIFECYCLE_STATE` macro. The default lifecycle value is `PSA_LIFECYCLE_ASSEMBLY_AND_TEST`.
 
-In Mbed OS, the PSA lifecycle is implemented as part of the [platform service](../apis/platform-service.html).
+In Mbed OS, the PSA lifecycle is implemented as part of the platform service.
 
 ### PSA lifecycle reference
 

docs/reference/configuration/mesh.md

@@ -9,8 +9,8 @@ This guide is divided in sections, and generic Nanostack configurations are firs
 For understanding the technologies and APIs, please refer to following sections before this one:
 
 - [Network connectivity in Mbed OS](../reference/networking.html) technology page.
-- [Thread](../reference/thread.html) technology reference page.
-- [Wi-SUN](../reference/wi-sun.html) technology reference page.
+- [Thread](../reference/thread-tech.html) technology reference page.
+- [Wi-SUN](../reference/wisun-tech.html) technology reference page.
 - [6LowPAN](../reference/mesh-tech.html) technology reference page.
 - [Mesh class reference](../apis/mesh-api.html) user API.
 - [Socket API](../apis/network-socket.html).

docs/reference/contributing/guidelines/workflow.md

@@ -100,7 +100,7 @@ Release: patch
 
 A functionality change can be any change in the functionality, including adding a new feature, a new method or a function. Software language does not matter.
 
-A feature contribution contains a new API, capability or behavior. It does not break backward compatibility with existing APIs, capabilities or behaviors. New feature contributions are very welcome in Mbed OS. However, because they add capability to the codebase, it's easy for a new feature to introduce bugs and a support burden. The introduction of new features should also come with documentation, majority of targets support and comprehensive test coverage proving the correctness of the feature per the documentation. Feature PRs are treated cautiously, and new features require a new minor version for the codebase. Features are candidates for feature releases. 
+A feature contribution contains a new API, capability or behavior. It does not break backward compatibility with existing APIs, capabilities or behaviors. New feature contributions are very welcome in Mbed OS. However, because they add capability to the codebase, it's easy for a new feature to introduce bugs and a support burden. The introduction of new features should also come with documentation, majority of targets support and comprehensive test coverage proving the correctness of the feature per the documentation. Feature PRs are treated cautiously, and new features require a new minor version for the codebase. Features are candidates for feature releases.
 
 Every pull request changing or adding functionality must contain a release notes section called "Release notes" to describe the changes to users.
 
@@ -112,7 +112,7 @@ It must contain:
 
 <span class="notes">**Note:** We may use this content in our official release notes.</span>
 
-For more details, please see the [pull request template addition for functional changes](./pull_request_drafts/pr_functional_change.md).
+For more details, please see the [pull request template addition for functional changes](../pull_request_drafts/pr_functional_change.md).
 
 We initially implement new features on separate branches in the Mbed OS repository. Mbed OS maintainers create the new branches by following the naming convention: "feature-" prefix.
 
@@ -151,7 +151,7 @@ It must contain:
 
 <span class="notes">**Note:** We may use this content in our official release notes.</span>
 
-For more details, please see the [pull request template addition](./pull_request_drafts/pr_breaking_change.md).
+For more details, please see the [pull request template addition](../pull_request_drafts/pr_breaking_change.md).
 
 A project technical lead and the Mbed OS technical lead must approve breaking change pull requests.