Early Review of draft-ietf-drip-registries-09
review-ietf-drip-registries-09-opsdir-early-jaeggli-2023-06-12-00

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.