Shepherd write-up for draft-ietf-drip-reqs-15
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in
the title page header?
This document requests publication as an Informational RFC. That is
indicated on the header page.
The status is appropriate as the document is defining a set of requirements
that will drive DRIP specifications.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up.
Recent examples can be found in the "Action" announcements for
approved documents. The approval announcement contains the
following sections:
Technical Summary:
This document defines terminology and requirements for Drone Remote
Identification Protocol (DRIP) Working Group solutions to support
Unmanned Aircraft System Remote Identification and tracking (UAS RID)
for security, safety, and other purposes. Complementing external
technical standards as regulator-accepted means of compliance with
UAS RID regulations, DRIP is meant to facilitate use of existing Internet
resources to support UAS RID and to enable enhanced related services,
and enable online and offline verification that UAS RID information
is trustworthy.
Working Group Summary:
This document ran 7 versions before adoption by the WG.
No major points of contention were encountered during the adoption,
development, and WGLC.
Slots were dedicated to this draft in 8 WG meetings (from 2020-03-25
to 2020-10-28). These slots helped to identify and fix issues. The
authors implemented the outcomes of the discussions held in these
meetings.
Given the scope of the draft (and the WG in general), the Chairs
contacted dozens of SDOs and organizations to socialize the WG in
general, and to notify them about WGLC. Representatives of other
organizations attended the WG meeting and contributed to the
discussion. For example, ICAO representatives (Saulo Da Silva)
attended the meetings and shared some feedback. Special care was
given the privacy since early stage of this document.
To further stress on that, the WG Chairs solicited detailed reviews
such as: https://mailarchive.ietf.org/arch/msg/tm-
rid/8iXcPG2tgR7VQVrIPZUr1JiA7g0/. The authors updated the draft
accordingly.
Early versions of the document was largely based on the process
of one region (US). The WG discussed that issue at the time and
agreed to progress the work based on available inputs/volunteers
as any other IETF effort. Also, the WG agreed to record this issue
in an appendix. Since then, the document was enriched with inputs
and relevant documents from the EU region.
The authors released -13 to address both secdir and opsdir reviews.
Like many other documents these days, no other comments were received
as part of the IETF Last Call.
Document Quality:
Detailed reviews were received for the draft, e.g.,
https://mailarchive.ietf.org/arch/msg/tm-rid/nE40wF9i-
eUxx21ffQzW3njv9ZU/.
These reviews helped to enhance the quality of the document.
Personnel:
The document shepherd is Mohamed Boucadair
<mohamed.boucadair@orange.com>
The Responsible Area Director is Eric Vyncke <evyncke@cisco.com>
(3) Briefly describe the review of this document that was performed by
the Document Shepherd.
At least three detailed reviews were made by the Document Shepherd:
o before adoption: https://github.com/boucadair/IETF-Drafts-
Reviews/blob/master/draft-card-tmrid-uas-reqs-00-rev%20Med.pdf
o -01: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/
draft-ietf-drip-reqs-01-rev%20Med.pdf
o as a shepherd: https://github.com/boucadair/IETF-Drafts-
Reviews/blob/master/draft-ietf-drip-reqs-06-rev%20Med.pdf
The authors have taken into account these various reviews.
This version is ready for publication.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
I have a concern with the updated figure 1 in -15. This figure includes a lot
of details about interfaces and so on; such details are more suitable in the
DRIP architecture I-D.
(5) Do portions of the document need review from a particular or from
broader perspective.
No.
(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of?
No.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of
BCP 78 and BCP 79 have already been filed.
Yes. IPR responses can be seen at:
Stuart Card: https://mailarchive.ietf.org/arch/msg/tm-rid/
CmbjhL7YzBSkal3-8pjnQ6N_6CI/
Adam Wiethuechter: https://mailarchive.ietf.org/arch/msg/tm-rid/
LOEgSVn5tSE8WSC3uKExLjjOdYw/
Robert Moskowitz: https://mailarchive.ietf.org/arch/msg/tm-rid/
J9MqBiIFy7v3Y2RCn4HVlULRN9A/
Andrei Gurtov: https://mailarchive.ietf.org/arch/msg/tm-rid/N2WD6y-
GdOzkhuyd437iYDtzUQQ/
(8) Has an IPR disclosure been filed that references this document?
No.
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with
it?
The consensus is solid.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?
No.
(11) Identify any ID nits the Document Shepherd has found in this
document.
idnits is clean.
(12) Describe how the document meets any required formal review
criteria
No formal language is used.
(13) Have all references within this document been identified as
either normative or informative?
Yes.
(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their
completion?
All normative references are published RFCs, except a reference to an
external specification ([F3411-19]).
Note that [F3411-19] is not freely available ($88), but an early
version is publicly available at
https://raw.githubusercontent.com/opendroneid/specs/master/
OpenDroneID_Bluetooth_0.64.3.pdf. A pointer to this freely available
document is also cited in the document. This is clearly called in
the draft (see the text right after Figure 2).
(15) Are there downward normative references references (see
RFC 3967)?
No downrefs.
(16) Will publication of this document change the status of any
existing RFCs?
No.
(17) Describe the Document Shepherd's review of the IANA
considerations section.
No IANA action is required. This is appropriately captured in the document.
(18) List any new IANA registries that require Expert Review for
future allocations.
None.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language.
N/A
(20) If the document contains a YANG module
N/A