[Drip] Paul Wouters' No Objection on draft-ietf-drip-rid-32: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-drip-rid-32: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-drip-rid/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

OLD DISCUSSES:

#1

   Note that if the zone hhit.arpa is ultimately used, some registrar
   will need to manage this for all HHIT applications.

Regardless of what zone is used, someone needs to keep it operational.
It might be an attractive target to attack, eg to try and avoid drones
being shut down. I would feel much better if this zone was optional,
not mandatory. (but if optional, one could also argue maybe not have it
at all?)

   If the HHITs cannot be
   looked up with services provided by the registrar identified via the
   embedded hierarchical information or its registration validated by
   registration attestations messages [drip-authentication], then the
   HHIT is either fraudulent or revoked/expired.

That's quite catastrophic if there is a Registrar/Registry outage. Would
all the drones get shot down or would they all be ignored (so they can
fly to their terrorism target)

#2

As DISCUSS'ED by others,
https://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hi-algorithm
does not seem to have a third field for "status" to denotate RECOMMENDED,
REQUIRED, etc, even though RFC 7401 creates the registry, uses the terms too
but doesn't populate a status field. Perhaps this or another short RFC could do
so.

Also, 3.4.1 calls this "Algorithm profiles" and "Values" but the IANA registry
calls it "Algorithm Profile" (singular) and "Value" (singular)

#3

Section 3.4.1.1. has a NULL field of variable length ? Or perhaps the
slash and pipe symbols on those first and second lines got swapped by
accident?

#4

   The new EdDSA HI uses [RFC8080] for the IPSECKEY RR encoding:

      Value  Description

      TBD2 (suggested value 4)
             An EdDSA key is present, in the format defined in [RFC8080]

I have asked the Expert of this Registry whether they are okay with this
entry to the ipseckey-rr-parameters registry. It might be confusing for IKE.

COMMENTS:

#1

   100.hhit.arpa   IN PTR      raa.example.com.

Please add a trailing dot, eg "100.hhit.arpa."

Similarly for:

    100.50.det.uas.icao.int   IN PTR      foo.uss.icao.int.

#2

      HIP DNS RR (Resource Record)

Add reference to RFC5205 on its first mention.

#3

    However, this document does not intend to provide a recommendation.

weasel wording. It should probaby just state "this document does not provide
a recommendation."

#4

   The individual DETs may be potentially too numerous (e.g., 60 - 600M)
   and dynamic (e.g., new DETs every minute for some HDAs) to store in a
   signed, DNS zone.

This can be achieved with online signing. I would remove this speculative
sentence unless it is backed by some real numbers.