fix dead links

spec/core/v2/ics-002-client-semantics/README.md

@@ -70,7 +70,7 @@ could be provided as executable WASM functions when the client instance is creat
 
 ### Definitions
 
-- `get`, `set`, `Path`, and `Identifier` are as defined in [ICS 24](../ics-024-host-requirements).
+- `get`, `set`, `Path`, and `Identifier` are as defined in [ICS 24]( ../../ics-024-host-requirements).
 
 - `Consensus` is a state update generating algorithm. It takes the previous state of a state machine together 
   with a set of messages (i.e., state machine transactions) and generates a valid state update of the state machine.
@@ -95,7 +95,7 @@ types may require additional properties.
 - `Height` specifies the order of the state updates of a state machine, e.g., a sequence number. 
   This entails that each state update is mapped to a `Height`.
 
-- `CommitmentRoot` is as defined in [ICS 23](../ics-023-vector-commitments). 
+- `CommitmentRoot` is as defined in [ICS 23]( ../../ics-023-vector-commitments). 
   It provides an efficient way for higher-level protocol abstractions to verify whether
   a particular state transition has occurred on the remote state machine, i.e.,
   it enables proofs of inclusion or non-inclusion of particular values at particular paths 
@@ -149,7 +149,7 @@ This specification outlines what each *client type* must define. A client type i
 of the data structures, initialisation logic, validity predicate, and misbehaviour predicate required
 to operate a light client. State machines implementing the IBC protocol can support any number of client
 types, and each client type can be instantiated with different initial consensus states in order to track
-different consensus instances. In order to establish a connection between two state machines (see [ICS 3](../ics-003-connection-semantics)),
+different consensus instances. In order to establish a connection between two state machines (see [ICS 3]( ../../ics-003-connection-semantics)),
 the state machines must each support the client type corresponding to the other state machine's consensus algorithm.
 
 Specific client types shall be defined in later versions of this specification and a canonical list shall exist in this repository.
@@ -196,7 +196,7 @@ as misbehaviour. Should one occur, a proof should be generated and submitted so
 and previous state roots invalidated as necessary.
 
 The `ConsensusState` of a chain MUST have a canonical serialisation, so that other chains can check
-that a stored consensus state is equal to another (see [ICS 24](../ics-024-host-requirements) for the keyspace table).
+that a stored consensus state is equal to another (see [ICS 24]( ../../ics-024-host-requirements) for the keyspace table).
 
 ```typescript
 type ConsensusState = bytes
@@ -339,7 +339,7 @@ to intervene to unfreeze a frozen client & provide a new correct ClientMessage w
 
 #### `CommitmentProof`
 
-`CommitmentProof` is an opaque data structure defined by a client type in accordance with [ICS 23](../ics-023-vector-commitments).
+`CommitmentProof` is an opaque data structure defined by a client type in accordance with [ICS 23]( ../../ics-023-vector-commitments).
 It is utilised to verify presence or absence of a particular key/value pair in state
 at a particular finalised height (necessarily associated with a particular commitment root).
 
@@ -352,7 +352,7 @@ Internal implementation details may differ (for example, a loopback client could
 - The `delayPeriodBlocks` is passed to the verification functions for packet-related proofs in order to allow packets to specify a period of blocks which must pass after a consensus state is added before it can be used for packet-related verification.
 
 `verifyMembership` is a generic proof verification method which verifies a proof of the existence of a value at a given `CommitmentPath` at the specified height. It MUST return an error if the verification is not successful. 
-The caller is expected to construct the full `CommitmentPath` from a `CommitmentPrefix` and a standardized path (as defined in [ICS 24](../ics-024-host-requirements/README.md#path-space)). If the caller desires a particular delay period to be enforced,
+The caller is expected to construct the full `CommitmentPath` from a `CommitmentPrefix` and a standardized path (as defined in [ICS 24]( ../../ics-024-host-requirements/README.md#path-space)). If the caller desires a particular delay period to be enforced,
 then it can pass in a non-zero `delayPeriodTime` or `delayPeriodBlocks`. If a delay period is not necessary, the caller must pass in 0 for `delayPeriodTime` and `delayPeriodBlocks`,
 and the client will not enforce any delay period for verification.
 
@@ -369,7 +369,7 @@ type verifyMembership = (
 ```
 
 `verifyNonMembership` is a generic proof verification method which verifies a proof of absence of a given `CommitmentPath` at the specified height. It MUST return an error if the verification is not successful. 
-The caller is expected to construct the full `CommitmentPath` from a `CommitmentPrefix` and a standardized path (as defined in [ICS 24](../ics-024-host-requirements/README.md#path-space)). If the caller desires a particular delay period to be enforced,
+The caller is expected to construct the full `CommitmentPath` from a `CommitmentPrefix` and a standardized path (as defined in [ICS 24]( ../../ics-024-host-requirements/README.md#path-space)). If the caller desires a particular delay period to be enforced,
 then it can pass in a non-zero `delayPeriodTime` or `delayPeriodBlocks`. If a delay period is not necessary, the caller must pass in 0 for `delayPeriodTime` and `delayPeriodBlocks`,
 and the client will not enforce any delay period for verification.
 
@@ -512,8 +512,8 @@ security assumptions of proxy state machine correctness.
 
 ##### Merklized state trees
 
-For clients of state machines with Merklized state trees, these functions can be implemented by calling the [ICS-23](../ics-023-vector-commitments/README.md) `verifyMembership` or `verifyNonMembership` methods, using a verified Merkle
-root stored in the `ClientState`, to verify presence or absence of particular key/value pairs in state at particular heights in accordance with [ICS 23](../ics-023-vector-commitments).
+For clients of state machines with Merklized state trees, these functions can be implemented by calling the [ICS-23]( ../../ics-023-vector-commitments/README.md) `verifyMembership` or `verifyNonMembership` methods, using a verified Merkle
+root stored in the `ClientState`, to verify presence or absence of particular key/value pairs in state at particular heights in accordance with [ICS 23]( ../../ics-023-vector-commitments).
 
 ```typescript
 type verifyMembership = (ClientState, Height, CommitmentProof, Path, Value) => boolean

spec/core/v2/ics-004-packet-semantics/README.md

@@ -29,15 +29,15 @@ In order to provide the desired ordering, exactly-once delivery, and module perm
 
 ### Definitions
 
-`ConsensusState` is as defined in [ICS 2](../ics-002-client-semantics).
+`ConsensusState` is as defined in [ICS 2]( ../../ics-002-client-semantics).
 
-`Connection` is as defined in [ICS 3](../ics-003-connection-semantics).
+`Connection` is as defined in [ICS 3]( ../../ics-003-connection-semantics).
 
-`Port` and `authenticateCapability` are as defined in [ICS 5](../ics-005-port-allocation).
+`Port` and `authenticateCapability` are as defined in [ICS 5]( ../../ics-005-port-allocation).
 
 `hash` is a generic collision-resistant hash function, the specifics of which must be agreed on by the modules utilising the channel. `hash` can be defined differently by different chains.
 
-`Identifier`, `get`, `set`, `delete`, `getCurrentHeight`, and module-system related primitives are as defined in [ICS 24](../ics-024-host-requirements).
+`Identifier`, `get`, `set`, `delete`, `getCurrentHeight`, and module-system related primitives are as defined in [ICS 24]( ../../ics-024-host-requirements).
 
 See [upgrades spec](./UPGRADES.md) for definition of `pendingInflightPackets` and `restoreChannel`.
 
@@ -260,7 +260,7 @@ Host state machines MAY also safely ignore the version data or specify an empty
 
 ### Sub-protocols
 
-> Note: If the host state machine is utilising object capability authentication (see [ICS 005](../ics-005-port-allocation)), all functions utilising ports take an additional capability parameter.
+> Note: If the host state machine is utilising object capability authentication (see [ICS 005]( ../../ics-005-port-allocation)), all functions utilising ports take an additional capability parameter.
 
 #### Identifier validation
 
@@ -313,7 +313,7 @@ function writeChannel(
 }
 ```
 
-See handler functions `handleChanOpenInit` and `handleChanOpenTry` in [Channel lifecycle management](../ics-026-routing-module/README.md#channel-lifecycle-management) for more details.
+See handler functions `handleChanOpenInit` and `handleChanOpenTry` in [Channel lifecycle management]( ../../ics-026-routing-module/README.md#channel-lifecycle-management) for more details.
 
 The opening channel must provide the identifiers of the local channel identifier, local port, remote port, and remote channel identifier.
 
@@ -713,19 +713,19 @@ function getCounterPartyHops(proof: CommitmentProof | MultihopProof, lastConnect
 
 The following sequence of steps must occur for a packet to be sent from module *1* on machine *A* to module *2* on machine *B*, starting from scratch.
 
-The module can interface with the IBC handler through [ICS 25](../ics-025-handler-interface) or [ICS 26](../ics-026-routing-module).
+The module can interface with the IBC handler through [ICS 25]( ../../ics-025-handler-interface) or [ICS 26]( ../../ics-026-routing-module).
 
 1. Initial client & port setup, in any order
-    1. Client created on *A* for *B* (see [ICS 2](../ics-002-client-semantics))
-    1. Client created on *B* for *A* (see [ICS 2](../ics-002-client-semantics))
-    1. Module *1* binds to a port (see [ICS 5](../ics-005-port-allocation))
-    1. Module *2* binds to a port (see [ICS 5](../ics-005-port-allocation)), which is communicated out-of-band to module *1*
+    1. Client created on *A* for *B* (see [ICS 2]( ../../ics-002-client-semantics))
+    1. Client created on *B* for *A* (see [ICS 2]( ../../ics-002-client-semantics))
+    1. Module *1* binds to a port (see [ICS 5]( ../../ics-005-port-allocation))
+    1. Module *2* binds to a port (see [ICS 5]( ../../ics-005-port-allocation)), which is communicated out-of-band to module *1*
 1. Establishment of a connection & channel, optimistic send, in order
-    1. Connection opening handshake started from *A* to *B* by module *1* (see [ICS 3](../ics-003-connection-semantics))
+    1. Connection opening handshake started from *A* to *B* by module *1* (see [ICS 3]( ../../ics-003-connection-semantics))
     1. Channel opening handshake started from *1* to *2* using the newly created connection (this ICS)
     1. Packet sent over the newly created channel from *1* to *2* (this ICS)
 1. Successful completion of handshakes (if either handshake fails, the connection/channel can be closed & the packet timed-out)
-    1. Connection opening handshake completes successfully (see [ICS 3](../ics-003-connection-semantics)) (this will require participation of a relayer process)
+    1. Connection opening handshake completes successfully (see [ICS 3]( ../../ics-003-connection-semantics)) (this will require participation of a relayer process)
     1. Channel opening handshake completes successfully (this ICS) (this will require participation of a relayer process)
 1. Packet confirmation on machine *B*, module *2* (or packet timeout if the timeout height has passed) (this will require participation of a relayer process)
 1. Acknowledgement (possibly) relayed back from module *2* on machine *B* to module *1* on machine *A*
@@ -743,7 +743,7 @@ Calling modules MUST execute application logic atomically in conjunction with ca
 The IBC handler performs the following steps in order:
 
 - Checks that the channel is not closed to send packets
-- Checks that the calling module owns the sending port (see [ICS 5](../ics-005-port-allocation))
+- Checks that the calling module owns the sending port (see [ICS 5]( ../../ics-005-port-allocation))
 - Checks that the timeout height specified has not already passed on the destination chain
 - Increments the send sequence counter associated with the channel
 - Stores a constant-size commitment to the packet data & packet timeout

spec/core/v2/ics-005-port-allocation/README.md

@@ -33,11 +33,11 @@ port simultaneously. Channels are end-to-end between two ports, each of which mu
 Optionally, the host state machine can elect to expose port binding only to a specially-permissioned module manager,
 by generating a capability key specifically for the ability to bind ports. The module manager
 can then control which ports modules can bind to with a custom rule-set, and transfer ports to modules only when it
-has validated the port name & module. This role can be played by the routing module (see [ICS 26](../ics-026-routing-module)).
+has validated the port name & module. This role can be played by the routing module (see [ICS 26]( ../../ics-026-routing-module)).
 
 ### Definitions
 
-`Identifier`, `get`, `set`, and `delete` are defined as in [ICS 24](../ics-024-host-requirements).
+`Identifier`, `get`, `set`, and `delete` are defined as in [ICS 24]( ../../ics-024-host-requirements).
 
 A *port* is a particular kind of identifier which is used to permission channel opening and usage to modules.