Drone Remote Identification Protocol (DRIP) Architecture
draft-ietf-drip-arch-31

This I-D was on hold since July 2023 waiting for a revised I-D that:
- addresses all DISCUSS (and most COMMENT) points raised during IESG evaluation and some directorate reviews
- get the confidence of the responsible AD that this architecture draft will be compatible with the I-D in cooking (notably -auth)

[Ballot comment]
Thank you to Valery Smyslov for the SECDIR review.

Thanks for the revised text in -25 to -29, and the revisions in drip-auth and drip-registries referenced here.

Was a DISCUSS.  Per https://mailarchive.ietf.org/arch/msg/tm-rid/SSkTnaBgxkbw1yWyuciXyFTTa6M/:

> > ** Section 9
> >    Broadcast RID messages can contain Personally Identifiable
> >    Information (PII).  A viable architecture for PII protection would be
> >    symmetric encryption of the PII using a session key known to the UAS
> >    and its USS ...
> >
> > Per “A viable architecture ...”, I’m not sure how to read all the text after
> > the first sentence given this phrasing.  Is the rest of the text the official
> > “DRIP architecture” or an example? I’m assuming the former and believe it would
> > benefit from its own set of security considerations.  A few initial questions:
> >
> > -- Are there channel security requirements between the decryption oracle/key
> > escrow or distribution server/USS and the Observer?
> >
> > -- Is there a strong authentication/authorization model to gain services from
> > the USS?
> >
> > -- How does this oracle or key server approach work in the case an offline
> > observer?

> One proposal for this is
>
> https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/
>
> It also deals with policy of use, like MUST NOT be used when there is no
> Internet for Authorized Observers to get keys.
>
>This one gets into a bit of airspace politics.
>
> I think the text is as specific it can be without pointing to
> drip-operator-privacy.

You answered my question which is the this is a notional architecture so I won’t poke at it as being able to be implemented as is with the text.  I strongly recommend you drop most of this language and focus on describing the properties of the desired solution and how they need to be solved by operational deployments.  Defining notional parts of a candidate solution creates confusion on the bounds of the DRIP architecture.
From https://mailarchive.ietf.org/arch/msg/tm-rid/SSkTnaBgxkbw1yWyuciXyFTTa6M/:

> > ** Section 1.2.1.  This section discusses a “range up to approximately 1 km”,
> > notes “smartphones” as endpoints, and cites Bluetooth and WiFi as the wireless
> > technologies.  Even with line of sight, these seem like very long ranges
> > without specialized antennas (i.e., not on a smartphone).
>
> Actual field work has shown these distances achieved and there is a
> general push from many sources to use these numbers.

RF propagation is not my area of expertise.  I am surprised about a usable range of 1km for Bluetooth 5.* with commodity antennas. If you do have a reference, please include it.

> ** Section 2.1
>
>    DRIP could address standardization of
>    secure protocols between the UA and GCS (over direct wireless and
>    Internet connection), between the UAS and the Net-RID SP, and/or
>    between the Net-RID DP and Observer devices.
>
> Can this text be clarified?  Does this hypothetical make sense in an archival
> document?
>
> draft-moskowitz-drip-secure-nrid-c2

I don’t follow why a WG document is forward referencing an unadopted body of work.  I leave it to the WG to assess whether possible future DRIP work should be referenced here.



> > ** Section 4.2.  What information is being put into the Private Information
> > Registry?
>
> Policy of RAA and HDA. Covered in [I-D.ietf-drip-registries] , but
> generally out of scope as it will be up to each to decided what to
> require and then make available to authorized users.  You don't like
> what one RAA|HDA is asking of you, try another.

Recommend a specific pointer in drip-registries.

> > ** Section 8.1
> >
> >    Leakage of the private
> >    key either from the UA or GCS to the component manufacturer is a
> >    valid concern and steps need to be in place to ensure safe keeping of
> >    the private key.
> >
> > -- Section 3.2 seems to allow for the possibility that the manufacture is in
> > the key security boundary.  What is the implication of that design?
> >
> > -- In what way is it anticipated that a UA would leak a key back to the
> > manufacturer?
>
> Unfortunately we have seen this in part in the Ukraine.  Russia has been
> getting information on Ukrainian drones used from their Chinese
> manufacturers.  The young men that were hobbyists have found that this
> need to be very careful on what they do, or they get personally targeted.
>
>
> So do you trust your manufacturer?  DoD is not allowed to use DJI
> systems.  Well, I have heard they use the physical platform and put in
> their own controller systems.  DJI makes some of the best UAs...

Thanks.  Consider adding a call out for this supply chain issue.

[Ballot comment]
Hi,

Thanks for this document.

This is somewhat outside my area, and this is a minor comment, but I have to confess that I found it slightly harder to read, I think because it is fairly acronym heavy, and I wonder whether expanding out some of the less frequently used acronyms may end up making the document slightly more readable and approachable.

Regards,
Rob

[Ballot comment]
Thanks, this is really interesting work.

I'm a little concerned at the shepherd writeup, which claims the bulk of the review is being done by the co-authors and the chairs.  Where's the rest of the working group?  And given the content of Section 4.2.2, has anyone from REGEXT looked at this?

Also, question #8 on the writeup was not answered, although it's possible it was folded into the answer for #7.  This should be clarified if possible as it's important to have properly recorded.

I can't parse the second paragraph of Section 3.1.

In Section 3.2, should "trustworthy" be capitalized as it was in the prior section?  Also in Section 3.2, the sixth paragraph (starting "Ed25519") seems to be a bit mangled.

The SHOULD in Section 4.1.2 needs expansion.  Why might an implementer legitimately choose not to do what this says?  Or does this really need to be a MUST?

[Ballot comment]
Thanks for this document. I have just a few comments.

1. This document repeatedly refers to "Observers", so capitalized as a proper noun. Presumably the capitalization implies that the authors think of Observers as a term of art, where Observers have some properties different from garden-variety lower-case observers, but the reader is left to guess what those properties might be.

Given the apparent importance of this distinction, it seems a definition should be supplied. Or, if there is in fact no important distinction between an Observer and an observer, lose the capitalization.

NITS and asides:

2. In §6, s/Broadcase/Broadcast/ (and does it really need to be capitalized?)

3. The crowdsourced RID idea is intriguing to be sure, but I'm a little baffled as to the motivation that would exist for people to opt in to such a scheme. I'm pretty sure that if my smartphone vendor popped up a dialog asking me to opt in to a UAV tracking scheme that doesn't benefit me in any meaningful way I'd click "no thanks" without a second thought. I'm curious whether there's some reason to think this will actually come to be a meaningfully widespread application, or if it's simply a neat idea that was fun to write down. (It's completely optional for you to answer this, it's only for my own curiosity.)

4. §8.1, s/wtih/with/

[Ballot comment]
Thanks for this document. I have just a few comments.

1. This document repeatedly refers to "Observers", so capitalized as a proper noun. Presumably the capitalization implies that the authors think of Observers as a term of art, where Observers have some properties different from garden-variety lower-case observers, but the reader is left to guess what those properties might be.

Given the apparent importance of this distinction, it seems a definition should be supplied. Or, if there is in fact no important distinction between an Observer and an observer, lose the capitalization.

NITS and asides:

2. In §6, s/Broadcase/Broadcast/ (and does it really need to be capitalized?)

3. The crowdsourced RID idea is intriguing to be sure, but I'm a little baffled as to the motivation that would exist for people to opt in to such a scheme. I'm pretty sure that if my smartphone vendor popped up a dialog asking me to opt in to a UAV tracking scheme I'd click "no thanks" without a second thought. I'm curious whether there's some reason to think this will actually come to be a meaningfully widespread application, or if it's simply a neat idea that was fun to write down. (It's completely optional for you to answer this, it's only for my own curiosity.)

4. §8.1, s/wtih/with/

[Ballot comment]
Thanks for this document. I have just a few comments.

1. This document repeatedly refers to "Observers", so capitalized as a proper noun. Presumably the capitalization implies that the authors think of Observers as a term of art, where Observers have some properties different from garden-variety lower-case observers, but the reader is left to guess what those properties might be.

Given the apparent importance of this distinction, it seems important that a definition be supplied. Or, if there is in fact no important distinction between an Observer and an observer, lose the capitalization.

NITS and asides:

2. In §6, s/Broadcase/Broadcast/ (and does it really need to be capitalized?)

3. The crowdsourced RID idea is intriguing to be sure, but I'm a little baffled as to the motivation that would exist for people to opt in to such a scheme. I'm pretty sure that if my smartphone vendor popped up a dialog asking me to opt in to a UAV tracking scheme I'd click "no thanks" without a second thought. I'm curious whether there's some reason to think this will actually come to be a meaningfully widespread application, or if it's simply a neat idea that was fun to write down. (It's completely optional for you to answer this, it's only for my own curiosity.)

4. §8.1, s/wtih/with/

[Ballot comment]
Thank you for this document - I am currently traveling and so was not able to do as thorough a review as I would like - apologies for the somewhat rushed tone.

Thank you for writing this; I find "architecture" and "use-case" documents to be really helpful to understand how things are supposed to work, to get a "lay of the land", how various components are supposed to fit together, etc -- so, thank you for writing this.

Roman's security review is, as usual, very thorough -- I did have a few additional security thoughts / questions which I'm suspecting may already have been addressed, but which I missed.

1: It seems like a relay attack would be fairly trivial with the broadcast model -- either just record previous broadcasts from a drone in a similar position and just replay it, or if there are multiple drones in a similar area (they often seem to flock together near "interesting" events), simply have a receiver which records a broadcast and then replays it. The document does say (Sec 5): "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." -- it seems like a note in the Security Considerations pointing back at this section would be good.

2: Based on how often keys are extracted even from devices which are "supposed" to be designed for security, I'm fairly sure that there will be trivial attacks for extracting private keys from small cheap drones and using them in "rogue" devices - the document does say "Leakage of the private key either from the UA or GCS to the component manufacturer is a valid concern and steps need to be in place to ensure safe keeping of the private key." but then "...  it is out of scope to deal wtih secure store for the private key." -- it feels to me like this is a fairly serious issue which is being hand-waved away with "it's out of scope..."

3: Nit: scope to deal wtih secure s/wtih/with/

4: "a revision to [F3411], currently in balloting (as of Oct 2021), adds type 4," -- presumably this has finished balloting - what was the outcome?

[Ballot comment]
Thanks for working on this documentation. Special thanks to Kyle Rose for the TSVART review.
Like Kyle I haven't picked up any TSV related issues. However, I have some comments which I believe will improve the document if addressed. See below --

- Section 1.1 : would be great to point to the 3GPP TR or TS for release 17 as well. An elaboration on how the UAS RID may be used as 3GPP CAA-level UAS RID would also be helpful here. Was this considered when the DRIP UAS RID designed so this is a direct match or the  3GPP needs some modification to adopt DRIP UAS RID.

Overall, I like the idea of describing regulation bodies and other SDOs in this section. However, due to various level of description and intentions, it feels this section is not clear about what it want to achieve.

- Section 1.4: Looking at the description it feels like the only reason figure 4 has two UASs is the V2V communication. It became a bit confusing for me to understand if there is any possibility of GCS in UAS1 sending command to UA in UAS2 or not. Or whether  GCS in UAS1 and UAS2 is representing same entity administrated by same  authority/controller. I went through the description with this confusion in mind and could not resolve it, may be I have missed it somehow. It will be great if this clarified in the description more vividly.

- Section 3: where is HHIT defined in  RFC 7401? or what is the purpose of referring to RFC 7401 in the beginning of the section?

- Where is the description of how to self-generate a DRIP Identifier? one possible answer could be  " Read this in section x of RFC xxx or in this document or read carefully here []", meaning I have surely missed something. But then I know where to read and how to generate the DRIP identifier.

[Ballot discuss]
I applaud the deliberate consideration being provided for security matters.  My concern is about the symmetry between the security claims being made and the level of detail being provided in the mechanisms.

** Definition of a HHIT.

Various security claims are made about the HHIT down to specifying cryptographic algorithms and resistance to attacks.  However, this document provides inconsistent and vague definitions for a HHIT.  Surprisingly, it doesn’t cite draft-ietf-drip-rid.  It is difficult to assess these claims given the lack of information on a HHIT.  I would have expected this architecture document to make high-level claims and leave the details to a standards-track document.  A few places to source the HHTI definitions:

-- Section 3 says ‘… explains the use of Hierarchical Host Identity Tags (HHITs) [RFC7401] …”, RFC7401 defines HIT but not HHIT.

-- Section 3 also says ‘Self-asserting in this usage means that, given the Host Identity (HI), the HHIT ORCHID construction and a signature of the registry on the HHIT …”, but as doesn’t explain that connection

-- A few places in the text suggest that HHIT, as the name suggest are hierarchical, and this hierarchy is key to ensuring security properties (e.g., Section 3.2. “The cryptographically-bound addition of the Hierarchy …”; Section 3.4 says “To provide this, each HHIT embeds plaintext information designating the hierarchy within which it is registered and a cryptographic hash of that information concatenated with the entity's public key, etc. provides examples of computing a HHIT by encoding a HHIT”; and Section 4.2.1. “The HHIT hierarchy  can provide the needed scalability and management structure”).  Where is that hierarchy explained in this document?

This is up to the WG, but IMO, the discussion about cryptographic properties would be better suited in the document providing the specifics (draft-ietf-drip-rid) and the top-level security properties cited by reference here. 

** Verification process of claims/assertions.
-- Section 3.2.  Each Observer device SHOULD be
  provisioned either with public keys of the DRIP identifier root
  registries or certificates for subordinate registries.

-- Section 3.2 ... prepopulating small caches on Observer devices with Registry public
  keys and a chain of Attestations or Certificates (tracing a path
  through the Registry tree). 

Where is the behavior ensuring a trust relationship between registries described?  These are no chains certificates in the X.509 sense.

Where is the link between the “DRIP identifier root registries” and the verification of UA traffic?  Is that draft-ietf-drip-auth?

-- Section 5.
  Optimization of different DRIP Authentication Messages  allows an
  Observer, without Internet connection (offline) or with (online), to
  be able to validate a UAS DRIP ID in real-time.  First is the sending
  of Broadcast Attestations (over DRIP Link Authentication Messages)

  [I-D.ietf-drip-auth]  containing the relevant registration of the UA's
  DRIP ID in the claimed Registry.  Next is sending DRIP Wrapper
  Authentication Messages that sign over both static (e.g., above
  registration) and dynamically changing data (such as UA location
  data).  Combining these two sets of information, an Observer can
  piece together a chain of trust and real-time evidence to make their
  determination of the UA's claims.

How does the use of specific message work if the Observer is offline?

As noted above, this is up to the WG, but IMO there is a level of detail here that distracts from the discussion of the architecture.  It would be best covered by reference.

** Section 9
  Broadcast RID messages can contain Personally Identifiable
  Information (PII).  A viable architecture for PII protection would be
  symmetric encryption of the PII using a session key known to the UAS
  and its USS ...

Per “A viable architecture ...”, I’m not sure how to read all the text after the first sentence given this phrasing.  Is the rest of the text the official “DRIP architecture” or an example? I’m assuming the former and believe it would benefit from its own set of security considerations.  A few initial questions:

-- Are there channel security requirements between the decryption oracle/key escrow or distribution server/USS and the Observer?

-- Is there a strong authentication/authorization model to gain services from the USS?

-- How does this oracle or key server approach work in the case an offline observer?

[Ballot comment]
Thank you to Valery Smyslov for the SECDIR review.

** Section 1.2.1.  This section discusses a “range up to approximately 1 km”, notes “smartphones” as endpoints, and cites Bluetooth and WiFi as the wireless technologies.  Even with line of sight, these seem like very long ranges without specialized antennas (i.e., not on a smartphone).

** Section 2.1

  DRIP could address standardization of
  secure protocols between the UA and GCS (over direct wireless and
  Internet connection), between the UAS and the Net-RID SP, and/or
  between the Net-RID DP and Observer devices.

Can this text be clarified?  Does this hypothetical make sense in an archival document?

** Figure 4.  This diagram introduces a lot of complexity, but then doesn’t reference architectural elements later by these names – GPOD and PSOD; and these use cases too -- V2I, VV.  Are those additional labels needed? 

** Section 3.1

  … a revision to [F3411], currently in balloting
  (as of Oct 2021) , adds type 4, Specific Session ID, to be
  standardized by IETF and other standards development organizations
  (SDOs) as extensions to ASTM UAS RID, consumes one of those bytes to
  index the sub-type, leaving only 19 for the identifier (see DRIP
  Requirement ID-1).

Has anything of note happened in the last 9 months per the type 4 balloting activities in [F3411]?
Section 3.2.  Consider:

OLD
By construction, the HIT is statistically unique through the
  cryptographic hash feature of second-preimage resistance

NEW
By construction, the HIT is statistically unique through the mandatory use of cryptographic hash functions with second-preimage resistance.

** Section 3.2

  A self-attestation of a HHIT used as a UAS ID can be done in as
  little as 84 bytes when Ed25519 [RFC8032] is used, by avoiding an
  explicit encoding technology like ASN.1 or Concise Binary Object
  Representation (CBOR [RFC8949]).  This attestation consists of only
  the HHIT, a timestamp, and the EdDSA signature on them

It would be clearer to explain how to compute these 84 bytes (64-bytes for the Ed25519 signature + 16-bytes for the HHIT + 4 byte for the timestamp = 84 bytes).

** Section 3.2
  Ed25519 [RFC8032] is used as the HHIT signing algorithm as [RFC9153]
  GEN-1 and ID-5 can best be met by restricting the HI to 32 bytes.  A
  larger public key would rule out the offline attestation feature that
  fits within the 200-byte Authentication Message maximum length.
  Other algorithms that meet this 32 byte constraint can be added as
  deemed needed.

-- The requirement for using Ed25519 doesn’t come from [RFC9153]

-- If Ed25519 is MTI, it should be stated here or instead cite the standards track document from which it comes.  It feels a bit odd to me to have an informational document specifying the required crypto algorithm when there are more detailed proposed standard document with the required interoperability details.

** Section 3.3

  Given the size
  constraints imposed by the Bluetooth 4 broadcast media, the UAS ID
  itself needs to be a non-spoofable inquiry input into the lookup.

Shouldn’t the UAS ID be non-spoofable regardless of the Bluetooth size constraints.

** Section 3.4.
  Although hash collisions may occur, the registrar can detect them and
  reject registration requests rather than issue credentials  ...

This is the first reference to Registrar issuing credentials.  What are those?

** Section 4.
  DRIP registries [I-D.ietf-drip-registries] hold both public and
  private UAS information (See PRIV-1 in [RFC9153]) resulting from the
  DRIP identifier registration process. 

What is the link to PRIV-1?

** Section 4.1.1.  What role does the HDA and RAA play relative to the reference architecture in Figure 4.

** Section 4.1.2.  What is a “standardized HHIT FQDN” vs. a “HHIT”?

** Section 4.1.2. 

A DRIP identifier SHOULD be registered as an Internet domain name (at
  an arbitrary level in the hierarchy, e.g., in .ip6.arpa). 
(Since this is a “SHOULD” level requirement without citation)  What is does it mean to register at an arbitrary level in the hierarchy beyond just registering?

** Section 4.2.  What information is being put into the Private Information Registry?

** Section 4.2.2 and 4.2.3.  I don’t understand the contrast being proposed here.  In Section 4.2.2, there is a feature rich protocol like EPP being suggested which handles not only query capabilities but a add/delete/update support.  Section 4.2.3 seems to be suggested query only capabilities.  If one uses, WebFinger, is there an alternative mechanism expected to register this information?  Could I use EPP + WebFinger?

** Section 5. 

  For that it MUST be
  registered (under DRIP Registries)

In both the public and private registry?

** Section 5. 

  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.

-- Editorial.  In the spirit of inclusive language consider an alternative to “sanity-checked”.

-- What additional validation is the Observer doing?

-- Does it “prove” or increase the likelihood of the UAS does in fact have the identity?  The current text suggests that it is circumstantial.

** Section 5.
  From received
  Broadcast RID messages and information that can be looked up using
  the received UAS ID in online registries or local caches, it is
  possible to establish levels of trust in the asserted information and
  the Operator.

What are these levels of trust?  As in the previous comment, is this a increased confidence in the information?

** Section 6.*.  The CS-RID doesn’t appear to land on the reference architecture in Figure 4.

** Section 7.

-- What does it mean to “initiate a cryptographic handshake … assuming mutual authentication … IPsec tunnel” vs. just initiating a IPsec tunnel?

-- What is the planned approach for provision the key materials for this communication?

-- Is it being suggested that the public/private key pair be used for IPsec too?

-- There is no suggestion of reusing the HIT public/private key for IPsec?

** Section 8.

Compromise of a registry private key could do widespread harm. 

Understood.  Thanks for saying so.  Could you please add more text to explain why there would be widespread harm.  There is almost no detail in this document about what is in that registry.

** Section 8.

  Key
  revocation procedures are as yet to be determined. 

-- Revocation of what keys?  The key-pair used for the HI and to generate the HHIT?

-- What’s the plan for static HI/HHITs set by the manufacture as described in Section 3.2

** Section 8.1

  Leakage of the private
  key either from the UA or GCS to the component manufacturer is a
  valid concern and steps need to be in place to ensure safe keeping of
  the private key.

-- Section 3.2 seems to allow for the possibility that the manufacture is in the key security boundary.  What is the implication of that design?

-- In what way is it anticipated that a UA would leak a key back to the manufacturer?

** Section 8.1
  Since it is possible for the UAS RID sender of a small harmless UA
  (or the entire UA) to be carried by a larger dangerous UA as a "false
  flag", it is out of scope to deal wtih secure store for the private
  key.

I don’t follow why a piggy-backing done precludes the need for dealing with the secure storage of private keys.  I would understand that DRIP is making it out of scope as it is an end-point security issue.  However, declaring secure storage of keys as out of scope is inconsistent with draft-ietf-drip-rid-29 which says in Section 4.1, that “The private key for the HI SHOULD be held in a cryptographically secure component.”

** Section 8.2
  UAs and Broadcast Remote ID communications
  are so constrained that current post quantum computing cryptography
  is not applicable. 

  Plus since a UA may use a unique HHIT for each
  operation, the attack window could be limited to the duration of the
  operation.

Since we are talking about a non-existent quantum computer, I’m not sure why this time bounding excludes consideration for this reason.  There would be no confusion or complication in the RID ecosystem if an attacker could reuse HHIT in a volume of airspace?

Editorial
-- Section 1.1.  Editorial.  s/The rule clearly states/The rule states/

-- Section 1.2  Editorial. s/two types UAS Remote ID/two types of UAS Remote ID/

-- Figure 2.  Editorial.  Consider number the steps described in the previous paragraph and then providing these corresponding numeric labels in the diagram.

-- Section 5.  Typo.

OLD
A sender's identity can not be approved
NEW
A sender's identity can not be proved

[Ballot comment]
# Internet AD comments for {draft-ietf-drip-arch-24}
CC @ekline

## Nits

### Appendix B

* Consider: "manned aviation" -> "crewed aviation", or some similar construct

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-drip-arch-22, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-04-06):

From: The IESG
To: IETF-Announce
CC: daniel.migault@ericsson.com, draft-ietf-drip-arch@ietf.org, drip-chairs@ietf.org, evyncke@cisco.com, tm-rid@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Drone Remote Identification Protocol (DRIP) Architecture) to Informational RFC


The IESG has received a request from the Drone Remote ID Protocol WG (drip)
to consider the following document: - 'Drone Remote Identification Protocol
(DRIP) Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-04-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes an architecture for protocols and services to
  support Unmanned Aircraft System (UAS) Remote Identification (RID)
  and tracking, plus UAS RID-related communications.  This architecture
  adheres to the requirements listed in the DRIP Requirements document
  (RFC9153).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-drip-arch/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The RFC type informational which is appropriated for an architecture document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes an architecture for protocols and services to
  support Unmanned Aircraft System Remote Identification and tracking
  (UAS RID), plus RID-related communications.  This architecture
  adheres to the requirements listed in the DRIP Requirements document.


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

no

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are at least two ongoing implementations:
* https://bitbucket.org/openhip/openhip/branches/
* one implementation AX Enterprize is involved in.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel Migault is the  Document Shepherd Éric Vyncke is the Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was mostly reviewed by the chairs and the co-authors. It would have been appreciated to have more reviews of course, but given the number of rounds, I believe the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

no.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

no.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

NA

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

We received the confirmation for version 19 from Adam, Shuai, Andrei,  Stu and (Jim that I do not see as a co-author ;-) ), so far we are missing Bob's disclosure but he made one disclosure on November 19.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

A set of people is driving the work but none has been silenced. The group contains people coming from different horizons.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

no

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


idnits 2.17.00 (12 Aug 2021)

/tmp/idnits14160/draft-ietf-drip-arch-20.txt:
-(10): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == There are 3 instances of lines with non-ascii characters in the document.


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 363 has weird spacing: '... Public  o---...'


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 0 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

yes - note for the AD if that seems to be an issue, I suspect this can be solved at the submission time.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No - though it might be good to publish req/arch together. Eventually rid might be mentioned but I do not think we need to wait for rid to be ready.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

na

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

no

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There is no IANA section.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

na

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

datatracker nits

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The RFC type informational which is appropriated for an architecture document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes an architecture for protocols and services to
  support Unmanned Aircraft System Remote Identification and tracking
  (UAS RID), plus RID-related communications.  This architecture
  adheres to the requirements listed in the DRIP Requirements document.


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

no

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are at least two ongoing implementations:
* https://bitbucket.org/openhip/openhip/branches/
* one implementation AX Enterprize is involved in.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel Migault is the  Document Shepherd Éric Vyncke is the Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was mostly reviewed by the chairs and the co-authors. It would have been appreciated to have more reviews of course, but given the number of rounds, I believe the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

no.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

no.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

NA

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

We received the confirmation for version 19 from Adam, Shuai, Andrei,  Stu and (Jim that I do not see as a co-author ;-) ), so far we are missing Bob's disclosure but he made one disclosure on November 19.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

A set of people is driving the work but none has been silenced. The group contains people coming from different horizons.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

no

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


idnits 2.17.00 (12 Aug 2021)

/tmp/idnits14160/draft-ietf-drip-arch-20.txt:
-(10): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == There are 3 instances of lines with non-ascii characters in the document.


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 363 has weird spacing: '... Public  o---...'


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 0 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

yes - note for the AD if that seems to be an issue, I suspect this can be solved at the submission time.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No - though it might be good to publish req/arch together. Eventually rid might be mentioned but I do not think we need to wait for rid to be ready.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

na

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

no

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There is no IANA section.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

na

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

datatracker nits

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The RFC type informational which is appropriated for an architecture document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes an architecture for protocols and services to
  support Unmanned Aircraft System Remote Identification and tracking
  (UAS RID), plus RID-related communications.  This architecture
  adheres to the requirements listed in the DRIP Requirements document.


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

no

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

XXXX

These are the known implementations

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel Migault is the  Document Shepherd Éric Vyncke is the Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was mostly reviewed by the chairs and the co-authors. It would have been appreciated to have more reviews of course, but given the number of rounds, I believe the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

no.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

no.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

NA

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

We received the confirmation for version 19 from Adam, Shuai, Andrei,  (Jim that I do not see as a co-author ;-) ), so far we are missing Stu and Bob.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

A set of people is driving the work but none has been silenced. The group contains people coming from different horizons.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

no

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


idnits 2.17.00 (12 Aug 2021)

/tmp/idnits14160/draft-ietf-drip-arch-20.txt:
-(10): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == There are 3 instances of lines with non-ascii characters in the document.


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 363 has weird spacing: '... Public  o---...'


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

    No issues found here.

    Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 0 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

yes - note for the AD if that seems to be an issue, I suspect this can be solved at the submission time.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No - though it might be good to publish req/arch together. Eventually rid might be mentioned but I do not think we need to wait for rid to be ready.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

na

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

no

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There is no IANA section.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

na

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

datatracker nits

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

NA

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The RFC type informational which is appropriated for an architecture document.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes an architecture for protocols and services to
  support Unmanned Aircraft System Remote Identification and tracking
  (UAS RID), plus RID-related communications.  This architecture
  adheres to the requirements listed in the DRIP Requirements document.


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

no

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

XXXX

These are the known implementations

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel Migault is the  Document Shepherd Éric Vyncke is the Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was mostly reviewed by the chairs and the co-authors. It would have been appreciated to have more reviews of course, but given the number of rounds, I believe the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

no.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

no.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

NA

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

XXX

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

A set of people is driving the work but none has been silenced. The group contains people coming from different horizons.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

no

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

XXX

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

yes - note for the AD if that seems to be an issue, I suspect this can be solved at the submission time.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No - though it might be good to publish req/arch together. Eventually rid might be mentioned but I do not think we need to wait for rid to be ready.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

na

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

no

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There is no IANA section.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

na

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

datatracker nits

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

NA