Skip to main content

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

Request Review of draft-ietf-drip-rid
Requested revision No specific revision (document currently at 37)
Type Last Call Review
Team Internet of Things Directorate (iotdir)
Deadline 2022-05-11
Requested 2022-04-27
Requested by Éric Vyncke
Authors Robert Moskowitz , Stuart W. Card , Adam Wiethuechter , Andrei Gurtov
I-D last updated 2022-05-04
Completed reviews Secdir Early review of -07 by Magnus Nyström (diff)
Iotdir Early review of -07 by Michael Richardson (diff)
Intdir Last Call review of -26 by Pascal Thubert (diff)
Iotdir Last Call review of -24 by Brian Haberman (diff)
Genart Last Call review of -24 by Elwyn B. Davies (diff)
Comments
A special domain of usability, so a review by IoT and INT directorates will be welcome. Another doc draft-ietf-drip-arch is probably a nice introduction read (still missing the INT directorate review).

Thank you. 

-éric
Assignment Reviewer Brian Haberman
State Completed
Request Last Call review on draft-ietf-drip-rid by Internet of Things Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/c3YJrX_EeTSWUXzsXvpBYYjoPuk
Reviewed revision 24 (document currently at 37)
Result Ready w/nits
Completed 2022-05-04
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.