Shepherd write-up for draft-ietf-drip-rid-22
(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 a Proposed Standard RFC. That
is indicated on the header page. The intended status is justified
given that the document (1) specifies a modified version of host
identity tags (initially defined in RFC 7401 that was published in
Standards Track) and (2) updates RFC 7343 (also published in the
Standards Track).
(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 specifies DRIP Entity Tags (DETs) that are used for
drone identification purposes (a.k.a., UAS Remote ID). DETs rely
upon Hierarchical Host Identity Tags (HHITs) which are defined as
self-asserting IPv6 addresses. Also, these HHITs include explicit
hierarchy to enable DNS queries and discovery of specific registrars
for 3rd-party identification attestation purposes.
Working Group Summary:
This document ran 8 versions before adoption by the WG (including a
version that passed surprisingly through without any validation by
the submission part of the datatracker and published as draft-ietf-drip-*;
see https://datatracker.ietf.org/doc/draft-ietf-drip-uas-rid/history/).
Regular slots were dedicated to this draft in several WG meetings.
The authors implemented the outcomes of the discussions held in these
meetings and the mailing list.
Once the draft was adopted, a note was sent to HIPSEC mailing
(https://mailarchive.ietf.org/arch/msg/
hipsec/2ojLTMCR7-YKQ5RJ68pBABF4mSY/) to check if there are any issues
with the specification (HIP part), but no follow up message was received.
Early SECDIR and IOTDIR reviews were requested by the Chairs against
-07. These reviews were addressed by the authors.
As suggested by the SECDIR reviewer, a review request was sent to the
CFRG for review (31/08/2021). A discussion in the CFRG mailing list
was then triggered: https://mailarchive.ietf.org/arch/msg/
cfrg/56XscYjs_GprhS0wxvVDWNincPg/ (09/2021) with the outcomes
implemented in -11.
A note was also sent to SAAG to seek for reviews, especially the
privacy section (https://mailarchive.ietf.org/arch/msg/
saag/5tyVqtjCGKVcSeX9gpS4_feI7YQ/). No follow up message was received :-(
The draft used to include some actions on behalf of the ICAO (RAA
assignment, for example), while these are not formally discussed by
the WG. These statements were removed and an action plan was agreed.
The WG agreed that no RAA assignment policy will be included in this
document. Such considerations (e.g., whether to abandon the control on
the RAA assignment bound to the IANA-assigned prefix or keep the full
control but have a provision for some delegation) will be covered in
draft-ietf-drip-registries. From an interoperability, this plan is OK
as DETs are unambiguously identified by the prefix.
There was a concern whether /28 prefix is sufficient to cover any
HHIT needs, not only DETs. The main outcomes were:
o The IPv6 prefix is for DRIP use and, as such, the requested prefix
size is reasonable. This block should be named "DRIP Device
Entity Tags (DETs) Prefix" to avoid any confusion.
o Maintain the request for the IANA /28 prefix.
o Add a provision for the use of other prefixes, including network-
specific prefixes.
o To unambiguously identify a DET, create a new registry to list
prefixes used for DET purposes.
Some issues were reported by IANA against -13: add a registration
procedure for the new EdDSA Curve Label registry, indicate the upper
boundary for the registry's Value field, etc.
Sections 3.4.1 and 3.4.2 discuss HIP parameters that are impacted
as a side effect of defining EdDSA as a HI algorithm. These
parameters are not needed for DRIP. The draft includes two notes to
make this clear enough.
At least two implementations were reported to the WG, one of them is
proprietary.
Document Quality:
The various 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 Éric 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 -07: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/
draft-ietf-drip-rid-07-rev%20Med.pdf
o -13: https://raw.githubusercontent.com/boucadair/IETF-Drafts-
Reviews/master/draft-ietf-drip-rid-13-rev%20Med.pdf
o -18: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/
draft-ietf-drip-rid-18-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?
No concern.
(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:
* Robert Moskowitz: https://mailarchive.ietf.org/arch/msg/tm-rid/H9G2SawqP0PtJyQK6LciyBGULgY/
* Stuart Card: https://mailarchive.ietf.org/arch/msg/tm-rid/WL2bPmcLpvMOHMfH-OrEN7UII5E/
* Adam Wiethuechter: https://mailarchive.ietf.org/arch/msg/tm-rid/9Ut-t3dVDZmEFz6xHSwcSIssYgs/
* Andrei Gurtov: https://mailarchive.ietf.org/arch/msg/tm-rid/fmiSIhWgOsmtvIYGmBPHKVBfpyY/
(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.
Some issues were found and shared with the authors (e.g., citations
in abstract, self-contained updated). These were fixed by the
authors.
Idnits still displays the following:
== There are 3 instances of lines with non-ascii characters in the document.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
== There are 8 instances of lines with non-RFC3849-compliant IPv6 addresses
in the document. If these are example addresses, they should be changed.
... but all these are false positives:
o The first nit is related to the affiliation of one of the co-
authors.
o The second nit is related to '100.hhit.arpa', but that's a valid
example.
o The third nit is related to the IANA IPv6 prefix.
(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 or publicly available
stable specifications.
(15) Are there downward normative references references (see
RFC 3967)?
Yes, RFC8032.
RFC8032 is already listed in https://datatracker.ietf.org/doc/downref/.
(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.
o The document creates a new registry for DRIP. It also creates a
two subregistries under that registry. The required policy for
adding new entries is provided for each of these subregistries.
o Updates a set of existing registries. The required information
to complete the actions, including where to find the registries, is
provided.
(18) List any new IANA registries that require Expert Review for
future allocations.
"Hierarchical HIT (HHIT) Prefixes"
(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