**Session Date/Time:** 01 Dec 2025 23:00

# [PPM](../wg/ppm.html)

## Summary

This interim meeting focused on the status and next steps for the Distributed Aggregation Protocol (DAP) document following its Working Group Last Call (WG Last Call), and a review of the Task Provisioning (TaskProv) extension. Key updates on the dependent VDAF (Verifiable Distributed Aggregation Function) draft from CFRG were also discussed. The group determined to advance DAP to IESG review while managing the normative reference to the still-in-progress VDAF document as a "downref." Chairs requested further input on TaskProv. Discussions also clarified the IANA registry creation process.

## Key Discussion Points

*   **DAP Protocol WG Last Call Review:**
    *   WG Last Call for DAP was initiated on September 16th and concluded on October 7th.
    *   The document received a review from the HTTP Directorate, leading to significant editorial improvements.
    *   Editors made 8 pull requests addressing 15 open issues, primarily for clarity and readability.
    *   A significant change was renaming "VDAF preparation" to "verification" to better align with current VDAF understanding and resolve confusion.
    *   The *only wire-breaking change* since DAP-16 was the adoption of a single media type (`application/BPM-DAP`) with message-specific parameters (e.g., `message=upload`).
    *   Thanks were extended to Daryl Miller (HTTP Directorate reviewer) and Martin.

*   **VDAF Draft (CFRG) Status:**
    *   The VDAF draft-17 incorporates changes from Armando Faz's paper, optimizing polynomial multiplication to use the Lagrange basis, yielding significant performance benefits.
    *   This change is considered a *breaking change* at the VDAF layer but does not affect the abstract API. DAP versions will implicitly reference specific VDAF versions (e.g., DAP-17 references VDAF-17).
    *   The VDAF document is considered largely complete, awaiting another round of CryptoPanel review at CFRG, followed by a Research Group Last Call.
    *   The sense of those present is that there is low likelihood of further API changes to VDAF. Future cryptographic optimizations or new algorithms would likely result in new VDAF definitions rather than changes to the core VDAF specification.

*   **DAP Next Steps:**
    *   Only three minor open issues remain for DAP, mostly related to updating references and IANA registry definitions.
    *   The primary dependency for DAP publication is the VDAF draft reaching RFC status.
    *   There was a discussion about whether to wait for VDAF to become an RFC or push DAP to IESG review with a normative reference (downref) to the CFRG draft. The latter was generally favored, managing the reference during the IESG process.
    *   The Auth48 process (final author approval) was noted as a potential point of delay due to multiple authors.
    *   A chair offered to contact CFRG chairs to inquire about prioritizing VDAF review, though VDAF authors indicated comfort with waiting for thorough review.

*   **Task Provisioning (TaskProv) Extension Status:**
    *   TaskProv received limited feedback during its WG Last Call. Chairs requested more expressions of support for publication.
    *   An editor reported successful production deployment of TaskProv, highlighting its value in enabling leader/collector entities to define tasks without requiring high-touch coordination with the helper (preserving privacy).
    *   Earlier concerns about efficiency for bulk uploads (due to repetitive task information) were deemed sufficiently addressed by relying on standard HTTP compression.
    *   Clarification was provided that TaskProv is most impactful in the leader-helper interaction, where the cost of task configuration is amortized across many reports.
    *   Martin Thompson noted that HTTP header field definitions should use Structured Fields (RFC 9651) for clarity and to leverage existing parsing libraries.

*   **IANA Process Clarification:**
    *   The IANA "Considerations" section within a document is where registries are defined.
    *   IANA reviews documents *after* IETF Last Call to ensure registry requests are clear and manageable, but they do not reject based on the technology itself.
    *   IANA will engage with authors to confirm instructions and show drafts of new registries.
    *   Media type registrations require a separate email request to a specific mailing list, following RFC 6838, which is then incorporated into the IANA Considerations.
    *   For registries designated as "Specification Required," the document should provide clear guidance for Designated Experts (DEs) on how to evaluate new registrations (e.g., "is it coherent and not spam").
    *   It was suggested to have two DEs for such registries. Chris and Martin volunteered.

*   **L1 BoundSum Extension:**
    *   The L1 BoundSum draft is considered ready for WG Last Call once DAP is finalized.
    *   A final revision is planned to align with VDAF's upcoming flexible range check capability (moving beyond power-of-2 constraints), which is a desired improvement.

## Decisions and Action Items

*   **DAP Document:**
    *   **Decision:** The working group intends to advance the DAP document to IESG review, managing the normative reference to the VDAF CFRG draft as a "downref" during the IESG process.
    *   **Action (Tim):** Create a Pull Request (PR) to add an RFC editor's note to DAP draft-17, specifying the plan to update the VDAF reference to an RFC number during the Auth48 stage.
    *   **Action (Tim):** Review and update any dangling references (e.g., Privacy Pass).
    *   **Action (Tim):** Release DAP draft-17 to the data tracker incorporating these changes.
    *   **Action (Tim):** After reviewing RFC 6838 (Media Type Specification), initiate the IANA media type registry request via email.
    *   **Action (Tim):** Review RFC 8126 (IANA Considerations) for guidance on defining registry policies and DE behavior.
*   **DAP Shepherd:**
    *   **Action (Chairs):** Identify and solicit a shepherd for the DAP document, noting that the shepherd should not be a co-author or editor.
*   **TaskProv Document:**
    *   **Action (Chairs):** Re-solicit additional comments and expressions of support for TaskProv publication on the PPM mailing list.
    *   **Action (Tim):** Provide a written summary of TaskProv deployment experience to the mailing list.
    *   **Action (Martin):** File an issue for TaskProv to define its HTTP header field using Structured Fields (RFC 9651).
*   **IANA Registry Guidance:**
    *   **Action (DAP Editors):** Add a paragraph to the IANA Considerations section of the DAP document to provide clear guidance for Designated Experts on how to evaluate new registrations for "Specification Required" registries (e.g., focusing on coherence and non-spam criteria).
    *   **Action (WG):** Chris and Martin volunteered to serve as Designated Experts for the new DAP registries.
*   **L1 BoundSum Document:**
    *   **Action (L1 BoundSum Editors):** Prepare one more revision of the L1 BoundSum document to incorporate the flexible range check alignment with the VDAF draft.

## Next Steps

*   **DAP:** Submit DAP draft-17 to the IESG for review once the action items above are completed.
*   **TaskProv:** After receiving sufficient support on the mailing list and addressing the header field definition, prepare TaskProv for IESG review.
*   **L1 BoundSum:** Complete the planned revision, then prepare for a Working Group Last Call.