Skip to main content

DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID
draft-ietf-drip-auth-49

Revision differences

Document history

Date Rev. By Action
2024-02-22
49 (System) IANA Action state changed to In Progress
2024-02-22
49 (System) RFC Editor state changed to EDIT
2024-02-22
49 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-02-22
49 (System) Announcement was received by RFC Editor
2024-02-22
49 (System) Removed all action holders (IESG state changed)
2024-02-22
49 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-02-22
49 Cindy Morgan IESG has approved the document
2024-02-22
49 Cindy Morgan Closed "Approve" ballot
2024-02-22
49 Cindy Morgan Ballot approval text was generated
2024-02-22
49 Éric Vyncke The latest revision (-49) and email discussions have addressed all remaining (non)-blocking issues.
2024-02-22
49 Éric Vyncke IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2024-02-21
49 Adam Wiethuechter New version available: draft-ietf-drip-auth-49.txt
2024-02-21
49 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2024-02-21
49 Adam Wiethuechter Uploaded new revision
2024-02-16
48 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-02-16
48 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-02-16
48 Adam Wiethuechter New version available: draft-ietf-drip-auth-48.txt
2024-02-16
48 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2024-02-16
48 Adam Wiethuechter Uploaded new revision
2024-02-15
47 (System) Changed action holders to Adam Wiethuechter, Stuart Card, Robert Moskowitz (IESG state changed)
2024-02-15
47 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation - Defer
2024-02-14
47 Murray Kucherawy
[Ballot comment]
Thanks for clarifying what Section 8.1 is seeking to accomplish.  Just to verify: From the IETF perspective, this is essentially a Standards Action …
[Ballot comment]
Thanks for clarifying what Section 8.1 is seeking to accomplish.  Just to verify: From the IETF perspective, this is essentially a Standards Action registry where ASTM's registrar acts as a Designated Expert, correct?

===

Forwarding some comments from Orie Steele, incoming ART AD:

There is no link available for "F3411-22a", but I found https://www.astm.org/f3411-22a.html

Not sure how paid specifications should like this or ISO should be referenced.

> An Observer SHOULD query DNS for the UA's HI.

Why not MUST ?

> An Observer SHOULD query DNS for the DIME's HI (e.g., Section 5 of [drip-registries]), when able.

Again, why not MUST? Seems to be reducing the utility of revocation.

> When correlation of these different data streams does not match in acceptable thresholds, the data SHOULD be rejected as if the signature failed to validate. Acceptable thresholds limits and what happens after such a rejection are out of scope for this document.

Why not MUST?

...
Its not clear exactly which FEC scheme is used here, a citation for the FEC would be nice.
2024-02-14
47 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss
2024-02-14
47 Paul Wouters
[Ballot comment]
I'm a little puzzled why this is an IETF document. It feels more like a [F3411] extension ?

      Therefore specification …
[Ballot comment]
I'm a little puzzled why this is an IETF document. It feels more like a [F3411] extension ?

      Therefore specification of particular DNS security options,
        transports, etc. is outside the scope of this document

I understand transports being out of scope but not DNS security options? If pulling key material from DNS, I think one should call out DNSSEC, or even mandate it.

Regarding 3.1.2.2. UA Signed Evidence

I don't understand why unpredictable means evidence? If I observe someone elses
unpredictable sends, can't I just retransmit those? Unless the signature contains
"live data", I can't tell it is a not a replay. I understand the two timestamps
and location/vector data are supposed to limit replays, but if those parts are
successful for that, I don't understand why an unpredictable component is still needed.
Also, what is unpredictable? I think a KDF with initial seed of "Paul is crazy" produces
a seemingly unpredictable stream, but to those knowing the seed, it is totally predictable.

        signing data that is guaranteed to be unique, unpredictable and easily cross checked

How does an IoT device do this? These famously do not have strong random sources? If they do,
would they need to use a construct similar to GCM where part is a counter and part is pseudorandom
to ensure the uniqueness without needing to store all previous "unpredictable" (aka random/unique) data?

        If an attacker (who is smart and spoofs more than just the UAS
        ID/data payloads) willingly replays a DRIP Link message, they
        have in principle actually helped by ensuring the DRIP Link is
        sent more frequently and be received by potential Observers.

But it would have spoofed its time and location of another device? I would
not all that "actually helping" ? This paragraph confuses me.

Why are there colour codes? Is that an aviation thing?
2024-02-14
47 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2024-02-14
47 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-02-14
47 Roman Danyliw
[Ballot comment]
(This is a revised ballot initially entered on -46 in preparation for the Feb-01-2024 telechat)

Thank you to Rich Salz for the early …
[Ballot comment]
(This is a revised ballot initially entered on -46 in preparation for the Feb-01-2024 telechat)

Thank you to Rich Salz for the early SECDIR review.

I lacked access to [F3411] which is a critical normative reference for this document.  In particular, I am unable to evaluate Section 4.3.2. 

Thank you for addressing my DISCUSS feedback on -46 and most of my COMMENTs.

** Section 4.2. 
  A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement
  chain MUST be included in each DRIP Manifest Section 4.4.

[per -46] It would have been helpful to provide more prose on computing and using a “Broadcast Endorsement chain”. 

[per -47] Thanks for the explanation on endorsement chains being related to content in [drip-registries].  See below.

** [per -46] Section 11.1.  I believe that [drip-registries] needs to be a normative reference given the importance of this reference for Section 4.1 and 9.2
2024-02-14
47 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2024-02-11
47 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-02-11
47 Adam Wiethuechter New version available: draft-ietf-drip-auth-47.txt
2024-02-11
47 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2024-02-11
47 Adam Wiethuechter Uploaded new revision
2024-02-01
46 Paul Wouters Telechat date has been changed to 2024-02-15 from 2024-02-01
2024-02-01
46 Paul Wouters IESG state changed to IESG Evaluation - Defer from IESG Evaluation
2024-02-01
46 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2024-01-31
46 Murray Kucherawy
[Ballot comment]
Forwarding some comments from Orie Steele, incoming ART AD:

There is no link available for "F3411-22a", but I found https://www.astm.org/f3411-22a.html

Not sure how …
[Ballot comment]
Forwarding some comments from Orie Steele, incoming ART AD:

There is no link available for "F3411-22a", but I found https://www.astm.org/f3411-22a.html

Not sure how paid specifications should like this or ISO should be referenced.

> An Observer SHOULD query DNS for the UA's HI.

Why not MUST ?

> An Observer SHOULD query DNS for the DIME's HI (e.g., Section 5 of [drip-registries]), when able.

Again, why not MUST? Seems to be reducing the utility of revocation.

> When correlation of these different data streams does not match in acceptable thresholds, the data SHOULD be rejected as if the signature failed to validate. Acceptable thresholds limits and what happens after such a rejection are out of scope for this document.

Why not MUST?

...
Its not clear exactly which FEC scheme is used here, a citation for the FEC would be nice.
2024-01-31
46 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2024-01-31
46 Murray Kucherawy
[Ballot discuss]
Section 8.1 declares two registries.  The first appears to describe a registration procedure that reduces to Standards Action (RFC 8126, Section …
[Ballot discuss]
Section 8.1 declares two registries.  The first appears to describe a registration procedure that reduces to Standards Action (RFC 8126, Section 4.9) with an Expert Review component to it.  It also seems like an I-D seeking Proposed Standard status is enough to qualify, even if that document is never actually published as an RFC.  Is that intended, or do we need to say abandoned I-Ds result in de-registration?  Or is there a provisional/permanent component to this?
2024-01-31
46 Murray Kucherawy [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy
2024-01-31
46 Di Ma Request for Telechat review by DNSDIR Completed: Ready with Nits. Reviewer: Di Ma. Sent review to list. Submission of review completed at an earlier date.
2024-01-31
46 Di Ma Request for Telechat review by DNSDIR Completed: Ready with Nits. Reviewer: Di Ma.
2024-01-31
46 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-01-31
46 Martin Duke
[Ballot comment]
Thanks to authors for quickly responding to my DISCUSS with a brief summary of the rate limitations of the protocol. These messages are …
[Ballot comment]
Thanks to authors for quickly responding to my DISCUSS with a brief summary of the rate limitations of the protocol. These messages are sent at a set rate and are not recovered if lost, so there is no transport issue.

Thanks to Gorry for the TSVART review.
2024-01-31
46 Martin Duke [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss
2024-01-31
46 Martin Duke
[Ballot discuss]
I'm not able to access [F3411] and therefore am unable to assess if this design creates excessive load on the network.

In particular, …
[Ballot discuss]
I'm not able to access [F3411] and therefore am unable to assess if this design creates excessive load on the network.

In particular, I'm somewhat concerned about two pages being lost, overpowering the FEC and resulting in loss of the entire authentication message (and the other message types it is wrapping!) and retransmission of the whole suite, depending on how sophisticated the loss recovery is. In some edge cases, this might never converge.

No doubt the authors can provide a high-level view of how congestion control and loss recovery work?
2024-01-31
46 Martin Duke [Ballot comment]
Thanks to Gorry for the TSVART review.
2024-01-31
46 Martin Duke [Ballot Position Update] New position, Discuss, has been recorded for Martin Duke
2024-01-31
46 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2024-01-30
46 Roman Danyliw
[Ballot discuss]
** Section 4.1.  I missed something very basic. Where is the signature algorithm that computes the value of “UA Signature” defined?

** Section …
[Ballot discuss]
** Section 4.1.  I missed something very basic. Where is the signature algorithm that computes the value of “UA Signature” defined?

** Section 4.4.

(a)  An Observer who has been listening for any length of time MUST hash
  received messages and cross-check them against the Manifest hashes.

(b) A receiver SHOULD use the Manifest to verify each ASTM Message hashed
  therein that it has previously received.

-- Per (a), Can “any length of time” please be qualified in some way since there is normative behavior specified?

-- These appear to be similar statements, but one is stronger than the other.  Doesn’t (a) require a check, but (b) is only strongly recommending it?  They should be consistent.

** Section 4.4.3
  For OGAs other than "5" [RFC9374], use the construct appropriate for
  the associated hash.  For example, for "2" which is ECDSA/SHA-384:

My understanding is that cSHAKE128 must be used as the hash for manifest hashes.  However, this text is introducing the possibility of other OGAs and associate hash algorithms.  When would they be used in a DRIP manifest and how would one know they are in use instead of cSHAKE128?

** Section 4.5.  What should an observer do if such a frame is seen in the wild?

** Section 6.3

  4.  MUST: send any other DRIP Authentication Format (RECOMMENDED:
      DRIP Manifest (Section 4.4) or DRIP Wrapper (Section 4.3)) where
      the UA is dynamically signing data that is guaranteed to be
      unique, unpredictable and easily cross checked by the receiving
      device (satisfying ID-5, GEN-1 and GEN-2); at least once per 5
      seconds

Thank you for the clarity of the UA behavior provided in this section.  This bullet needs to be refined. 

It starts by saying “any other DRIP Authentication Formats”, which I took to mean all those in Table 2 other than Link (to include future ones registered in the corresponding IANA registry) need to do something (be sent once per 5/sec).  However, there is a “RECOMMENDED” parenthetical which is a smaller number of messages.  Which is it, all non-Link messages, or only those in the recommended list?

** Appendix A.  If this appendix is informative, normative language should not be used here.
2024-01-30
46 Roman Danyliw
[Ballot comment]
Thank you to Rich Salz for the early SECDIR review.

I lacked access to [F3411] which is a critical normative reference for this …
[Ballot comment]
Thank you to Rich Salz for the early SECDIR review.

I lacked access to [F3411] which is a critical normative reference for this document.  In particular, I am unable to evaluate Section 4.3.2.  Some of the above DISCUSS may be related to this lack of access. 

** Editorial.  “Sanity check” is used throughout the document to describe some validation activity.  Please consider replacing this phrase with a more precise expression.

** Section 3.1.1.  Editorial.
  An Observer SHOULD query DNS for the UA's HI.  If not available it
  may have been revoked.  Note that accurate revocation status is a
  DIME inquiry; DNS non-response is a hint that a DET is expired or
  revoked

-- My initial read of the “If not available text” text was that if “DNS was not available”, not that the HIT wasn’t found in DNS.

-- what’s a “DIME inquiry”?  what’s makes a revocation status “accurate”; are there other kinds?

** Section 3.2.1. 
      Authentication Type (4 bits) and Page Number (4 bits)

Which one is first?  Does this come from [F3411]?

** Section 3.2.2.
  Additional Data: (255 octets max)

Isn’t there more nuance to this than up to “255 octets max”.  Doesn’t the size of the Signature determine how much Additional data can be present?  Something like (368 – sizeof(Signature) – 7) <= Sizeof(Additional Data) <= 255 octets.

** Section 3.2.4.2
  Under Broadcast
  RID, the Extended Transport that can hold the least amount of
  authentication data is Bluetooth 5.x at 9 pages.

Didn’t the section prior indicate that Bluetooth 4.x was the most constrained?

** Section 4.2. 
  A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement
  chain MUST be included in each DRIP Manifest Section 4.4.

It would have been helpful to provide more prose on computing and using a “Broadcast Endorsement chain”.

** Section 4.3.1.  Given that Figure 6 must be implemented but it is described in pseudo-code, further clarity is needed.  Specifically, this algorithm appears to be a validation check.  There appears to be two “return” statement indicating failure.  I’m assuming that the two comments (“//”) are to be read as validation success.  If that’s accurate, please say so.

** Section 4.4
  Judicious use of a Manifest enables an entire Broadcast RID message
  stream to be strongly authenticated with less than 100% overhead
  relative to a completely unauthenticated message stream

Recommend pointing to Section 6.3 to quantify what "judicious use" means.

** Section 4.4.3

  For the first built Manifest this value
  is filled with a random nonce.

How does the observer get this nonce to validate the observed message?

** Section 6.4

  UAS operation may impact the frequency of sending DRIP Authentication
  messages.  When a UA dwells at an approximate location, and the
  channel is heavily used by other devices, less frequent message
  authentication may be effective (to minimize RF packet collisions)
  for an Observer.  Contrast this with a UA transiting an area, where
  authenticated messages SHOULD be sufficiently frequent for an
  Observer to have a high probability of receiving an adequate number
  for validation during the transit.

Would these “less frequent” or “sufficiently frequent” broadcasts qualitatively described above alter the quantitate, mandatory transmission rates in Section 6.3?

** Section 11.1.  Can [F3411] provide more identifying information.  For example, can the name of the SDO be provided.

** Section 11.1.  I believe that [drip-registries] needs to be a normative reference given the importance of this reference for Section 4.1 and 9.2
2024-01-30
46 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2024-01-30
46 Warren Kumari
[Ballot comment]
Firstly, thank you for this document.

Also, much thanks to Di Ma for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-drip-auth-43-dnsdir-lc-ma-2024-01-08/), and for the followup …
[Ballot comment]
Firstly, thank you for this document.

Also, much thanks to Di Ma for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-drip-auth-43-dnsdir-lc-ma-2024-01-08/), and for the followup discussion.

I went and found the added text:
"Since DRIP depends on DNS for some
  of its functions, DRIP usage of DNS needs to be protected in line
  with best security practices.  Many participating nodes will have
  limited local processing power and/or poor, low bandwidth QoS paths.
  Appropriate and feasible security techniques will be highly UAS and
  Observer situation dependent.  Therefore specification of particular
  DNS security options, transports, etc. is outside the scope of this
  document."

I think that this is reasonable for the in-line stuff, but (Like Erik), I think that it would also make sense to explicitly call out DNSSEC.
2024-01-30
46 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2024-01-30
46 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-01-30
46 Zaheduzzaman Sarker [Ballot comment]
Thanks for working on this specification. Thanks to Gorry Fairhurst for the TSVART review which certainly has improved the document.
2024-01-30
46 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-01-29
46 Carlos Jesús Bernardos Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Jesús Bernardos. Sent review to list.
2024-01-29
46 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2024-01-26
46 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-01-26
46 Gunter Van de Velde Request closed, assignment withdrawn: Carlos Martínez Early OPSDIR review
2024-01-26
46 Gunter Van de Velde Closed request for Early review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2024-01-26
46 Tim Chown Assignment of request for Telechat review by INTDIR to Tim Chown was rejected
2024-01-25
46 Adam Wiethuechter New version available: draft-ietf-drip-auth-46.txt
2024-01-25
46 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2024-01-25
46 Adam Wiethuechter Uploaded new revision
2024-01-22
45 Behcet Sarikaya Request for Telechat review by IOTDIR Completed: Ready with Issues. Reviewer: Behcet Sarikaya. Sent review to list.
2024-01-22
45 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Carlos Jesús Bernardos
2024-01-22
45 Tim Chown Assignment of request for Telechat review by INTDIR to Tim Chown was rejected
2024-01-21
45 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-drip-auth-45
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments …
[Ballot comment]
# Internet AD comments for draft-ietf-drip-auth-45
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### general

* I think it's reasonable to remind the casual reader that DNSSEC is a
  recommended best practice, when it comes to an Observer querying DNS
  for various bits of information.  RFC9364#section-1.1 (other references
  are probably better)
2024-01-21
45 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-01-20
45 Bernie Volz Request for Telechat review by INTDIR is assigned to Tim Chown
2024-01-19
45 Adam Wiethuechter New version available: draft-ietf-drip-auth-45.txt
2024-01-19
45 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2024-01-19
45 Adam Wiethuechter Uploaded new revision
2024-01-18
44 Ines Robles Request for Telechat review by IOTDIR is assigned to Behcet Sarikaya
2024-01-18
44 Éric Vyncke Requested Telechat review by IOTDIR
2024-01-18
44 Éric Vyncke Requested Telechat review by INTDIR
2024-01-17
44 Jim Reid Request for Telechat review by DNSDIR is assigned to Di Ma
2024-01-17
44 Éric Vyncke Placed on agenda for telechat - 2024-02-01
2024-01-17
44 Éric Vyncke Ballot has been issued
2024-01-17
44 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2024-01-17
44 Éric Vyncke Created "Approve" ballot
2024-01-17
44 Éric Vyncke IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2024-01-17
44 Éric Vyncke Ballot writeup was changed
2024-01-17
44 Éric Vyncke Ballot writeup was changed
2024-01-16
44 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-01-16
44 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-01-16
44 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2024-01-16
44 Adam Wiethuechter New version available: draft-ietf-drip-auth-44.txt
2024-01-16
44 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2024-01-16
44 Adam Wiethuechter Uploaded new revision
2024-01-10
43 Éric Vyncke Waiting for a revised I-D addressing DNSDIR/IANA/TSVART last call comments (and noted that the authors are working with reviewers)
2024-01-10
43 (System) Changed action holders to Adam Wiethuechter, Stuart Card, Robert Moskowitz (IESG state changed)
2024-01-10
43 Éric Vyncke IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2024-01-09
43 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-01-08
43 Di Ma Request for Last Call review by DNSDIR Completed: Almost Ready. Reviewer: Di Ma. Sent review to list.
2024-01-05
43 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2024-01-05
43 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-drip-auth-43. If any part of this review is inaccurate, please let us know.

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

IANA has completed its review of draft-ietf-drip-auth-43. If any part of this review is inaccurate, please let us know.

IANA has several questions about the first action requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, a new registry is to be created called the DRIP SAM Type registry. The new registry will be located in the Drone Remote ID Protocol registry group located at:

https://www.iana.org/assignments/drip/

IANA Question --> IANA notes that the current draft says, "This registry is a mirror for SAM Types containing the subset of allocations used by DRIP Authentication Messages. Future additions MUST be done through ICAO using their process. The following values have been allocated by ICAO to the IETF and are defined here: . . ." How is IANA to be notified, in the future, that ICAO has allocated a new DRIP SAM Type to the IETF? Will there be an RFC for these future values, or is another mechanism going to be in place? IANA requests that a future version of this draft provide specific guidance on the mechanism for future registrations. In addition, what should the reference be for the initial four registration provided in section 8.1 of the current draft?

IANA understands that there are four initial registrations in the new registry as follows:

SAM Type Name Description Reference
---------+------+-----------+------------
0x01 DRIP Link Format to hold Broadcast Endorsements [ see above question ]
0x02 DRIP Wrapper Authenticate full ASTM Messages [ see above question ]
0x03 DRIP Manifest Authenticate hashes of ASTM Messages [ see above question ]
0x04 DRIP Frame Format for future DRIP authentication [ see above question ]

Second, a new registry is to be created called the DROP Frame Type registry. The The new registry will be located in the Drone Remote ID Protocol registry group located at:

https://www.iana.org/assignments/drip/

The registration policy for the new registry is [RFC8126]:

0x01 - 0x9F: Expert Review
0xA0 - 0xEF: First Come First Served
0xF0 - 0xFF: Experimental Use

Frame Type 0x00 is to be marked reserved with a reference of [ RFC-to-be ].

The registry will include a note that registration requests MUST be sent to drip-reg-review@ietf.org and be evaluated within a three-week review period on the advice of one or more designated experts.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2023-12-20
43 Barry Leiba Request for Last Call review by ARTART is assigned to Tara Whalen
2023-12-20
43 Jim Reid Request for Last Call review by DNSDIR is assigned to Di Ma
2023-12-20
43 Gorry Fairhurst Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Gorry Fairhurst. Sent review to list.
2023-12-20
43 Magnus Westerlund Request for Last Call review by TSVART is assigned to Gorry Fairhurst
2023-12-19
43 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-12-19
43 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-01-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-drip-auth@ietf.org, drip-chairs@ietf.org, evyncke@cisco.com, mohamed.boucadair@orange.com, tm-rid@ietf.org …
The following Last Call announcement was sent out (ends 2024-01-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-drip-auth@ietf.org, drip-chairs@ietf.org, evyncke@cisco.com, mohamed.boucadair@orange.com, tm-rid@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID) to Proposed Standard


The IESG has received a request from the Drone Remote ID Protocol WG (drip)
to consider the following document: - 'DRIP Entity Tag Authentication Formats
& Protocols for Broadcast
  Remote ID'
  as Proposed Standard

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 2024-01-09. 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


  The Drone Remote Identification Protocol (DRIP), plus trust policies
  and periodic access to registries, augments Unmanned Aircraft System
  (UAS) Remote Identification (RID), enabling local real time
  assessment of trustworthiness of received RID messages and observed
  UAS, even by Observers then lacking Internet access.  This document
  defines DRIP message types and formats to be sent in Broadcast RID
  Authentication Messages to verify that attached and recent detached
  messages were signed by the registered owner of the DRIP Entity Tag
  (DET) claimed.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc9153: Drone Remote Identification Protocol (DRIP) Requirements and Terminology (Informational - Internet Engineering Task Force (IETF))
    rfc9434: Drone Remote Identification Protocol (DRIP) Architecture (Informational - Internet Engineering Task Force (IETF))



2023-12-19
43 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-12-19
43 Cindy Morgan Last call announcement was changed
2023-12-19
43 Éric Vyncke Last call was requested
2023-12-19
43 Éric Vyncke Last call announcement was generated
2023-12-19
43 Éric Vyncke Ballot approval text was generated
2023-12-19
43 Éric Vyncke Ballot writeup was generated
2023-12-19
43 Éric Vyncke AD review was acted upon by the authors. Email sent to support@ietf.org to request a 3-week IETF Last Call (end of the year vacations).
2023-12-19
43 Éric Vyncke IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2023-12-18
43 (System) Changed action holders to Éric Vyncke (IESG state changed)
2023-12-18
43 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-12-18
43 Adam Wiethuechter New version available: draft-ietf-drip-auth-43.txt
2023-12-18
43 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-12-18
43 Adam Wiethuechter Uploaded new revision
2023-12-15
42 Éric Vyncke AFAIK there are still some AD review comments to be addressed ;-)
2023-12-15
42 (System) Changed action holders to Adam Wiethuechter, Stuart Card, Robert Moskowitz (IESG state changed)
2023-12-15
42 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2023-12-14
42 Mohamed Boucadair
# Document Shepherd Write-Up for draft-ietf-drip-auth

Initial version: 05/12/2023
Updated version to remove a note about code delimiters: 15/12/2023

## Document History

1. Does the …
# Document Shepherd Write-Up for draft-ietf-drip-auth

Initial version: 05/12/2023
Updated version to remove a note about code delimiters: 15/12/2023

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?


The document went into 3 WGLCs. No controversy was raised during the development
of this specification, except the issue related to the code points to be
used for identifying the various authentication messages given that the process
for assigning and managing that space was not in place. The issue is now fixed
and the IETF has formally requested the allocation of 4 code points.
The codepoints will be echoed in an IANA registry (checked with IANA).


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, in addition to a proprietary implementation, the following ones were
disclosed:

* Implementation by Linköping University [18][19]
* DRIP Importer [20]

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Some key directorate reviews were arranged by the Chairs early in the process to tag
and fix security issues, in particular.

Also, LSs were sent to ASTM and ICAO about the SAM codepoints to identify DRIP
authentication messages. ASTM and ICAO representatives attended many of DRIP
meetings (including interims [21]). No technical issue was raised by ASTM/ICAO, but
the main blocking point was the management of the SAP codepoints. Codepoints
are not formally assigned to the IETF. As per the discussion with IANA, it is
OK to mirror these codes in the IANA DRIP registry.


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

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

N/A


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?


Yes. The shepherd made many reviews since early versions of this spec.
The authors adequately addressed all the issues raised by the shepherd [22].

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

We requested an OPS early review, but unfortunately no review was received.
We hope that an OPS review will happen in the IETF Last Call.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (authentication/
interop).

Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. Here are the replies from the authors:

- Stu: https://mailarchive.ietf.org/arch/msg/tm-rid/HxzguRqBGWpPhiC8hodLXRafEiU/
- Bob: https://mailarchive.ietf.org/arch/msg/tm-rid/WGd4zd3cLgyBQKXqau280D_QS1g/
- Adam: https://mailarchive.ietf.org/arch/msg/tm-rid/0fctB3FPRU6fjBUVDdAAE1ztV9s/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I do think that RFC 9153 and RFC 9434 can be listed as informative. This point
was already discussed in the WG.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are published RFCs, except a reference to an
external specification ([F3411]). That reference was already listed
in other DRIP RFCs, e.g., RFC 9153.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

RFC 9153 and RFC 9434.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document requests the creation of two registries. Both the target
location and required information to proceed with the IANA actions
are provided. The document also include guidance for expert review.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.


DRIP SAM Type and DRIP Frame Type are new registries under the DRIP
registry group.

The document also include guidance for expert review.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://mailarchive.ietf.org/arch/msg/tm-rid/SGIgyJz4HjXkOkBzPIpoJXX_OsU/
[19]: https://play.google.com/store/apps/details?id=org.securedroneid.android&pli=1
[20]: https://github.com/openutm/verification/tree/main/flight_blender_e2e_integration/ietf-drip
[21]: https://datatracker.ietf.org/doc/minutes-interim-2023-drip-02-202306141400/
[22]: https://github.com/ietf-wg-drip/draft-ietf-drip-auth/issues?q=is%3Aissue+author%3A%40me+is%3Aclosed
2023-12-14
42 (System) Changed action holders to Éric Vyncke (IESG state changed)
2023-12-14
42 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-12-14
42 Adam Wiethuechter New version available: draft-ietf-drip-auth-42.txt
2023-12-14
42 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-12-14
42 Adam Wiethuechter Uploaded new revision
2023-12-08
41 Éric Vyncke Sent AD review to https://mailarchive.ietf.org/arch/msg/tm-rid/mKMlkJkmNW9OkGJcUdMel4W2mzw/
2023-12-08
41 (System) Changed action holders to Adam Wiethuechter, Stuart Card, Robert Moskowitz (IESG state changed)
2023-12-08
41 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2023-12-07
41 Mohamed Boucadair
# Document Shepherd Write-Up for draft-ietf-drip-auth

Initial version: 05/12/2023

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a …
# Document Shepherd Write-Up for draft-ietf-drip-auth

Initial version: 05/12/2023

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?


The document went into 3 WGLCs. No controversy was raised during the development
of this specification, except the issue related to the code points to be
used for identifying the various authentication messages given that the process
for assigning and managing that space was not in place. The issue is now fixed
and the IETF has formally requested the allocation of 4 code points.
The codepoints will be echoed in an IANA registry (checked with IANA).


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, in addition to a proprietary implementation, the following ones were
disclosed:

* Implementation by Linköping University [18][19]
* DRIP Importer [20]

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Some key directorate reviews were arranged by the Chairs early in the process to tag
and fix security issues, in particular.

Also, LSs were sent to ASTM and ICAO about the SAM codepoints to identify DRIP
authentication messages. ASTM and ICAO representatives attended many of DRIP
meetings (including interims [21]). No technical issue was raised by ASTM/ICAO, but
the main blocking point was the management of the SAP codepoints. Codepoints
are not formally assigned to the IETF. As per the discussion with IANA, it is
OK to mirror these codes in the IANA DRIP registry.


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

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

N/A


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?


Yes. The shepherd made many reviews since early versions of this spec.
The authors adequately addressed all the issues raised by the shepherd [22].

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

We requested an OPS early review, but unfortunately no review was received.
We hope that an OPS review will happen in the IETF Last Call.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (authentication/
interop).

Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. Here are the replies from the authors:

- Stu: https://mailarchive.ietf.org/arch/msg/tm-rid/HxzguRqBGWpPhiC8hodLXRafEiU/
- Bob: https://mailarchive.ietf.org/arch/msg/tm-rid/WGd4zd3cLgyBQKXqau280D_QS1g/
- Adam: https://mailarchive.ietf.org/arch/msg/tm-rid/0fctB3FPRU6fjBUVDdAAE1ztV9s/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is this warning:

  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.

This is OK as the pseudo code is provided as an example.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I do think that RFC 9153 and RFC 9434 can be listed as informative. This point
was already discussed in the WG.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are published RFCs, except a reference to an
external specification ([F3411]). That reference was already listed
in other DRIP RFCs, e.g., RFC 9153.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

RFC 9153 and RFC 9434.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document requests the creation of two registries. Both the target
location and required information to proceed with the IANA actions
are provided. The document also include guidance for expert review.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.


DRIP SAM Type and DRIP Frame Type are new registries under the DRIP
registry group.

The document also include guidance for expert review.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://mailarchive.ietf.org/arch/msg/tm-rid/SGIgyJz4HjXkOkBzPIpoJXX_OsU/
[19]: https://play.google.com/store/apps/details?id=org.securedroneid.android&pli=1
[20]: https://github.com/openutm/verification/tree/main/flight_blender_e2e_integration/ietf-drip
[21]: https://datatracker.ietf.org/doc/minutes-interim-2023-drip-02-202306141400/
[22]: https://github.com/ietf-wg-drip/draft-ietf-drip-auth/issues?q=is%3Aissue+author%3A%40me+is%3Aclosed
2023-12-06
41 Éric Vyncke AD review started
2023-12-06
41 (System) Changed action holders to Éric Vyncke (IESG state changed)
2023-12-06
41 Éric Vyncke IESG state changed to AD Evaluation from Publication Requested
2023-12-05
41 Mohamed Boucadair
# Document Shepherd Write-Up for draft-ietf-drip-auth

Initial version: 05/12/2023

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a …
# Document Shepherd Write-Up for draft-ietf-drip-auth

Initial version: 05/12/2023

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?


The document went into 3 WGLCs. No controversy was raised during the development
of this specification, except the issue related to the code points to be
used for identifying the various authentication messages given that the process
for assigning and managing that space was not in place. The issue is now fixed
and the IETF has formally requested the allocation of 4 code points (with fees).
The codepoints will be echoed in an IANA registry (checked with IANA).


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, in addition to a proprietary implementation, the following ones were
disclosed:

* [18]
* Secure remote Drone ID (DRIP) Android App [19]
* DRIP Importer [20]

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Some key directorate reviews were arranged by the Chairs early in the process to tag
and fix security issues, in particular.

Alos, LSs were sent to ASTM and ICAO about the SAM codepoints to identify DRIP
authentication messages. ASTM and ICAP representatives attended many of DRIP
meetings (including interims [21]). No technical issue was raised by ASTM/ICAO, but
the main blocking point was the management of the SAP codepoints. Codepoints
are not formally assigned to the IETF. As per the discussion with IANA, it is
OK to mirror these codes in the IANA DRIP registry.


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

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

N/A


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?


Yes. The shepherd made many reviews since early versions of this spec.
The authors adequately addressed all the issues raised by the shepherd [22].

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

We requested an OPS early review, but unfortunately no review was received.
We hope that an OPS review will happen in the IETF Last Call.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (authentication/
interop).

Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. Here are the replies from the authors:

- Stu: https://mailarchive.ietf.org/arch/msg/tm-rid/HxzguRqBGWpPhiC8hodLXRafEiU/
- Bob: https://mailarchive.ietf.org/arch/msg/tm-rid/WGd4zd3cLgyBQKXqau280D_QS1g/
- Adam: https://mailarchive.ietf.org/arch/msg/tm-rid/0fctB3FPRU6fjBUVDdAAE1ztV9s/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is this warning:

  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I do think that RFC 9153 and RFC 9434 can be listed as informative. This point
was already discussed in the WG.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are published RFCs, except a reference to an
external specification ([F3411]). That reference was already listed
in other DRIP RFCs, e.g., RFC 9153.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

RFC 9153 and RFC 9434.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document requests the creation of two registries. Both the target
location and required information to proceed with the IANA actions
are provided. The document also include guidance for expert review.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.


DRIP SAM Type and DRIP Frame Type are new registries under the DRIP
registry group.

The document also include guidance for expert review.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://mailarchive.ietf.org/arch/msg/tm-rid/SGIgyJz4HjXkOkBzPIpoJXX_OsU/
[19]: https://play.google.com/store/apps/details?id=org.securedroneid.android&pli=1
[20]: https://github.com/openutm/verification/tree/main/flight_blender_e2e_integration/ietf-drip
[21]: https://datatracker.ietf.org/doc/minutes-interim-2023-drip-02-202306141400/
[22]: https://github.com/ietf-wg-drip/draft-ietf-drip-auth/issues?q=is%3Aissue+author%3A%40me+is%3Aclosed
2023-12-05
41 Mohamed Boucadair Responsible AD changed to Éric Vyncke
2023-12-05
41 Mohamed Boucadair IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2023-12-05
41 Mohamed Boucadair IESG state changed to Publication Requested from I-D Exists
2023-12-05
41 Mohamed Boucadair Document is now in IESG state Publication Requested
2023-12-05
41 Mohamed Boucadair Tag Doc Shepherd Follow-up Underway cleared.
2023-12-05
41 Mohamed Boucadair
# Document Shepherd Write-Up for draft-ietf-drip-auth

Initial version: 05/12/2023

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a …
# Document Shepherd Write-Up for draft-ietf-drip-auth

Initial version: 05/12/2023

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is clear consensus to progress this specification.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?


The document went into 3 WGLCs. No controversy was raised during the development
of this specification, except the issue related to the code points to be
used for identifying the various authentication messages given that the process
for assigning and managing that space was not in place. The issue is now fixed
and the IETF has formally requested the allocation of 4 code points (with fees).
The codepoints will be echoed in an IANA registry (checked with IANA).


3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, in addition to a proprietary implementation, the following ones were
disclosed:

* [18]
* Secure remote Drone ID (DRIP) Android App [19]
* DRIP Importer [20]

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Some key directorate reviews were arranged by the Chairs early in the process to tag
and fix security issues, in particular.

Alos, LSs were sent to ASTM and ICAO about the SAM codepoints to identify DRIP
authentication messages. ASTM and ICAP representatives attended many of DRIP
meetings (including interims [21]). No technical issue was raised by ASTM/ICAO, but
the main blocking point was the management of the SAP codepoints. Codepoints
are not formally assigned to the IETF. As per the discussion with IANA, it is
OK to mirror these codes in the IANA DRIP registry.


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

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

N/A


8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?


Yes. The shepherd made many reviews since early versions of this spec.
The authors adequately addressed all the issues raised by the shepherd [22].

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

We requested an OPS early review, but unfortunately no review was received.
We hope that an OPS review will happen in the IETF Last Call.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.

This status is appropriate given the nature of the specification (authentication/
interop).

Datatracker state attributes correctly reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. Here are the replies from the authors:

- Stu: https://mailarchive.ietf.org/arch/msg/tm-rid/HxzguRqBGWpPhiC8hodLXRafEiU/
- Bob: https://mailarchive.ietf.org/arch/msg/tm-rid/WGd4zd3cLgyBQKXqau280D_QS1g/
- Adam: https://mailarchive.ietf.org/arch/msg/tm-rid/0fctB3FPRU6fjBUVDdAAE1ztV9s/


13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is this warning:

  -- Found something which looks like a code comment -- if you have code
    sections in the document, please surround them with '' and
    '' lines.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

I do think that RFC 9153 and RFC 9434 can be listed as informative. This point
was already discussed in the WG.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are published RFCs, except a reference to an
external specification ([F3411]). That reference was already listed
in other DRIP RFCs, e.g., RFC 9153.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

RFC 9153 and RFC 9434.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

None

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document requests the creation of two registries. Both the target
location and required information to proceed with the IANA actions
are provided. The document also include guidance for expert review.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.


DRIP SAM Type and DRIP Frame Type are new registries under the DRIP
registry group.

The document also include guidance for expert review.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://mailarchive.ietf.org/arch/msg/tm-rid/SGIgyJz4HjXkOkBzPIpoJXX_OsU/
[19]: https://play.google.com/store/apps/details?id=org.securedroneid.android&pli=1
[20]: https://github.com/openutm/verification/tree/main/flight_blender_e2e_integration/ietf-drip
[21]: https://datatracker.ietf.org/doc/minutes-interim-2023-drip-02-202306141400/
[22]: https://github.com/ietf-wg-drip/draft-ietf-drip-auth/issues?q=is%3Aissue+author%3A%40me+is%3Aclosed
2023-12-05
41 Mohamed Boucadair Tag Doc Shepherd Follow-up Underway set. Tag Revised I-D Needed - Issue raised by WGLC cleared.
2023-12-05
41 Mohamed Boucadair IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2023-12-04
41 Adam Wiethuechter New version available: draft-ietf-drip-auth-41.txt
2023-12-04
41 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-12-04
41 Adam Wiethuechter Uploaded new revision
2023-11-14
40 Adam Wiethuechter New version available: draft-ietf-drip-auth-40.txt
2023-11-14
40 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-11-14
40 Adam Wiethuechter Uploaded new revision
2023-10-30
39 Mohamed Boucadair Tag Revised I-D Needed - Issue raised by WGLC set.
2023-10-17
39 Mohamed Boucadair
# Document Shepherd Write-Up for Group Documents

* 3GGLCs
* LS ICAO
* implem: https://mailarchive.ietf.org/arch/msg/tm-rid/SGIgyJz4HjXkOkBzPIpoJXX_OsU/
* IPR
- Stu: https://mailarchive.ietf.org/arch/msg/tm-rid/HxzguRqBGWpPhiC8hodLXRafEiU/
- Bob: https://mailarchive.ietf.org/arch/msg/tm-rid/WGd4zd3cLgyBQKXqau280D_QS1g/
- Adam: https://mailarchive.ietf.org/arch/msg/tm-rid/0fctB3FPRU6fjBUVDdAAE1ztV9s/




Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.)

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

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

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2023-10-17
39 Mohamed Boucadair
# Document Shepherd Write-Up for Group Documents

* 3GGLCs
* LS ICAO
* implem: https://mailarchive.ietf.org/arch/msg/tm-rid/SGIgyJz4HjXkOkBzPIpoJXX_OsU/
* IPR
- Stu: https://mailarchive.ietf.org/arch/msg/tm-rid/HxzguRqBGWpPhiC8hodLXRafEiU/
- Bob: https://mailarchive.ietf.org/arch/msg/tm-rid/WGd4zd3cLgyBQKXqau280D_QS1g/




Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.)

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

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

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2023-10-16
39 Mohamed Boucadair
Given the changes made since the last WGLC (1), we would like to make sure that the WG is happy with this version to be …
Given the changes made since the last WGLC (1), we would like to make sure that the WG is happy with this version to be sent to the IESG.

Please review and share your comments by October 30, 2023.

Comments (including, "I like this version as it is") are useful to share. Also, thoughts about how to address a recent comment about whether RFCs 9153 and 9434 should be cited as informative or normative, are also welcome.

(1): https://author-tools.ietf.org/iddiff?url1=draft-ietf-drip-auth-14&url2=draft-ietf-drip-auth-39&difftype=--html
2023-10-16
39 Mohamed Boucadair Tag Doc Shepherd Follow-up Underway cleared.
2023-10-16
39 Mohamed Boucadair IETF WG state changed to In WG Last Call from WG Document
2023-10-12
39 Adam Wiethuechter New version available: draft-ietf-drip-auth-39.txt
2023-10-12
39 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-10-12
39 Adam Wiethuechter Uploaded new revision
2023-10-11
38 Adam Wiethuechter New version available: draft-ietf-drip-auth-38.txt
2023-10-11
38 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-10-11
38 Adam Wiethuechter Uploaded new revision
2023-09-26
37 Adam Wiethuechter New version available: draft-ietf-drip-auth-37.txt
2023-09-26
37 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-09-26
37 Adam Wiethuechter Uploaded new revision
2023-09-25
36 Adam Wiethuechter New version available: draft-ietf-drip-auth-36.txt
2023-09-25
36 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-09-25
36 Adam Wiethuechter Uploaded new revision
2023-09-20
35 Mohamed Boucadair Tag Doc Shepherd Follow-up Underway set. Tag Revised I-D Needed - Issue raised by WGLC cleared.
2023-09-20
35 Adam Wiethuechter New version available: draft-ietf-drip-auth-35.txt
2023-09-20
35 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-09-20
35 Adam Wiethuechter Uploaded new revision
2023-09-20
34 Adam Wiethuechter New version available: draft-ietf-drip-auth-34.txt
2023-09-20
34 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-09-20
34 Adam Wiethuechter Uploaded new revision
2023-09-19
33 Adam Wiethuechter New version available: draft-ietf-drip-auth-33.txt
2023-09-19
33 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-09-19
33 Adam Wiethuechter Uploaded new revision
2023-09-18
32 Adam Wiethuechter New version available: draft-ietf-drip-auth-32.txt
2023-09-18
32 Adam Wiethuechter New version approved
2023-09-18
32 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2023-09-18
32 Adam Wiethuechter Uploaded new revision
2023-09-13
31 Adam Wiethuechter New version available: draft-ietf-drip-auth-31.txt
2023-09-13
31 (System) New version approved
2023-09-13
31 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2023-09-13
31 Adam Wiethuechter Uploaded new revision
2023-08-29
30 Daniel Migault IETF WG state changed to WG Document from In WG Last Call
2023-07-12
30 Mohamed Boucadair SAM IDs are pre-assigned at https://www.icao.int/airnavigation/IATF/Documents/ASTM%20F3411-22a%20SAM%20ID%20%20Registry_Public_10.07.23.xlsx?Web=1
2023-06-28
30 Mohamed Boucadair Added to session: interim-2023-drip-03
2023-06-14
30 Mohamed Boucadair Added to session: interim-2023-drip-02
2023-03-27
30 Adam Wiethuechter New version available: draft-ietf-drip-auth-30.txt
2023-03-27
30 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-03-27
30 Adam Wiethuechter Uploaded new revision
2023-03-27
29 Mohamed Boucadair Added to session: IETF-116: drip  Tue-0630
2023-03-18
29 Qin Wu Removed from session: IETF-116: alto  Mon-0830
2023-03-14
29 Mohamed Boucadair Added to session: IETF-116: alto  Mon-0830
2023-02-22
29 Mohamed Boucadair Still waiting for the ASTM/ICAO feedback about SAM allocations
2023-02-22
29 Mohamed Boucadair Notification list changed to mohamed.boucadair@orange.com because the document shepherd was set
2023-02-22
29 Mohamed Boucadair Document shepherd changed to Mohamed Boucadair
2023-02-21
29 Mohamed Boucadair Added to session: interim-2023-drip-01
2023-02-15
29 Adam Wiethuechter New version available: draft-ietf-drip-auth-29.txt
2023-02-15
29 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2023-02-15
29 Adam Wiethuechter Uploaded new revision
2023-01-27
28 Adam Wiethuechter New version available: draft-ietf-drip-auth-28.txt
2023-01-27
28 (System) New version approved
2023-01-27
28 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2023-01-27
28 Adam Wiethuechter Uploaded new revision
2023-01-06
27 Adam Wiethuechter New version available: draft-ietf-drip-auth-27.txt
2023-01-06
27 (System) New version approved
2023-01-06
27 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2023-01-06
27 Adam Wiethuechter Uploaded new revision
2022-11-03
26 Mohamed Boucadair Tag Revised I-D Needed - Issue raised by WGLC set.
2022-10-26
26 Mohamed Boucadair Added to session: IETF-115: drip  Thu-1530
2022-10-17
26 Mohamed Boucadair Changed document external resources from: None to:

github_repo https://github.com/ietf-wg-drip/draft-ietf-drip-auth
2022-10-14
26 Adam Wiethuechter New version available: draft-ietf-drip-auth-26.txt
2022-10-14
26 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-10-14
26 Adam Wiethuechter Uploaded new revision
2022-10-14
25 Mohamed Boucadair 2nd WGLC from 14/10/22 to 28/10/22
2022-10-13
25 Adam Wiethuechter New version available: draft-ietf-drip-auth-25.txt
2022-10-13
25 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-10-13
25 Adam Wiethuechter Uploaded new revision
2022-10-12
24 Matt Joras Request for Early review by GENART Completed: Ready with Nits. Reviewer: Matt Joras. Sent review to list.
2022-10-12
24 Adam Wiethuechter New version available: draft-ietf-drip-auth-24.txt
2022-10-12
24 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-10-12
24 Adam Wiethuechter Uploaded new revision
2022-10-07
23 Adam Wiethuechter New version available: draft-ietf-drip-auth-23.txt
2022-10-07
23 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-10-07
23 Adam Wiethuechter Uploaded new revision
2022-09-29
22 Adam Wiethuechter New version available: draft-ietf-drip-auth-22.txt
2022-09-29
22 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-09-29
22 Adam Wiethuechter Uploaded new revision
2022-09-01
21 Adam Wiethuechter New version available: draft-ietf-drip-auth-21.txt
2022-09-01
21 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-09-01
21 Adam Wiethuechter Uploaded new revision
2022-09-01
20 Adam Wiethuechter New version available: draft-ietf-drip-auth-20.txt
2022-09-01
20 (System) New version approved
2022-09-01
20 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2022-09-01
20 Adam Wiethuechter Uploaded new revision
2022-08-30
19 Adam Wiethuechter New version available: draft-ietf-drip-auth-19.txt
2022-08-30
19 (System) New version approved
2022-08-30
19 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2022-08-30
19 Adam Wiethuechter Uploaded new revision
2022-08-13
18 Adam Wiethuechter New version available: draft-ietf-drip-auth-18.txt
2022-08-13
18 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-08-13
18 Adam Wiethuechter Uploaded new revision
2022-08-08
17 Adam Wiethuechter New version available: draft-ietf-drip-auth-17.txt
2022-08-08
17 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-08-08
17 Adam Wiethuechter Uploaded new revision
2022-08-08
16 Adam Wiethuechter New version available: draft-ietf-drip-auth-16.txt
2022-08-08
16 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-08-08
16 Adam Wiethuechter Uploaded new revision
2022-07-19
15 Mohamed Boucadair Added to session: IETF-114: drip  Mon-1330
2022-07-16
15 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Carlos Martínez
2022-07-16
15 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Carlos Martínez
2022-07-14
15 Jean Mahoney Request for Early review by GENART is assigned to Matt Joras
2022-07-14
15 Jean Mahoney Request for Early review by GENART is assigned to Matt Joras
2022-07-12
15 Mohamed Boucadair Requested Early review by OPSDIR
2022-07-12
15 Mohamed Boucadair Requested Early review by GENART
2022-07-11
15 Adam Wiethuechter New version available: draft-ietf-drip-auth-15.txt
2022-07-11
15 (System) New version approved
2022-07-11
15 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2022-07-11
15 Adam Wiethuechter Uploaded new revision
2022-06-24
14 Mohamed Boucadair Ends 08/07/2022
2022-06-24
14 Mohamed Boucadair IETF WG state changed to In WG Last Call from WG Document
2022-06-21
14 Adam Wiethuechter New version available: draft-ietf-drip-auth-14.txt
2022-06-21
14 (System) New version approved
2022-06-21
14 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2022-06-21
14 Adam Wiethuechter Uploaded new revision
2022-06-14
13 Adam Wiethuechter New version available: draft-ietf-drip-auth-13.txt
2022-06-14
13 (System) New version approved
2022-06-14
13 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2022-06-14
13 Adam Wiethuechter Uploaded new revision
2022-05-25
12 Adam Wiethuechter New version available: draft-ietf-drip-auth-12.txt
2022-05-25
12 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-05-25
12 Adam Wiethuechter Uploaded new revision
2022-05-25
11 Adam Wiethuechter New version available: draft-ietf-drip-auth-11.txt
2022-05-25
11 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-05-25
11 Adam Wiethuechter Uploaded new revision
2022-05-11
10 Adam Wiethuechter New version available: draft-ietf-drip-auth-10.txt
2022-05-11
10 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-05-11
10 Adam Wiethuechter Uploaded new revision
2022-04-30
09 Adam Wiethuechter New version available: draft-ietf-drip-auth-09.txt
2022-04-30
09 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-04-30
09 Adam Wiethuechter Uploaded new revision
2022-04-26
08 Adam Wiethuechter New version available: draft-ietf-drip-auth-08.txt
2022-04-26
08 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-04-26
08 Adam Wiethuechter Uploaded new revision
2022-04-19
07 Adam Wiethuechter New version available: draft-ietf-drip-auth-07.txt
2022-04-19
07 Adam Wiethuechter New version accepted (logged-in submitter: Adam Wiethuechter)
2022-04-19
07 Adam Wiethuechter Uploaded new revision
2022-04-14
06 Adam Wiethuechter New version available: draft-ietf-drip-auth-06.txt
2022-04-14
06 (System) New version accepted (logged-in submitter: Adam Wiethuechter)
2022-04-14
06 Adam Wiethuechter Uploaded new revision
2022-03-22
05 Rich Salz Request for Early review by SECDIR Completed: Has Issues. Reviewer: Rich Salz. Sent review to list.
2022-03-10
05 Tero Kivinen Request for Early review by SECDIR is assigned to Rich Salz
2022-03-10
05 Tero Kivinen Request for Early review by SECDIR is assigned to Rich Salz
2022-03-09
05 Mohamed Boucadair Added to session: IETF-113: drip  Wed-1300
2022-03-08
05 Mohamed Boucadair Requested Early review by SECDIR
2022-03-07
05 Adam Wiethuechter New version available: draft-ietf-drip-auth-05.txt
2022-03-07
05 (System) New version approved
2022-03-07
05 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2022-03-07
05 Adam Wiethuechter Uploaded new revision
2021-12-20
04 Adam Wiethuechter New version available: draft-ietf-drip-auth-04.txt
2021-12-20
04 (System) New version approved
2021-12-20
04 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2021-12-20
04 Adam Wiethuechter Uploaded new revision
2021-11-08
03 Adam Wiethuechter New version available: draft-ietf-drip-auth-03.txt
2021-11-08
03 (System) New version approved
2021-11-08
03 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2021-11-08
03 Adam Wiethuechter Uploaded new revision
2021-10-26
02 Mohamed Boucadair Added to session: IETF-112: drip  Thu-1430
2021-10-21
02 Adam Wiethuechter New version available: draft-ietf-drip-auth-02.txt
2021-10-21
02 (System) New version approved
2021-10-21
02 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2021-10-21
02 Adam Wiethuechter Uploaded new revision
2021-07-09
01 Mohamed Boucadair Added to session: IETF-111: drip  Wed-1430
2021-06-18
01 Adam Wiethuechter New version available: draft-ietf-drip-auth-01.txt
2021-06-18
01 (System) New version approved
2021-06-18
01 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Robert Moskowitz , Stuart Card
2021-06-18
01 Adam Wiethuechter Uploaded new revision
2021-03-10
00 Mohamed Boucadair This document now replaces draft-wiethuechter-drip-auth instead of None
2021-03-10
00 Mohamed Boucadair Changed consensus to Yes from Unknown
2021-03-10
00 Mohamed Boucadair Intended Status changed to Proposed Standard from None
2021-03-08
00 Mohamed Boucadair Added to session: IETF-110: drip  Tue-1700
2020-12-18
00 Adam Wiethuechter New version available: draft-ietf-drip-auth-00.txt
2020-12-18
00 (System) WG -00 approved
2020-12-18
00 Adam Wiethuechter Set submitter to "Adam Wiethuechter ", replaces to (none) and sent approval email to group chairs: drip-chairs@ietf.org
2020-12-18
00 Adam Wiethuechter Uploaded new revision