Early Review of draft-ietf-drip-registries-18
review-ietf-drip-registries-18-dnsdir-early-blacka-2024-10-31-00

This document was a little difficult to get into because DRIP has a lot of
terminology and background that I wasn't familiar with.  It was unclear
initially whether or not the background was needed to understand this I-D.
Familiarity with the terminology should help as the density of acronyms made
this reviewer's head spin.

For example, from Section 1.1 (General Concept):

    DETs embedded a hierarchy scheme which is mapped onto DNS. DIME's enforce
    registration and information access of data associated with a DET while also
    providing the trust inherited from being a member of the hierarchy. Other
    identifiers and their methods are out of scope for this document.

To translate this by simply expanding the acronyms:

    Drone Remote Identity Protocol Entity Tags embedded a hierarchy scheme which
    is mapped onto [the] Domain Name System.  Drone Remote Identity Protocol
    Identity Management Entities enforce registration ...

While not specifically DNS related, I think this draft would benefit from
spelling out the acronyms on first use.  It does point to other normative RFCs
for the actual definition of the terms so I don't expect the terms to be
defined in the draft.

At a high level, this I-D basically says:

* The DRIP identifier is encoded as a non-routable IPv6 address.  After the IANA
assigned prefix, the next bits are (group)(sub-group), so we can create normal
DNS delegations at (group) and (sub-group) levels.

* We can put records in the IPv6 reverse DNS the normal way, by following the
standard IPv6 reverse space conventions.

* Standard metadata for the identifiers are to be put in two new record types at
the leaf nodes (i.e, the full IPv6 address entries.)

It posits that there could be a full "RRR" (Registry, Registrar, Registrant)
ecosystem for this, or an abbreviated version of that ecosystem.  All of this
seems reasonable.

Section 5 "Canonical Public Registration Certificate" seems to come out of the
blue.  I'm not sure what this certificate is for, where it goes, or why it
refers to Appendix A, which doesn't mention it. Also, section 5.1 talks about
using a URI extension in the certificate, but the example doesn't have one.

I have no comment on the contents of section 8, but since it is, in fact, a
security consideration, shouldn't it be Section 7.2? (i.e., under the security
considerations.)

This I-D defines two new resource record types.  Given that the ultimate purpose
of this draft is to put these new records in the DNS, I find it a little odd
that the definitions are relegated to appendices.  Further, using CBOR to define
the wire formats is quite new to me.  Have other new DNS RR types used CBOR?  At
a high level this seems OK, CBOR is an IETF standard after all.  But all other
DNS Resource Record definitions do not use CBOR, and just describe the straight
binary format of the record.

While this draft does define a presentation format for the new RR types, using
the Extended Diagnostic Notation for it does not make it clear to DNS
implementers what the actual text representation should look like.  What we are
expecting to see are example full zone file format records.

The draft worries a bit about the fact that the RAA (e.g., country code) field
is 14 bits long, thus doesn't fall on a nibble boundary.  To avoid splitting the
nibble, it just takes the top two bits from the next field (HDA).  I think this
is just what you would do in a normal non-label boundary IPv6 allocation (which
maybe nobody does), it is just that each RAA would only get 4 of the 16
possible nibble values.  It is possible that I don't quite understand this part
of the proposal, however.

Overall, I'd say that this I-D is on the correct track: at a high level the
basic concepts appear to make sense, but the details need work.