This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review.

Status: Ready (with TSVART-nonspecific LC comments)

I don't see any novel transport issues in this document: there is precedent for everything being proposed, with explicit references to existing RFCs.


Putting my individual reviewer hat on, however:

> Only sending the DET and a signature on frequently changing data that can be sanity-checked by the Observer (such as a Location/Vector message) proves that the observed UA possesses the claimed UAS ID.

"Frequently changing" is not the right standard for preventing replay attacks: "novel" is. The idea is that the sender needs to sign data that has never been signed before and moreover that the receiver knows *a priori* would never have been signed by the key owner before. This is why, for instance, time codes are frequently used in such constructions: because time flows in only one direction, everyone has the ability to agree on what the current time is (even in a scenario in which participants are moving at relativistic speeds, a single reference frame can be chosen arbitrarily as the basis for the shared time scale), and no properly-functioning implementation would sign a future time code.

> For that it MUST be registered (under DRIP Registries) and be actively used by the party (in most cases the UA).

"Must" should probably be lowercase given that this is an informational document. Moreover, given the document overall takes the approach of making recommendations to others about how they can use IETF protocols in their technology space, and given that the IETF is not the protocol police, such recommendations really should be suggestions ("may be registered using such-and-such a protocol") rather than normative requirements.

Nits aside, my main issue with this draft boils down to one question: why is this work happening at the IETF? In brief, the draft covers the following high-level recommendations:

* Construction of an identifier for which only the owner can attest ownership (section 3)

* Use of DNS as a registry for such identifiers (section 4)

* Maintaining trust over time in messages from a given sender without on-going access to a trusted third-party (section 5)

* Link-layer concerns (section 6)

* Bootstrapping a persistent secure channel using identifiers currently trusted (section 7)

None of these requires internet standards development unique to drone identification.

It seems like the proper standards venue for this work is an aircraft or aerospace regulatory SDO, with liaisons from the IETF acting as subject matter experts for use of and integration with IETF protocols. If there is a broad category of users that heavily leverage internet technologies or that will likely impact protocol performance, there is precedent for the IETF forming a non-standards-developing operations group (akin to MOPS, a WG I co-chair) providing a forum within the IETF for the formulation and dispatch of requirements to appropriate function-specific WGs, both within and without the IETF, for further standards activity.

Based on some early feedback I received, I want to make clear that I am *not* suggesting that the process for setting up a working group was not followed in the case of drip; rather, I am suggesting the process produced the wrong outcome. Working groups with very tangential relevance to the core mission of the IETF---development and maintenance of internet transports and their prerequisites---are a distraction that consumes valuable resources. While I risk sounding like Abe Simpson with this objection (https://www.youtube.com/watch?v=O5dmxBUbzBU), I know I am not the only one who has expressed concern over scope creep within the IETF, so taking this opportunity to highlight an example seemed worthwhile.