[Iot-directorate] Iotdir early review of draft-ietf-drip-rid-07

[Michael Richardson via Datatracker <[e-mail]>]

Reviewer: Michael Richardson
Review result: Almost Ready

Reviewer: Michael Richardson

Review result: Ready with Nits
Document: draft-ietf-drip-rid-07
Summary: Almost Ready

I have done an IoT-Directorate review of draft-ietf-drip-rid-07.
I think that I have previously read the document prior to WG adoption.

While the core content of the document is all present, and it would appear
that code could be written from it,  the text in the document is pretty
rough shape.

The document needs an editorial pass to make the language a bit less abrupt.

There is a lot of content in the appendixes (more than 70% or so), and I
didn't see a lot of forward references to them.  Do we need them all?


Nits:

I stumbled on the very first sentence:

  [drip-requirements] describes a UAS ID as a "unique (ID-4), non-spoofable
  (ID-5), and identify a registry where the ID is listed (ID-2)"; all within
          ^^^^^^^^^^^^^^^ <- just does not flow with the rest of the sentence.
  a 20 character Identifier (ID-1).

In general, I'd rather that the first word wasn't a reference.
Maybe just move that sentence to the end of the Introduction, or at least
maybe two or three paragraphs down.

s/This is in contrast to general IDs (e.g. a UUID or device serial number) as
       the subject in an X.509 certificate./
  This is in contrast to using general IDs (e.g. a UUID or device serial number) as
       the subject in an [RFC5280] X.509 certificate./

a) please expand "CA" in the intro on first use.
b) please consider if this just belongs in Security Considerations.
   "In a multi-CA PKI, a subject can occur in multiple CAs, possibly
   fraudulently. CAs within the PKI would need to implement an approach to
   enforce assurance of uniqueness."

Maybe write:
   "The use of multiple Certification Authorities (CA), such as used for the
   public WebPKI comes with the risk of duplicates among the different CAs.
   These can occur due to fraud or error, and to date the WebPKI has not
   found a way to prevent this, only to detect the occurance afterwards.
   [reference to certtrans]

} 1.1. Nontransferablity of HHITs
} HIs and its HHITs SHOULD NOT be transferable between UA or even between
} replacement electronics for a UA. The private key for the HI SHOULD be held
} in a cryptographically secure component.

I agree that this is true.  But, I think that some additional explanation is
waranteed.  I know that we had the discussion about rebuilding entire air
frames, where every single component is changed, and yet, it's the same
airframe.

} TYPE-3
} A UTM system assigned UUID [RFC4122], which can but need not be dynamic.

maybe write:
      A UTM system assigned UUID [RFC4122]. These can be dynamic, but
      do not need to be.

} 3.1. Hierarchical HITs encoded as CTA-2063-A Serial Numbers

please give me an example of a CTA-2063-A serial number, and please give me
an example of a HHIT encoded as one.... AHA. Appendix B.4, so a forward
reference, please?... ah, but no actual example in B.4.

3.3:
} The justification then was attacks against these fields are DoS attacks
  against protocols using them.

Please reword, as this doesn't look like a sentence to me.

} The individual HHITs are potentially too numerous (e.g. 60 - 600M) and
} dynamic to actually store in a signed, DNS zone.

This point has been disputed before. .com is much larger,  and we don't have 600M
of them on day one.  I.e. by the time we really have 600M of them, then there
will be a business justification for investing in the required hardware.

section 9, please start by explaining what a HHIT hijacking *is*, and what
        the operational impact of such a thing occuring is.