**Session Date/Time:** 25 Jul 2022 17:30

# drip

## Summary

The drip working group session provided updates on the status of three core drafts (`drip-id`, `drip-architecture`, `drip-authentication-protocols`) which are in various stages of ISG review or Working Group Last Call (WGLC). A significant portion of the discussion focused on the `drip-registries` draft, addressing challenges with terminology (specifically "registrar") and the document's structure, leading to a decision to split it into an architecture document and separate implementation interface documents. Hackathon results showcasing live registration and lookup demonstrations were also presented, highlighting implementation progress and reinforcing the need for clear documentation. The group also discussed dependencies on external bodies like ICAO for code allocations and the FAA for DNS entries.

## Key Discussion Points

*   **Document Status Updates:**
    *   **`drip-id` (RID):** Version 31 posted; no design changes since v17. IESG reviewed v29. Ongoing work to resolve ISG comments, particularly concerning IANA considerations and avoiding semantic clashes with existing IETF/ICANN terminology. Discussions on deferring registry-specific issues to future documents. Bob Moskowitz committed to regular updates as resolutions are reached.
    *   **`drip-architecture` (ARCH):** Received 11 reviews (1 discus, 10 new objections). Most comments were editorial or for clarification, including diagram improvements. Revision 25 was posted with fixes, including alignment with RFC 90153 terminology and updates for ASTM F3411-22A (new reader type 4). The draft is expected to be shipped to the RFC editor in approximately two weeks if no further major comments arise.
    *   **`drip-authentication-protocols` (AUTH):** In WGLC. Key dependency is ICAO allocation of specific authentication method codes as per ASTM F3411-22A. Version -05 posted with significant reordering and explanation text. Adam Wiethuechter outlined the inclusion of ICAO DNS structure, cert OIDs, EPP clarifications, and X.509 certificates.
*   **ICAO and FAA Dependencies:**
    *   A critical dependency for `drip-authentication-protocols` is the formal registry of authentication method codes by ICAO. Chairs will coordinate an IETF liaison statement to ICAO to expedite this process.
    *   Discussions regarding OYTARK (Other YC type ARKA) and DNS entries managed by the FAA Communication Panel. A working paper will be co-authored for submission to the FAA Communication Panel meeting in September.
*   **`drip-registries` Document Structure and Terminology:**
    *   **Document Complexity:** Experience from interoperability demonstrations revealed significant difficulty for new implementers to understand the `drip-registries` document flow (e.g., how DET works, DNS usage), requiring extensive explanation (20+ hours for one person).
    *   **"Registrar" Terminology:** The term "registrar" is problematic due to its specific meaning within ICANN, which entails complex processes, regulations, and economic models (e.g., per-session ID registration fees) that are unsuitable for drone operations.
    *   **Proposed Alternatives for "Registrar":** "Drip Registration Agency," "Drip Provisioning Agency (DPA)," or "Drip ID Management Organization (DMO)" were suggested. The intent is to define the *function* without inheriting the ICANN semantic burden.
    *   **New Document Structure Proposal:** To address complexity and terminology, it was proposed that the current `drip-registries` draft become an "Architecture for DET-based Registries" document, containing high-level architecture, resource record definitions, and object definitions. New, separate documents would then be spawned to define specific interfaces between components, such as DPA-Registry (e.g., using EPP or Open API) and Information Agent-backend. This aims to separate process from implementation details.
    *   **DNS Structure:** Discussions on the FQDN structure (e.g., `uas.icao.int` vs. other domains like `remote-id.arpa`) emphasized the need for flexibility in the `drip-registries` architecture to allow implementers to choose their specific domain. Jim Reid clarified the use of "apex" instead of "root" in DNS terminology.
*   **Implementations and Hackathon:**
    *   **Info Networks:** Demonstrated live registration with an AX implementation, broadcasting of session IDs, and lookups via DNS.
    *   **Andre:** Presented a flying drone carrying Raspberry Pi 4 with drip code, transmitting via GPS, and an Android app. Also mentioned an alternative Iroha blockchain implementation and an open HEAP release for generating drone ID tags.

## Decisions and Action Items

*   **`drip-id`:** Bob Moskowitz to continue direct engagement with relevant ADs to resolve remaining ISG concerns and post regular draft updates as resolutions are achieved.
*   **`drip-architecture`:** Editors to incorporate remaining feedback and aim for publication within two weeks, assuming no further significant issues.
*   **`drip-authentication-protocols`:**
    *   Chairs to draft and send an IETF liaison statement to ICAO requesting the allocation of specific authentication method codes (F3411-22A).
    *   Rob Seegers, Ashley, Fred (from Ghana), and Andre (via chat) volunteered to review the document for WGLC.
    *   Adam Wiethuechter to coordinate with the FAA Communication Panel on submitting a working paper concerning OYTARK and DNS entry management.
*   **`drip-registries` Document Structure:**
    *   **Decision:** The working group agrees to restructure the `drip-registries` work by converting the current draft into a high-level "Architecture for DET-based Registries" document.
    *   **Decision:** New, separate documents will be created to specify implementation-specific interfaces (e.g., DPA-Registry via EPP/Open API, Information Agent interfaces).
    *   **Action Item:** Adam Wiethuechter to prepare a "dry run" proposal of this new document structure and content allocation and share it on the mailing list for working group review *before* making any formal changes to existing drafts.
*   **Terminology:** The term "registrar" will be replaced with a more appropriate term (e.g., "Drip Provisioning Agency" or "Drip ID Management Organization") in relevant documents to avoid semantic and regulatory conflicts with ICANN. This change will be reflected in `drip-architecture` and the new `drip-registries` structure.

## Next Steps

*   **`drip-id`**: Continue iteration to resolve ISG comments for publication.
*   **`drip-architecture`**: Finalize and ship to RFC editor.
*   **`drip-authentication-protocols`**: Incorporate WGLC review comments, await ICAO feedback, and prepare for further progression.
*   **`drip-registries`**: Adam Wiethuechter to circulate the proposed new document structure and content outline for working group review and feedback on the mailing list.
*   **Future Work**: The working group will begin to consider and actively lead work on **Network Remote ID** for future IETF sessions (e.g., IETF 115), aiming to define robust and secure solutions.
*   All technical discussions and feedback are encouraged to occur on the mailing list to ensure transparency and proper record-keeping.