**Session Date/Time:** 01 Mar 2023 16:00

# [DRIP](../wg/drip.html)

## Summary
The DRIP Working Group held its first interim meeting of the year to discuss the status of active documents and critical technical issues. Key topics included addressing USA-centric language in `drip-arch`, the stalled ASTM-ICAO agreement for SAM type code point registration affecting `drip-auth` progress, and architectural concepts for DNS delegation and serial number handling in `drip-registries`. The group identified specific action items for document revisions and emphasized the need for continued GitHub engagement ahead of IETF 116.

## Key Discussion Points

*   **`drip-rid` Status**: The document received 48 RFC editor comments, which have been addressed. The working group hopes for RFC publication before IETF 116.
*   **`drip-arch` (Time Sources - Section 8.5)**:
    *   A concern was raised that text in Section 8.5, specifically references to "satisfy FAA which is USA only specify used by the USA government's operating GPS," is too USA-centric for an IETF global standard.
    *   The author explained this text was added to address an AD's comments about time precision and requested assistance in generalizing precision requirements for other Global Navigation Satellite Systems (GNSS).
    *   The discussion also touched on the use of 32-bit Unix timestamps (which are specified in ASTM F3411 and thus outside DRIP's direct control for that context, though an offset extends their utility beyond 2038) and the need to define a globally appropriate level of time and location precision for DRIP devices.
    *   A proposal was made to rephrase the text, potentially by framing the USA-specific details as an example or by removing the nationality-specific language.
*   **`drip-auth` (SAM Type Registry)**:
    *   The ASTM-ICAO interaction regarding ICAO's role as the registrar for SAM type code points (defined in ASTM F3411) remains stalled, as ASTM awaits an official response from ICAO. This situation is currently blocking further progress on `drip-auth`.
    *   The ASTM F3411 allocation process for these code points follows an expert review model, similar to IANA.
    *   ICAO representatives confirmed that the request is being processed but, due to the involvement of member states and legal review, they cannot guarantee a resolution by IETF 116 (late March).
    *   Options for resolution were discussed, including continuing to wait for the ASTM-ICAO agreement, or exploring ASTM potentially delegating the registrar role to IANA as a fallback.
    *   A sense of those present indicated that the working group should continue to wait for ICAO's response but develop a "Plan B" if no significant progress is made by IETF 116.
*   **`drip-auth` (GitHub Issue #29 - "pseudo blockchain")**:
    *   The term "pseudo blockchain" was identified as problematic and potentially misleading. The original intent was to illustrate the concept of a linked chain of hashes, not to imply a specific distributed ledger technology.
    *   Following a brief discussion, a sense of those present was to replace "pseudo blockchain" with "ledger" and to provide clarifying text.
*   **`drip-registries` (DIME Architecture)**:
    *   The document has evolved to define a "Drip Identity Management Entity" (DIME) architecture, focusing on Debt registration and lookup interfaces for public and private information. This system uses a two-level endorsement hierarchy, akin to x.509 PKI augmented by DNS.
    *   **DNS Delegation Model**: A model similar to E.164 ENUM was proposed, where ICAO (analogous to ITU) would delegate IPv6 prefixes for UAS Remote ID (RID) at a national level to National Aviation Authorities (NAAs). This model aims to minimize direct ICANN involvement.
    *   **DNS for DEBTs**: Discussion covered placing DEBTs (IPv6 addresses) in `ip6.arpa` using nibble-reversed format, and potentially utilizing H-ID and NAFTA resource records for lookups.
    *   **DNS for Serial Numbers**: Integration of serial numbers (defined by ANSI/CTA, with manufacturer codes from ICAO) into DNS (e.g., `sn.uas.arpa`) was discussed. The concept of encoding a DEBT into a serial number, which is crucial for certain UAS RID modules, was highlighted.
    *   **Privacy Concerns**: A critical point was emphasized that the lookup mapping a DEBT to a serial number must *never* be publicly available in DNS, as this constitutes Personally Identifiable Information (PII). Such lookups must be handled by a private registry.
    *   **NAFTA Records**: The complexity of NAFTA records was weighed against simpler URI records. While NAFTA offers flexibility (e.g., encoding query names in URIs for specialized access), its complexity necessitates careful documentation and specification to avoid undesirable implementations.

## Decisions and Action Items

*   **`drip-arch` (Section 8.5 - USA-centric text)**: The Chair will draft a Pull Request to propose revised wording (e.g., adding "for example" or generalizing the statement) for Section 8.5 of `drip-arch` to address the USA-centric language.
*   **`drip-auth` (SAM Type Registry)**: The working group will continue to await ICAO's official response regarding the SAM type code point registrar. A re-evaluation will occur at IETF 116 to determine a "Plan B" if no significant progress has been made.
*   **`drip-auth` (GitHub Issue #29 - "pseudo blockchain")**: Adam will update the `drip-auth` document to replace the term "pseudo blockchain" with "ledger" and provide clarifying text.
*   **General Action**: All working group participants are strongly encouraged to review the open issues on GitHub for both `drip-auth` and `drip-registries`. Contributions in the form of comments, proposed solutions, or pull requests are requested prior to IETF 116.

## Next Steps

*   Continue to monitor the progress of the ASTM-ICAO interaction for SAM type code point allocation.
*   Implement the proposed changes to `drip-arch` and `drip-auth` as per the action items.
*   Further refine the `drip-registries` architecture, focusing on the DNS delegation model, serial number handling, and the definitive choice and specification of DNS resource records (e.g., NAFTA vs. URI records), with a paramount focus on avoiding the public exposure of PII.
*   Prepare for detailed discussions on these topics at the IETF 116 meeting in Yokohama, aiming for substantial progress rather than a mere recap of issues.