**Session Date/Time:** 26 Sep 2022 15:00

# [TAPS](../wg/taps.html)

## Summary

The TAPS Working Group held an interim meeting to review open Pull Requests (PRs) and issues, aiming to finalize the remaining technical content and prepare documents for submission. Key discussions revolved around specific text clarifications in the API and architecture documents, consistency across protocol mappings, and administrative steps for shepherd write-ups and document progression. All outstanding PRs were reviewed and merged or slated for immediate follow-up. Several issues were closed, and a plan was established for addressing the remaining technical consistency items and administrative tasks.

## Key Discussion Points

*   **Review and Merging of Pull Requests (PRs)**
    *   **Editorial Updates:** A PR containing minor editorial updates was reviewed and merged.
    *   **Introduce Racing More Clearly:** A PR clarifying the concept of "racing" was reviewed and merged.
    *   **Reference IPv6 Address Considerations for Temporary Local Property:** Discussion centered on referencing RFC 8981 (Temporary Address Extensions for IPv6) for local addresses. It was agreed to merge the PR, with a follow-up to incorporate Gorry's suggestion to move the reference and adjust phrasing.
    *   **Metadata Only Messages:** Extensive discussion on clarifying the phrasing around messages containing "no data" or "zero bytes." The group agreed on replacing "raw bytes" with "no application data" and being more precise about the use of `message data` and `message context` parameters. The PR was merged with these adjustments.
    *   **Multicast:** Discussion on a PR adding `remote` and `local` specifiers, `TTL` parameter, and interface specification for multicast groups. Concerns were raised about the lack of clarity on how to determine the receiving interface. It was agreed to add a cross-reference to Section 9.1.1 of the API document regarding `get remote endpoint` and `get local endpoint` from `message context`. The PR was merged, with specific follow-up actions planned for further cleanup.
    *   **General Cleanup PR (by Gorry):** A PR addressing various consistency issues, including capitalization of terms (e.g., `Requests`, `Responses`, `Interface`, `Endpoint`), use of keywords (`MUST`, `SHOULD`), and list formatting was reviewed. Tommy agreed to address specific capitalization issues. The PR was merged.

*   **Review and Closure of Issues**
    *   **Issues related to "Taps" vs "Transport Services" capitalization and formatting:** Several long-standing issues concerning terminology and formatting were closed as "overtaken by velocity/events," as the relevant changes had already been incorporated.
    *   **"Add examples for ASM and SSM":** This issue was closed as "overtaken by events," as related content was addressed in other PRs.
    *   **"TCP implementation mapping" (Issue 1050):** A detailed review led by Anna identified several inconsistencies between the API document and protocol mappings:
        *   `Connection error` event missing for UDP/multicast mappings.
        *   `Initiate error` vs `establishment error` terminology.
        *   `Add remote` and `remove remote` actions not covered in protocol mappings (specifically for MPTCP).
        *   `Rendezvous` not covered.
        *   `Closed event` missing where `connection error` is present.
        *   `SCTP priority` property appearing in isolation.
        *   UDP-Lite description being incomplete.
        *   Anna proposed specific actions for each point, which received tacit approval from the group to be addressed in a follow-up PR.
    *   **"Complete implementation":** This issue was closed as it was covered by the discussion and actions planned for Issue 1050.

*   **Formatting Consistency: Backticks vs. Squiggles**
    *   A discussion arose regarding the use of triple backticks (` ``` `) vs. triple squiggles (` ~~~ `) for code blocks in Markdown. It was clarified that squiggles produce rendered code blocks, while backticks produce inline code. Colin volunteered to create a PR to standardize the use of squiggles for code blocks.

*   **Shepherd Write-ups and Document Progression**
    *   **Shepherd Assignments:** The group re-confirmed shepherds for each TAPS document:
        *   Brian for `taps-impl` (Implementation document).
        *   Anna for `taps-api` (API document).
        *   Michael for `taps-arch` (Architecture document).
    *   **Shepherd Process:** Michael, being new to the shepherd role, was offered guidance and resources. The importance of the shepherd's role in guiding the document through ISG/IETF review and ensuring author responsiveness was highlighted.
    *   **Author List Discussion:** The previous discussion with the ISG regarding author lists, particularly for the document with more than five authors, was briefly mentioned as an important historical context for the shepherd write-ups.

*   **Future Meetings and Work**
    *   **IETF 115 (London):** The TAPS WG will not have a session in London, as no action was required for WGs not holding a session.
    *   **"What's Next" Discussion:** It was decided to defer the "what's next" discussion until the current set of documents has progressed further through the RFC editor queue.
    *   **Area Director Update:** It was suggested to inform the TSV Area Directors about the working group's progress and future plans, potentially as part of a TSV Area update.

## Decisions and Action Items

**Decisions:**

*   All open Pull Requests (Editorial, Racing, V6 Address Considerations, Metadata-only Messages, Multicast, Gorry's Cleanup PR) were merged.
*   Issues related to "Taps" vs "Transport Services" capitalization, "Add examples for ASM and SSM," and "Complete implementation" were closed.
*   Specific actions were agreed upon to address inconsistencies in "TCP implementation mapping" (Issue 1050), to be captured in a new PR.
*   Shepherds for the three TAPS documents were confirmed: Brian for `taps-impl`, Anna for `taps-api`, and Michael for `taps-arch`.
*   Target date for remaining PRs (multicast cleanup, backtick/squiggle fix, implementation mappings) is **October 10th**.
*   Target date for Shepherd Write-ups is **November 2nd**.

**Action Items:**

*   **Philip:** Create a minor PR to incorporate Gorry's phrasing suggestion for the IPv6 temporary address reference in `taps-arch`.
*   **Anna:** Create a PR to address the inconsistencies identified in "TCP implementation mapping" (Issue 1050) for `taps-impl`.
*   **Colin:**
    *   Create a PR to clean up multicast-related text in `taps-api`, specifically regarding cross-references to message context and clarifying examples.
    *   Create a PR to ensure consistent use of triple squiggles (` ~~~ `) for code blocks and triple backticks (` ``` `) for inline code throughout the documents.
*   **Tommy:** Review and fix capitalization issues, particularly for terms like `Requests`, `Responses`, `Interface`, `Endpoint` resulting from Gorry's cleanup PR.
*   **Brian (Shepherd for `taps-impl`):** Prepare the Shepherd Write-up for `taps-impl` by November 2nd.
*   **Anna (Shepherd for `taps-api`):** Prepare the Shepherd Write-up for `taps-api` by November 2nd.
*   **Michael (Shepherd for `taps-arch`):** Prepare the Shepherd Write-up for `taps-arch` by November 2nd. Rhys to share a "cheat sheet" guide.
*   **Chairs:** Inform the TSV Area Directors about the working group's progress and future intentions.

## Next Steps

1.  Authors/Contributors to address outstanding PRs and minor fixes by **October 10th**.
2.  Shepherds to complete their respective Shepherd Write-ups by **November 2nd**.
3.  Documents will then be submitted for IESG review.
4.  A future interim will likely be needed to process IESG and IETF Last Call review comments.
5.  The discussion regarding "what's next" for the TAPS Working Group will be deferred until the current set of documents are further along in the publication process.