Reviewer: Brian Haberman Review result: Ready with Nits 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
