Session Date/Time: 15 Jun 2022 15:00

TAPS

Summary

The TAPS working group meeting focused on reviewing and addressing several open Pull Requests (PRs) and GitHub Issues across the Architecture, Interface, and Implementation drafts. Key technical discussions revolved around clarifying path selection properties for scavenger traffic, handling protocol fallback, ensuring consistent property naming, and defining the capabilities of message framers. The group made decisions to merge several PRs and assigned action items for remaining issues. A target was set to publish new revisions of all three drafts by the IETF 114 submission deadline in July, with a plan for subsequent document alignment, a final Working Group Last Call (WGLC), and confirmation of assigned document shepherds.

Key Discussion Points

PR #363: Editorial suggestions for implementation draft:
- Discussion centered on the text advising path selection for "scavenger" traffic using "capacity profile."
- Initial text suggesting "prefer a path with the highest available capacity" was questioned as "scavenger" (implying lead-bat congestion control) is typically about deferring to other traffic, not seeking high capacity.
- A suggestion was made to frame it as "prefer a path that supports the scavenger service where it doesn't impact other flows."
- The group agreed to revise the text to be more generic, clarifying that the list of examples is not exhaustive and avoiding overly prescriptive advice for scavenger traffic, focusing instead on minimizing impact.
PR #364: Reference property preferences in implementation draft:
- The implementation draft was missing explicit references to property preference levels (e.g., prohibit, require).
- A simple approach to add these references early in the document was proposed and accepted.
PR #362: Architecture draft - protocol fallback and key material sharing:
- The term "protocol fallback" was found to be ambiguous based on sector review feedback.
- The language was changed to discuss specifying a "minimum version" for connection attempts and clarifying guidelines for key material sharing to prevent unintended reuse across protocols.
PR #361: Editorial fixes and property name consistency:
- Numerous small wording fixes were compiled, and references to property names were updated from using section headings to the actual property names (e.g., multipath-transporter-policy).
- A discussion arose regarding standardizing property name casing (camelCase vs. dash-case) across all drafts. It was decided to merge this PR, and open a follow-up issue for a comprehensive pass on property name consistency in the API draft.
PR #358: Framers for connection protocols:
- The discussion aimed to clarify the role of framers beyond simple message encoding/decoding, specifically their ability to implement parts of protocols, perform handshakes, and manage internal state to make a connectionless protocol connection-oriented.
- It was emphasized that a framer can be a stateful entity and its actions are not limited to a one-to-one message translation. Text will be refined to reflect this broader capability.
Issue #354: ICMP for multicast:
- The section on handling ICMP errors for multicast was reviewed. There was uncertainty about the relevance and practical implementation of ICMP error reporting for multicast receivers in real stacks.
- The group leaned towards removing specific examples of ICMP errors for multicast, opting for more generic error reporting, to avoid unnecessary details and potential inaccuracies.
Issue #349: Privacy implications for using the same tokens on different paths:
- The issue highlighted privacy concerns related to correlating different connection attempts and addresses when performing connection racing, particularly with early data or shared tokens.
- It was agreed that this is a privacy consideration inherent to connection racing and early data, and a warning should be included in the interface draft's privacy and security considerations section, cautioning implementers about potential information leaks.

Decisions and Action Items

Decision: PR #363 (Editorial suggestions for implementation draft regarding scavenger capacity profile) to be merged after refining text to be more generic about path preference and clarifying it's an example.
Decision: PR #364 (Reference property preferences in implementation draft) to be merged.
Decision: PR #362 (Architecture draft - protocol fallback and key material sharing) to be merged.
Decision: PR #361 (Editorial fixes and property name consistency) to be merged.
- Action Item: Michael S.M. to open a follow-up PR for the API draft to ensure property names are consistently referenced and to standardize casing (Issue #365).
Decision: PR #360 (Selection properties after connection established) to be merged.
Action Item: Tommy Pauly to refine text in PR #358 (Framers for connection protocols) to clarify that framers can implement parts of protocols, handle handshakes, and manage internal state beyond simple message encapsulation/decapsulation.
Action Item: Tommy Pauly to perform an editorial pass on PR #348 (Grammar fix).
Action Item: Tommy Pauly to move the text on inbound/outbound send/receive rate to a more suitable location (Issue #356).
Action Item: Tommy Pauly to review and adjust normative language (uppercase "SHOULD"/"MUST") for consistency and accuracy (Issue #355).
Action Item: Tommy Pauly to remove specific text on ICMP errors for multicast, opting for more generic error reporting (Issue #354).
Action Item: Gory (Gorry_Gory) to suggest specific text for exposing quoted packet information from UDP ICMP errors if available from the OS (Issue #353).
Action Item: Tommy Pauly to suggest text clarifying that message content can be a structured object (e.g., via message context in framers) in addition to byte arrays (Issue #352).
Action Item: Tommy Pauly to align terminology for "final message" (e.g., end-of-message) across the API document and examples (Issue #351).
Action Item: Michael S.M. to add warning text to the interface draft's privacy/security considerations regarding privacy implications of connection racing, particularly the correlation of addresses when using early data or tokens on different paths (Issue #349).

Next Steps

Draft Publication: The chairs will work to publish new revisions of all three TAPS drafts (Architecture, Interface, and Implementation) by the IETF 114 Internet-Draft submission deadline (July 11).
Document Alignment: Following the next revisions, the working group will focus on aligning the content across the three documents, with the expectation that the Architecture and Interface drafts will be finalized once the Implementation draft is complete.
Working Group Last Call (WGLC): The chairs will discuss and plan for a short, final WGLC for all documents once they are aligned.
Shepherd Confirmation: Chairs will confirm the previously assigned document shepherds: Brian for Implementation, Anna for Interface, and Michael for Architecture. Once confirmed, these assignments will be updated in the data tracker.