Skip to main content

Shepherd writeup
draft-ietf-drip-rid

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
Back