DRIVERS-2789 Convert Another SDAM Spec File to Markdown

use python code block

source/auth/auth.md

@@ -148,7 +148,7 @@ Drivers MUST follow the following steps for an authentication handshake:
 
 If the authentication handshake fails for a socket, drivers MUST mark the server Unknown and clear the server's
 connection pool. (See [Q & A](#q--a) below and SDAM's
-[Why mark a server Unknown after an auth error](/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#why-mark-a-server-unknown-after-an-auth-error)
+[Why mark a server Unknown after an auth error](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#why-mark-a-server-unknown-after-an-auth-error)
 for rationale.)
 
 All blocking operations executed as part of the authentication handshake MUST apply timeouts per the

source/client-side-encryption/client-side-encryption.md

@@ -1574,7 +1574,7 @@ If the [crypt_shared](#crypt_shared) library is loaded, the driver MUST NOT atte
 Single-threaded drivers MUST connect with
 [serverSelectionTryOnce=false](../server-selection/server-selection.md#serverselectiontryonce),
 `connectTimeoutMS=10000`, and MUST bypass
-[cooldownMS](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst#cooldownms) when connecting to
+[cooldownMS](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#cooldownms) when connecting to
 mongocryptd. See
 [Why are serverSelectionTryOnce and cooldownMS disabled for single-threaded drivers connecting to mongocryptd?](#why-are-serverselectiontryonce-and-cooldownms-disabled-for-single-threaded-drivers-connecting-to-mongocryptd)
 
@@ -2115,7 +2115,7 @@ server before making another attempt. Meaning if the first attempt to mongocrypt
 observe a 5 second delay. This is not configurable in the URI, so this must be overridden internally. Since mongocryptd
 is a local process, there should only be a very short delay after spawning mongocryptd for it to start listening on
 sockets. See the SDAM spec description of
-[cooldownMS](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst#cooldownms).
+[cooldownMS](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#cooldownms).
 
 Because single threaded drivers may exceed `serverSelectionTimeoutMS` by the duration of the topology scan,
 `connectTimeoutMS` is also reduced.

source/client-side-operations-timeout/client-side-operations-timeout.md

@@ -209,7 +209,7 @@ See [serverSelectionTimeoutMS is not deprecated](#serverselectiontimeoutms-is-no
 If `timeoutMS` is set, drivers MUST append a `maxTimeMS` field to commands executed against a MongoDB server using the
 `minRoundTripTime` field of the selected server. Note that this value MUST be retrieved during server selection using
 the `servers` field of the same
-[TopologyDescription](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst#TopologyDescription) that
+[TopologyDescription](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#TopologyDescription) that
 was used for selection before the selected server's description can be modified. Otherwise, drivers may be subject to a
 race condition where a server is reset to the default description (e.g. due to an error in the monitoring thread) after
 it has been selected but before the RTT is retrieved.

source/connection-monitoring-and-pooling/connection-monitoring-and-pooling.md

@@ -380,13 +380,13 @@ interface ConnectionPool {
 This specification does not define how a pool is to be created, leaving it up to the driver. Creation of a connection
 pool is generally an implementation detail of the driver, i.e., is not a part of the public API of the driver. The SDAM
 specification defines
-[when](https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#connection-pool-creation)
-the driver should create connection pools.
+[when](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#connection-pool-creation) the driver should
+create connection pools.
 
 When a pool is created, its state MUST initially be set to "paused". Even if minPoolSize is set, the pool MUST NOT begin
 being [populated](#populating-the-pool-with-a-connection-internal-implementation) with [Connections](#connection) until
 it has been marked as "ready". SDAM will mark the pool as "ready" on each successful check. See
-[Connection Pool Management](/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#connection-pool-management)
+[Connection Pool Management](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#connection-pool-management)
 section in the SDAM specification for more information.
 
 ```
@@ -508,8 +508,8 @@ Populating the pool MUST NOT block any application threads. For example, it coul
 via the use of non-blocking/async I/O. Populating the pool MUST NOT be performed unless the pool is "ready".
 
 If an error is encountered while populating a connection, it MUST be handled via the SDAM machinery according to the
-[Application Errors](/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#application-errors)
-section in the SDAM specification.
+[Application Errors](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#application-errors) section
+in the SDAM specification.
 
 If minPoolSize is set, the [Connection](#connection) Pool MUST be populated until it has at least minPoolSize total
 [Connections](#connection). This MUST occur only while the pool is "ready". If the pool implements a background thread,

source/index.md

@@ -29,6 +29,7 @@
 - [Retryable Reads](retryable-reads/retryable-reads.md)
 - [Retryable Writes](retryable-writes/retryable-writes.md)
 - [SDAM Logging and Monitoring Specification](server-discovery-and-monitoring/server-discovery-and-monitoring-logging-and-monitoring.md)
+- [Server Discovery And Monitoring](server-discovery-and-monitoring/server-discovery-and-monitoring.md)
 - [Server Discovery And Monitoring -- Summary](server-discovery-and-monitoring/server-discovery-and-monitoring-summary.md)
 - [Server Discovery And Monitoring -- Test Plan](server-discovery-and-monitoring/server-discovery-and-monitoring-tests.md)
 - [Server Monitoring](server-discovery-and-monitoring/server-monitoring.md)

source/load-balancers/load-balancers.md

@@ -21,7 +21,7 @@ The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SH
 #### SDAM
 
 An abbreviated form of "Server Discovery and Monitoring", specification defined in
-[Server Discovery and Monitoring Specification](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst).
+[Server Discovery and Monitoring Specification](../server-discovery-and-monitoring/server-discovery-and-monitoring.md).
 
 #### Service
 

source/logging/logging.md

@@ -134,7 +134,7 @@ produce.
 | Component Name | Specification(s) | Environment Variable |
 | --------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------ |
 | command | [Command Logging and Monitoring](../command-logging-and-monitoring/command-logging-and-monitoring.rst) | `MONGODB_LOG_COMMAND` |
-| topology | [Server Discovery and Monitoring](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst) | `MONGODB_LOG_TOPOLOGY` |
+| topology | [Server Discovery and Monitoring](../server-discovery-and-monitoring/server-discovery-and-monitoring.md)  | `MONGODB_LOG_TOPOLOGY` |
 | serverSelection | [Server Selection](../server-selection/server-selection.md) | `MONGODB_LOG_SERVER_SELECTION` |
 | connection | [Connection Monitoring and Pooling](../connection-monitoring-and-pooling/connection-monitoring-and-pooling.md) | `MONGODB_LOG_CONNECTION` |
 

source/polling-srv-records-for-mongos-discovery/polling-srv-records-for-mongos-discovery.rst

@@ -26,7 +26,7 @@ specification's definition of monitoring a set of mongos servers in a Sharded
 TopologyType.
 
 .. _`Initial DNS Seedlist Discovery`: ../initial-dns-seedlist-discovery/initial-dns-seedlist-discovery.md
-.. _`Server Discovery and Monitoring`: ../server-discovery-and-monitoring/server-discovery-and-monitoring.rst
+.. _`Server Discovery and Monitoring`: ../server-discovery-and-monitoring/server-discovery-and-monitoring.md
 
 META
 ====
@@ -144,7 +144,7 @@ Single-Threaded Drivers
 The rescan MUST happen **before** scanning all servers as part of the normal
 scanning_ functionality, but only if *rescanSRVIntervalMS* has passed.
 
-.. _scanning: https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#scanning
+.. _scanning: ../server-discovery-and-monitoring/server-discovery-and-monitoring.md#scanning
 
 Test Plan
 =========

source/retryable-reads/retryable-reads.md

@@ -202,7 +202,7 @@ Drivers MUST only attempt to retry a read command if
 
 If the driver decides to allow retry and the previous attempt of a retryable read command encounters a retryable error,
 the driver MUST update its topology according to the Server Discovery and Monitoring spec (see
-[SDAM: Error Handling](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst#error-handling)) and
+[SDAM: Error Handling](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#error-handling)) and
 capture this original retryable error. Drivers should then proceed with selecting a server for a retry attempt.
 
 ###### 3a. Selecting the server for retry
@@ -247,7 +247,7 @@ and the timeout has not yet expired, then the Driver MUST jump back to step 2b a
 attempts.
 
 Otherwise, drivers MUST update their topology according to the SDAM spec (see
-[SDAM: Error Handling](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst#error-handling)). If an
+[SDAM: Error Handling](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#error-handling)). If an
 error would not allow the caller to infer that an attempt was made (e.g. connection pool exception originating from the
 driver), the previous error should be raised. If a retry failed due to another retryable error or some other error
 originating from the server, that error should be raised instead as the caller can infer that an attempt was made and

source/retryable-writes/retryable-writes.md

@@ -216,7 +216,7 @@ The RetryableWriteError label might be added to an error in a variety of ways:
  - the `writeConcernError.code` field in a mongos response
 
  The criteria for retryable errors is similar to the discussion in the SDAM spec's section on
- [Error Handling](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst#error-handling), but includes
+ [Error Handling](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#error-handling), but includes
  additional error codes. See [What do the additional error codes mean?](#what-do-the-additional-error-codes-mean) for
  the reasoning behind these additional errors.
 
@@ -300,8 +300,8 @@ MUST NOT attempt to retry a write command on any other error.
 
 If the first attempt of a write command including a transaction ID encounters a retryable error, the driver MUST update
 its topology according to the SDAM spec (see:
-[Error Handling](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst#error-handling)) and capture
-this original retryable error.
+[Error Handling](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#error-handling)) and capture this
+original retryable error.
 
 Drivers MUST then retry the operation as many times as necessary until any one of the following conditions is reached:
 
@@ -319,7 +319,7 @@ retrying is not possible and drivers MUST raise the retryable error from the pre
 is able to infer that an attempt was made.
 
 If a retry attempt also fails, drivers MUST update their topology according to the SDAM spec (see:
-[Error Handling](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst#error-handling)). If an error
+[Error Handling](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#error-handling)). If an error
 would not allow the caller to infer that an attempt was made (e.g. connection pool exception originating from the
 driver) or the error is labeled "NoWritesPerformed", the error from the previous attempt should be raised. If all server
 errors are labeled "NoWritesPerformed", then the first error should be raised.
@@ -449,7 +449,7 @@ function executeRetryableWrite(command, session) {
 ```
 
 `handleError` in the above pseudocode refers to the function defined in the
-[Error handling pseudocode](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst#error-handling-pseudocode)
+[Error handling pseudocode](../server-discovery-and-monitoring/server-discovery-and-monitoring.md#error-handling-pseudocode)
 section of the SDAM specification.
 
 When retrying a write command, drivers MUST resend the command with the same transaction ID. Drivers MUST NOT resend the
@@ -557,7 +557,7 @@ The spec concerns itself with retrying write operations that encounter a retryab
 network error or a response indicating that the node is no longer a primary). A retryable error may be classified as
 either a transient error (e.g. dropped connection, replica set failover) or persistent outage. In the case of a
 transient error, the driver will mark the server as "unknown" per the
-[SDAM](../server-discovery-and-monitoring/server-discovery-and-monitoring.rst) spec. A subsequent retry attempt will
+[SDAM](../server-discovery-and-monitoring/server-discovery-and-monitoring.md) spec. A subsequent retry attempt will
 allow the driver to rediscover the primary within the designated server selection timeout period (30 seconds by
 default). If server selection times out during this retry attempt, we can reasonably assume that there is a persistent
 outage. In the case of a persistent outage, multiple retry attempts are fruitless and would waste time. See

source/server-discovery-and-monitoring/server-discovery-and-monitoring-logging-and-monitoring.md

@@ -33,8 +33,7 @@ The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SH
 `Server`
 
 > The term `Server` refers to the implementation in the driver's language of an abstraction of a mongod or mongos
-> process, or a load balancer, as defined by the
-> [SDAM specification](https://github.com/mongodb/specifications/blob/master/source/server-discovery-and-monitoring/server-discovery-and-monitoring.rst#server).
+> process, or a load balancer, as defined by the [SDAM specification](server-discovery-and-monitoring.md#server).
 
 ### Specification