Incorporate feedback on depeering and creation handshake

Address the review feedback to reintroduce delete methods on session
batches and clarify the expectations where receivers need additional
sessions to be created.

draft-ramseyer-grow-peering-api.md

@@ -118,7 +118,7 @@ On successful authentication, PeeringDB provides the Resource Server (RS) with t
   * PARTIAL APPROVAL CASE
     * Server returns a list with the structure for each of the acceptable peering sessions as in the approval case. The server also returns a list of sessions that have not deemed as validated or acceptable to be created. The set of sessions accepted and rejected is disjoint and the join of both sets matches the cardinality of the requested sessions. The sessions on each set are associated to the client request by the Item ID specified for each session.
   * REJECTION CASE
-    * Server returns and error message which indicates that all of the sessions requested have been rejected and the reason for it.
+    * Server returns an error message which indicates that all of the sessions requested have been rejected and the reason for it.
 
 ## CLIENT CONFIGURATION
 The client then configures the chosen peering sessions asynchronously using their internal mechanisms.
@@ -179,15 +179,17 @@ Session Array
   Client may provide initial UUID for client-side tracking, but the server UUID will be the final definitive ID.  RequestID will not change across the request.
 
 BGP Session
-  * local_asn (ASN of requestor)
-  * local_ip (IP of requestor, v4 or v6)
-  * peer_asn (server ASN)
-  * peer_ip (server-side IP)
-  * peer_type (public or private)
-  * md5 (optional, as defined above)
-  * location (Peering Location, as defined above)
-  * status (Session Status, as defined above)
-  * session_id (of individual session generated by the server. Client provides a item ID to track the session within the request, but the server's session ID will be the final definitive ID)
+
+  A structure that describes a BGP session and contains the following elements:
+    * local_asn (ASN of requestor)
+    * local_ip (IP of requestor, v4 or v6)
+    * peer_asn (server ASN)
+    * peer_ip (server-side IP)
+    * peer_type (public or private)
+    * md5 (optional, as defined above)
+    * location (Peering Location, as defined above)
+    * status (Session Status, as defined above)
+    * session_id (of individual session generated by the server. Client provides a item ID to track the session within the request, but the server's session ID will be the final definitive ID)
 
 Error
 
@@ -235,6 +237,38 @@ On each call, there should be rate limits, allowed senders, and other optional r
         * 403:
           * Unauthorized to perform the operation
 
+* /sessions/{session_id}: Operate on individual sessions
+  * Retrieve an existing session resource
+    * Below is based on OpenAPI specification: [https://github.com/bgp/autopeer/blob/main/api/openapi.yaml](https://github.com/bgp/autopeer/blob/main/api/openapi.yaml)
+    * GET: /sessions/{session_id}
+      * Request parameters:
+        * session_id returned by the server on creation or through the session list operation.
+      * Responses:
+        * 200 OK:
+          * Contents: Session structure with current attributes
+        * 400:
+          * Error (example: session_id is invalid)
+        * 403:
+          * Unauthorized to perform the operation
+        * 404:
+          * The session referred by the specified session_id does not exist or is not visible to the caller
+
+  * Delete a session.
+    * Given a session ID, delete it which effectively triggers an depeering from the initiator.
+    * Below is based on OpenAPI specification: [https://github.com/bgp/autopeer/blob/main/api/openapi.yaml](https://github.com/bgp/autopeer/blob/main/api/openapi.yaml)
+    * DELETE: /sessions/{session_id}
+      * Request parameters:
+        * session_id returned by the server on creation or through the session list operation.
+      * Response:
+        * 204: OK
+          * Contents: empty response as the session is processed and hard deleted
+        * 400:
+          * Error (example: session_id is invalid)
+        * 403:
+          * Unauthorized to perform the operation
+        * 404:
+          * The session referred by the specified session_id does not exist or is not visible to the caller
+
 ### UTILITY API CALLS
 Endpoints which provide useful information for potential interconnections.
 
@@ -291,7 +325,7 @@ If the client configured B as well, it will not come up.
 
 This draft encourages peers to set up garbage collection for unconfigured or down peering sessions, to remove stale configuration and maintain good router hygiene.
 
-Related to rejection, if the server would like to configure additional sessions with the client, the server may either reject all the session that do not meet the criteria caused by such absence in the client's request or issue a separate request to the client's server requesting those additional peering sessions D and E.
+Related to rejection, if the server would like to configure additional sessions with the client, the server may either reject all the session that do not meet the criteria caused by such absence in the client's request or approve the client's request and issue a separate request to the client's server requesting those additional peering sessions D and E.
 The server will configure D and E on their side, and D and E will become part of the sessions requested in the UUID.
 The client may choose whether or not to accept those additional sessions.
 If they do, the client should configure D and E as well.