DRIP Entity Tags in the Domain Name System
draft-ietf-drip-registries-33

Thanks. I believe all my DISCUSS items have been addressed.

Thanks to Derrell Piper and Christian Huitema for their many secdir reviews.

I’ll admit this draft is a bit outside my technical comfort zone, but I gave it a good try and worked to understand the concepts. That said, I did find parts of the text a little confusing, maybe it’s just because this area isn’t my expertise, or perhaps because the abstract could do a better job of setting the stage. For example, I wasn’t immediately clear that this is focused specifically on UAS entities, is it?.

Would the following version of the abstract be a more accurate and clearer alternative?

"
This document defines a DRIP (Drone Remote Identification Protocol) entity tag-based hierarchical registry structure and associated processes to facilitate trustable and scalable registration and lookup of information related to Unmanned Aircraft Systems (UAS). The registry system supports issuance, discovery, and verification of DRIP Entity Tags (DETs), enabling secure identification and association of UAS and their operators. It also defines the interactions between different classes of registries (root, organizational, and individual) and their respective roles in maintaining the integrity of the registration data. This architecture enables decentralized, federated operation while supporting privacy, traceability, and regulatory compliance requirements in the context of UAS Remote ID and other services.
"

Would it make sense to expand and normative reference towards a RFC when th word DRIP is used the first time in the draft?

G/

Thank you for the revision; IANA has confirmed that the updated link is acceptable.

=== PREVIOUS DISCUSS ===
The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is specified as a CSV file on the main branch of a GitHub repo. This seems problematic in two ways:

- First, it is not an archival resource; future commits to the GitHub repo could modify it without notice. At the very least, this should link to the version of the file in a specific commit so that it cannot change without modifying the link in the document.

- Second, the link does not appear in the document's references and probably should.

I'm sympathetic to the desire not to add a 4k row table in an appendix. Have you collaborated with IANA on the best way for them to receive the initial values of this registry?
=== /PREVIOUS DISCUSS ===

I second Gunter's observation that this document does not cater to new readers. The term DRIP is not introduced in the document, and RFC9153/RFC9434 is not clearly associated to this acronym to help anyone figure it out. There are several unfamiliar abbreviations just in Figure 1, which should be setting the framework for understanding the rest of the document. (GCS, AAA, etc.) While I appreciate the pointer to RFCs 9153, 9374, and 9434 for terminology, a list of the terms being imported from them would be useful to help readers look up terminology as needed. A brief explanation of what DRIP is and what role this document's work plays in that would go a long way.

Related, I don't see a definition or reference for the term "nibble revers(ed|ing)" beyond "convention". You already have the STD88 reference, which uses similar language; I'd just point to it where appropriate. (From STD88, "The sequence of nibbles is encoded in reverse order, i.e. the low-order nibble is encoded first, followed by the next low-order nibble and so on. Each nibble is represented by a hexadecimal digit.")

The "Canonical Registration Certificate" is mentioned as a field in the HHIT RRType without further context about what this is or how it is used. Please provide references inline as appropriate.

In Section 5.2, I was not able to parse the phrase "public information typically sent of the UAS Broadcast RID that is static". Is there a missing or substituted word here? If not, is there a different word order that would be easier to understand?

In Section 6.1, the DE's authority is confusing to me in two ways. First, if the DE is "expected to process these delegation requests on a first-come, first-served basis," what need is there for the DE? Just permit IANA to allocate this space directly. Second, what does it mean that "[t]he DE will have the discretion to perform minimal technical checks" if the DE "[can]not enforce these"? Again, performing unenforceable checks could be done by any member of the public and doesn't require a DE.

I note that the raft of DNS BCPs and RFCs to which security guidance is delegated are all informational. This may be correct, as this is guidance rather than a compatibility requirement, but please double-check that you don't intend any of these to be normative.

===NITS FOLLOW===

Abstract, "DRIP specific" => "DRIP-specific"

Section 4, "UAS specific" => "UAS-specific"

Section 5.1, "HHIT specific" => "HHIT-specific"

Section 6.1, "ie" => "i.e."

Section 7.1, "following RFC" => "following RFCs" (or just drop it entirely, e.g. "[RFC7720], ...., and [RFC3007] provide suitable guidance.")

# Orie Steele, ART AD, comments for draft-ietf-drip-registries-29 
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-drip-registries-29.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/


## Comments

I support Roman and Andy's DISCUSS.

### Use of Existing DNS Models

```
240	3.1.  Use of Existing DNS Models
```

Perhaps this section could be removed / reduced to a reference?


### Possible solutions

```
332	   Dynamic DRIP registration is another possible solution, for example
333	   when the operator of a UAS device registers its corresponding HHIT
334	   record and other resources before a flight and deletes them
335	   afterwards.  This may be feasible in controlled environments with
```

For a proposed standard, I would expect clearer guidance on when to choose each solution, not a survey of possible solutions.


### Out of scope, but in the the document

```
344	   others).  All of these are out of scope for this document.  The
345	   specifics for the UAS RID use case are detailed in the rest of
346	   document.
```

Probably the informative text could be drastically reduced, since the operational details of the existing normative dependencies are out of scope for this document.


### SHOULD not MUST

```
369	   DNSSEC is strongly RECOMMENDED.  When a DIME decides to use DNSSEC
370	   they SHOULD define a framework for cryptographic algorithms and key
371	   management [RFC6841].  This may be influenced by frequency of
372	   updates, size of the zone, and policies.
```

Why note MUST? When is it recommended to use DNSSEC without defining such a framework?
This is also a downref, does not appear to have been called out.


### Text Representation

```
407	   The data are represented in base64 [RFC4648] and may be divided into
408	   any number of white-space-separated substrings, down to single base64
409	   digits, which are concatenated to obtain the full object.  These
410	   substrings can span lines using the standard parenthesis.  Note that
411	   the data has internal subfields but these do not appear in the master
412	   file representation; only a single logical base64 string will appear.
```

I don't understand "substrings can span lines using the standard parenthesis".

It seems like this is just white space separated base64 strings, which MUST be concatenated, before they can be decoded to the binary data.

This section seems repeated needlessly in:

```
470	5.2.1.  Text Representation
```

Consider refactoring to a reference.

### Consider and EDN example

```
416	   The data MAY, for display purposes only, be represented using the
417	   Extended Diagnostic Notation as defined in Appendix G of [RFC8610].
```

An elided example could improve this section, especially since what immediately follows is CDDL not EDN.
You might also consider a reference to the appendix of this document.

### IANA Considerations

```
555	   The DE will check delegation requests for DET address space that get
556	   submitted to IANA.  Since there is no control over who submits these
557	   delegation requests or the address space they refer to, a degree of
558	   checking is necessary.  The DE will liaise with IANA on the outcome
559	   of these checks.
```

Will the DE requests and related discussions be conducted on a public mailing list?


```
577	   The DE will be expected to liaise with IANA to develop a DNSSEC
578	   Practice Statement for delegations in 3.0.0.1.0.2.ipv6.arpa. if/when
579	   there’s a demand for DNSSEC deployment for DRIP.
```

This feels like it might be better accomplished with specification required registration policy.


### ISO 3166-1 Numeric Nation Codes and RAAs

```
626	   The mapping between ISO 3166-1 Numeric Nation Codes and RAAs is
627	   specified as a CSV file on GitHub (https://github.com/ietf-wg-drip/
628	   draft-ietf-drip-registries/blob/main/iso3166-raa.csv).  Each Nation
```

I assume this github link will be removed in the future?

### Normative guidance in security considerations

```
764	   for DNSSEC Policies and DNSSEC Practice Statements.  A self-signed
765	   entity (i.e. an entity that self-signed it certificate as part of the
766	   HHIT RRType) MUST use DNSSEC.
```

This requirement should be called out in the body of the document.


### influence security SHOULD

```
776	   Decisions about DNS or registry best practices and other operational
777	   matters that influence security SHOULD be made by the CAA, ideally in
778	   consultation with local stakeholders.
```

I don't understand how to implement this should.
Is this establishing some relationship between the CAA and EPP operational guidance?
Consider referring to BCPs here, and framing this as a recommendation to deviate from BCPs only with the express support of the CAA, or similar framing.


### Section 7.5 of RFC9374 does not exist

```
795	   When DNSSEC is not in use, due to the length of the ORCHID hash
796	   selected for DETs (Section 7.5 of [RFC9374]), clients MUST "walk" the
```

I think you mean Section 3.5

### ORCHID Validation Procedures

```
795	   When DNSSEC is not in use, due to the length of the ORCHID hash
796	   selected for DETs (Section 7.5 of [RFC9374]), clients MUST "walk" the
797	   tree of certificates locating each certificate by performing DNS
798	   lookups of HHIT RRTypes for each DET verifying inclusion into the
799	   hierarchy.  The collection of these certificates (which provide both
800	   signature protection from the parent entity and the public key of the
801	   entity) is the only way without DNSSEC to prove valid registration.
802	   The data within the BRID RRType has no direct endorsement when not
803	   protected by DNSSEC.  The contents of the BRID RRType auth key,
804	   containing the Endorsements, SHOULD be validated, similiar to the
805	   certificates mentioned previously.

```

Requirements for clients should be introduced in the body of the document.
Faults in the validation procedure or issues with key compromise should be discussed in the security considerations.

Under which cases can "SHOULD be validated" be ignored, or be made mandatory?


### Security impact of signaling

```
823	   Optimally this requires that the UAS somehow signal the DIME that a
824	   flight using a Specific Session ID will soon be underway or complete.
825	   It may also be facilitated under UTM if the USS (which may or may not
826	   be a DIME) signals when a given operation using a Session ID goes
827	   active.
```

I don't follow why this is in the security considerations.

### Guidance to registry

```
772	   the Extensible Provisioning Protocol (EPP) [STD69].  The registry
773	   SHOULD provide a lookup service such as WHOIS [RFC3912] or RDAP
774	   [STD95] to publish public information about registered domain names.
```

Is this new guidance to registries to support DIME?

When can this SHOULD be ignored?

Guidance related to the core operation of the protocol should be in the body of the document.


## Nits

#### AAA expand of first use

```
157	   This document does not specify AAA mechanisms used by Private
```

Thank you for the updates to respond to my DISCUSS and COMMENT feedback.

===
** Can guidance be given on when the recommendations made here should be ignored?

-- Section 7.1
   The Registrar and Registry are commonly used concepts in the DNS.
   These components interface the DIME into the DNS hierarchy and thus
   operation SHOULD follow best common practices, specifically in
   security (such as running DNSSEC) as appropriate.

-- Section 7.1
   If DNSSEC is used, a DNSSEC Practice Statement SHOULD be developed
   and published.  It SHOULD explain how DNSSEC has been deployed and
   what security measures are in place.  

-- Section 7.1
   The contents of the BRID RRType auth key,
   containing the Endorsements, SHOULD be validated, similiar to the
   certificates mentioned previously.

Under what circumstances would these best practices or validation be ignored.