Greetings, I have reviewed https://datatracker.ietf.org/doc/draft-ietf-drip-registries/ on behalf of the Operations and Managament area. this is an early review so take it with a grain of salt. --- Section 5.3 us underspecified at a minimum for the normative operation of a nameserver providing services. (the authors note this) 5.3. Name Server (NS) The interface of the Name Server to any component (nominally the Registry) in a DIME is out of scope as typically they are implementation specific. Author Note: This may be very important here as we should not preclude a USS from running his own Name Server but they are not DNS experts and will need guidance or at least pointers to it to not mess it up. Such as SOA and NS formats to allow delegation if as RAA. In particular name resolution for UAS registries seems like the sort of application that should come with language about availability as a potentially life-critical system. --- I struggle with the descriptions in section 6.1 6.1. Serial Number There are four ways a Serial Number is supported (by DRIP): 1. As itself as a clear-text string with additional information 2. As itself as a clear-text string mapped to a DET "post" generation by the manufacturer (for use in authentication) and additional information 3. As itself as a clear-text string mapped to a DET "post" generation by the user (for use in authentication) and additional information 4. As an encoding of an HI and associated DET by the manufacturer (for use in authentication) with additional information these could be both tightened up and be more clear if written as something like the following track backing and forth between the explanitory notes or the cases should end up being 4 sub headings e.g. 6.1.1 2/3/4 and not simply a list. 6.1. Serial Number There are four ways a Serial Number is supported (by DRIP): 1. A clear-text string with additional information The case where a UA is provisioned with a Serial Number by the manufacturer. The manufacturer is runs an MAA and uses the mechanisms of this document to provide additional information. 2. A clear-text string mapped to a DET "post" generation by the manufacturer (for use in authentication) and additional information A UAS is provisioned with a Serial Number and DET by the manufacturer enabling their devices to use [drip-auth] and provide additional information. A public mapping of the Serial Number to DET and all public artifacts MUST be provided by the manufacturer. This document RECOMMENDS the manufacturer use an MAA for this task. 3. A clear-text string mapped to a DET "post" generation by the user (for use in authentication) and additional information where a UAS has a Serial Number (from the manufacturer) and the user has a mechanism to generate and map a DET to the Serial Number after production. This can provide dynamic signing keys for DRIP Authentication Messages via [drip-auth] for UAS that MUST fly only using Serial Numbers. Registration SHOULD be allowed to any relevant DIME that supports it. 4. As an encoding of an HI and associated DET by the manufacturer (for use in authentication) with additional information where a UAS manufacturer chooses to use the Serial Number scheme defined in [RFC9374] to create Serial Numbers, their associated DETs for [drip-auth] and provide additional information. This document RECOMMENDED that the manufacturer "locks" the device from changing its authentication method so identifiers in both the Basic ID and Authentication Message do not de-sync. The manufacturer MUST use an MAA for this task, with the mapping between their Manufacturer Code and the upper portion of the DET publicly available. --- section 6.3.1 6.3.2 should be labeled properly as session-ids --- section 7 is observably incomplete It is noted by the authors that as this system scales the problem becomes a, well known and tricky, key management problem. While recommendations for key management are useful they are not necessarily in scope for this document as best common practices around key management should already be mandated and enforced by the cognizant authorities in their existing systems. This document instead focuses on finding a balance for generic wide-spread interoperability between DIMEs with authorities and their existing systems in a Differentiated Access Process (DAP). at a minimum the key managment problem should be elucidated DRIP has no intention to develop a new "art" of key management, instead hoping to leverage existing systems and be flexible enough to adapt as new ones become popular. --- ICAO administered domain apex sounds like this is specifying a type of TLD, if it is not then what is described should be more narrowly specified. if it does this is ietf direction to ICANN 8. DRIP in the Domain Name System Per [drip-arch] all information classified as public is stored in the DNS to satisfy REG-1 from [RFC9153]. The apex for domain names MUST be under the administrative control of ICAO, the international treaty organization providing the critical coordination platform for civil aviation. ICAO SHOULD be responsible for the operation of the DNS-related infrastructure for these domain name apexes. It MAY chose to run that infrastructure directly or outsource it to competent third parties or some combination of the two. ICAO SHOULD specify the technical and administrative criteria for the provision of these services: contractual terms (if any), reporting, uptime, SLAs (if any), DNS query handling capacity, response times incident handling, complaints, law enforcement interaction and so on. --- DNS review should probably come from a DNS SME for additional considerations.