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

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-drip-auth and RFC 9575, changed IESG state to RFC Published)

[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.

[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?

[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

[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.

[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?

[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.

[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?

[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.

[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

[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.

[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)

(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

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))

# 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

# 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

# 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

# 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

# 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/

# 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/

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