Last Call Review of draft-ietf-drip-rid-24
review-ietf-drip-rid-24-iotdir-lc-haberman-2022-05-04-00

I am the IoT Directorate reviewer for this draft. Please treat these comments
as normal last call comments.

From an IoT perspective, I believe this draft is nearly ready and I do not see
anything described here that would be an impact on IoT devices. I only came
across a few nits that may be worth addressing. Please let me know if you would
like to discuss any of these...

1. In the Introduction, it mentions a 20-character identifier and references
ID-1 from the DRIP requirements document. That requirements document calls out
a 19-byte identifier. Can you clarify?

2. In 2.3, the definition of a HIT is indicated to be 128 bits long, but there
is not an indicated length for HHITs. The later definition of HHIT generation,
in section 3.5, tells me it is also 128 bits long, but it may be good to
clarify this definition.

3. Section 3 - similar to the comment above, the second paragraph omits the
28-bit prefix in its description of the HHIT, which initially led me to think
of the HHIT as being 100 bits long.

4. The HHIT Suite ID description in section 3.2 is a bit confusing. It appears
that the registry described is for the 8-bit enhanced Suite ID, but it is
unclear why value 16 is marked as RESERVED.

5. Section 3.2.1 - Private Use reservations in IANA registries have been
problematic in some instances. Is there a risk of "de facto standardization" in
those two private use reservations? Would it make more sense to allow for
provisional allocations that could be transitioned to permanent ones?

6. Section 3.3.1 - I see a few instances of lower-case "must" here that could
be read as needing to be "MUST" (e.g., maintaining a DNS zone) for
interoperability reasons.

7. Section 3.3.1 - I would suggest changing "raa.bar.com" to "raa.example.com"
to comply with the rules for using domain names in documents.

8. Section 3.4.1.1 - The EdDSA Curve field is populated using the values from
figure 2? The 16-bit field adjacent to the EdDSA Curve field is Reserved?

9. Section 4.2 discusses the use of DNSSEC to provide trusted mappings and
section 5 talks about DNS-over-TLS as a viable alternative to DNSSEC. Later in
the document, it states that this document will not make any firm
recommendations on the mapping service. I will note that DNS-over-TLS is not a
sufficient replacement for DNSSEC as they address two different problems.
Additionally, DNS-over-TLS does define two different profiles of operation.
Please ensure that another document discusses the functions needed in this
mapping service and provides MTI guidance to ensure there is always an
available mapping service in all use cases.

10 Section 8.1 - I am not sure why "Reserved-by-Protocol" is listed as
"False?". Given that these identifiers are indistinguishable from IPv6
addresses, do you want all IPv6 implementations to handle these in a special
way if they are seen as either a source or destination address? Similar to
ORCHID, I would expect this value to be FALSE.