Skip to main content

Drone Remote Identification Protocol (DRIP) Requirements and Terminology
draft-ietf-drip-reqs-18

Revision differences

Document history

Date Rev. By Action
2022-02-03
18 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-11-21
18 (System) RFC Editor state changed to AUTH48
2021-11-12
18 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-09-09
18 Mohamed Boucadair Notification list changed to mohamed.boucadair@orange.com from tm-rid@ietf.org, mohamed.boucadair@orange.com
2021-09-09
18 (System) RFC Editor state changed to EDIT
2021-09-09
18 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-09-09
18 (System) Announcement was received by RFC Editor
2021-09-09
18 (System) IANA Action state changed to No IANA Actions from In Progress
2021-09-09
18 (System) IANA Action state changed to In Progress
2021-09-09
18 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-09-09
18 Cindy Morgan IESG has approved the document
2021-09-09
18 Cindy Morgan Closed "Approve" ballot
2021-09-09
18 Cindy Morgan Ballot approval text was generated
2021-09-09
18 Éric Vyncke
As the -18 addresses all previous DISCUSS (thank you Roman for clearing them). Thanks to the authors for updated the text based on the IESG …
As the -18 addresses all previous DISCUSS (thank you Roman for clearing them). Thanks to the authors for updated the text based on the IESG evaluation.
2021-09-09
18 (System) Removed all action holders (IESG state changed)
2021-09-09
18 Éric Vyncke IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2021-09-08
18 Roman Danyliw
[Ballot comment]
Thank you to Linda Dunbar for the SECDIR review.

Thank you for addressing my DISCUSS and COMMENT points.


==[ OLD
** Section 1.1.  …
[Ballot comment]
Thank you to Linda Dunbar for the SECDIR review.

Thank you for addressing my DISCUSS and COMMENT points.


==[ OLD
** Section 1.1.  Is there a reference for IEEE 802.11 Beacon modes?

** Section 4.3.1. Is there a clear definition somewhere of (a) private information; and (b) safety critical information?

** Section 4.3.1.  PRIV-2.

DRIP MUST NOT encrypt safety critical data to be
          transmitted over Broadcast RID in any situation where it is
          unlikely that local Observers authorized to access the
          plaintext will be able to decrypt it or obtain it from a
          service able to decrypt it.

How would DRIP “know” that the local Observers are unlikely to be to be able to decrypt the information?
2021-09-08
18 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2021-09-08
18 Stuart Card New version available: draft-ietf-drip-reqs-18.txt
2021-09-08
18 (System) New version accepted (logged-in submitter: Stuart Card)
2021-09-08
18 Stuart Card Uploaded new revision
2021-07-07
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-07-07
17 Stuart Card New version available: draft-ietf-drip-reqs-17.txt
2021-07-07
17 (System) New version approved
2021-07-07
17 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card
2021-07-07
17 Stuart Card Uploaded new revision
2021-07-01
16 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2021-07-01
16 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-07-01
16 Robert Wilton [Ballot comment]
Thank you for an interesting, clear, and well written document.

Regards,
Rob
2021-07-01
16 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-07-01
16 Murray Kucherawy
[Ballot comment]
This is all very interesting.  And it's nice to see aviation (a hobby of mine) needing and seeking this kind of help from …
[Ballot comment]
This is all very interesting.  And it's nice to see aviation (a hobby of mine) needing and seeking this kind of help from technology.  I'm looking forward to the actual protocol work.  Thanks for doing such a thorough job on such a foundational document.

Thanks, too, for providing a free alternative to F3411-19.
2021-07-01
16 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2021-06-30
16 Erik Kline
[Ballot comment]
[ _general_ ]

* I know these are industry-standard terms and often appear as quoted text
  but, as a matter of observation, …
[Ballot comment]
[ _general_ ]

* I know these are industry-standard terms and often appear as quoted text
  but, as a matter of observation, it might be good to get in the general
  habit of s/{un}manned/{un}crewed/g wherever feasible.

[S1.2] [nit]

* "needing access to the ...Service or external lookups" ->
  "needing access to the ...Service for external lookups"?

[S4.1.1] [question]

* Vis. GEN-3, given the possibly dynamic nature of Type 3 is the UAS ID
  expected to be unique or is the tuple of {UAS_ID, observation_time} the
  thing that is unique (and therefore the thing to be looked up)?

  Ah, I see ID-4 kinda talks to this issue.
2021-06-30
16 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-06-30
16 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2021-06-29
16 Roman Danyliw
[Ballot discuss]
** Section 6.

It may be inferred from the general requirements (Section 4.1) for
  provable ownership, provable binding, and provable registration,
  …
[Ballot discuss]
** Section 6.

It may be inferred from the general requirements (Section 4.1) for
  provable ownership, provable binding, and provable registration,
  together with the identifier requirements (Section 4.2), that DRIP
  must provide:

  *  message integrity

  *  non-repudiation

  *  defense against replay attacks

  *  defense against spoofing

Thanks for enumerating these highly desirable security properties as part of DRIP.  A bit more clarifying language is needed to explain which communication paths in the DRIP architecture (Figure 3 and 4) have these properties and under what circumstances.  Section 4.1 and 4.2 seem specific to properties between particular parties or messages.  Likewise, subsequent text in this section such as “… there may be caveats on the extent to which requirements can be satisfied …” seems to suggest these are not universal across the architecture.
2021-06-29
16 Roman Danyliw
[Ballot comment]
Thank you to Linda Dunbar for the SECDIR review.

** Abstract. 
Complementing external technical standards as regulator-accepted
  means of compliance with UAS …
[Ballot comment]
Thank you to Linda Dunbar for the SECDIR review.

** Abstract. 
Complementing external technical standards as regulator-accepted
  means of compliance with UAS RID regulations ...
I had trouble parsing this sentence.  Is it saying that DRIP is a complementing way to comply with UAS RID regulations?  Have “regulators” confirmed that  compliance with DRIP satisfies “UAS RID regulations”

** Section 1.1.  Is there a reference for IEEE 802.11 Beacon modes?

** Section 1.1.  Editorial.
s/to authorities; enable authorities/to authorities; and enable authorities/

** Section 4.1.1.  GEN-2 and GEN-3.  Since the name of the requirement is “provable binding” and “provable registration”, should the corresponding text convey the equivalently strong language.  For example:

GEN-2
s/MUST enable binding all/MUST enable the cryptographic binding of all/

GEN-3
s/MUST enable verification/MUST enable cryptographically-secure verification/

** Section 4.1.1.  Per Gen-6, it would be helpful to more clearly state the pair wise communications that will be secured.

** Section 4.2.2.  Per “In Network RID, it would be used by the application running over HTTPS (and possibly other protocols)”, to be clear, is HTTPS a requirement?

** Section 4.3.1. Is there a clear definition somewhere of (a) private information; and (b) safety critical information?

** Section 4.3.1.  PRIV-2.

DRIP MUST NOT encrypt safety critical data to be
          transmitted over Broadcast RID in any situation where it is
          unlikely that local Observers authorized to access the
          plaintext will be able to decrypt it or obtain it from a
          service able to decrypt it.

How would DRIP “know” that the local Observers are unlikely to be to be able to decrypt the information?

** Section 4.4.1.  REG-2 makes a point of enforcing AAA but REG-1 explicitly states “MUST NOT restrict access to this information based on identity or role of the party submitting the query”.  Would this normative MUST per REG-1 rule out denial of service mitigation (e.g., rate limited high volume queries from an IP address) or attempts to scrape the entire database?

** Section 4.4.1.  REG-3.  What is “Internet direct contact information”?
2021-06-29
16 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2021-06-29
16 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-06-28
16 Stuart Card New version available: draft-ietf-drip-reqs-16.txt
2021-06-28
16 (System) New version approved
2021-06-28
16 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card
2021-06-28
16 Stuart Card Uploaded new revision
2021-06-25
15 Mohamed Boucadair
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
  …
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
 

  The Responsible Area Director is Eric Vyncke

(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
2021-06-25
15 Stuart Card New version available: draft-ietf-drip-reqs-15.txt
2021-06-25
15 (System) New version approved
2021-06-25
15 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card
2021-06-25
15 Stuart Card Uploaded new revision
2021-06-25
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-06-25
14 Stuart Card New version available: draft-ietf-drip-reqs-14.txt
2021-06-25
14 (System) New version approved
2021-06-25
14 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card
2021-06-25
14 Stuart Card Uploaded new revision
2021-06-23
13 Suresh Krishnan Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Suresh Krishnan. Sent review to list.
2021-06-14
13 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2021-06-14
13 Éric Vyncke Placed on agenda for telechat - 2021-07-01
2021-06-14
13 Éric Vyncke Ballot has been issued
2021-06-14
13 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2021-06-14
13 Éric Vyncke Created "Approve" ballot
2021-06-14
13 (System) Changed action holders to Éric Vyncke (IESG state changed)
2021-06-14
13 Éric Vyncke IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2021-06-14
13 Éric Vyncke Ballot writeup was changed
2021-06-14
13 Mohamed Boucadair
Shepherd write-up for draft-ietf-drip-reqs-09

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
  …
Shepherd write-up for draft-ietf-drip-reqs-09

(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
 

  The Responsible Area Director is Eric Vyncke

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

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:

  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
2021-06-14
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-06-14
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2021-06-14
13 Stuart Card New version available: draft-ietf-drip-reqs-13.txt
2021-06-14
13 (System) New version accepted (logged-in submitter: Stuart Card)
2021-06-14
13 Stuart Card Uploaded new revision
2021-06-07
12 Nagendra Nainar Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Nagendra Nainar. Sent review to list.
2021-06-07
12 Éric Vyncke To address the security directorate comment in Last Call
2021-06-07
12 (System) Changed action holders to Éric Vyncke, Andrei Gurtov, Robert Moskowitz, Stuart Card, Adam Wiethuechter (IESG state changed)
2021-06-07
12 Éric Vyncke IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2021-06-07
12 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-06-04
12 Linda Dunbar Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Linda Dunbar. Sent review to list.
2021-06-03
12 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2021-06-03
12 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-drip-reqs-12, which is currently in Last Call, and has the following comments:

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

The IANA Functions Operator has reviewed draft-ietf-drip-reqs-12, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-05-27
12 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2021-05-27
12 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2021-05-27
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2021-05-27
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2021-05-26
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2021-05-26
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2021-05-24
12 Mohamed Boucadair
Shepherd write-up for draft-ietf-drip-reqs-09

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
  …
Shepherd write-up for draft-ietf-drip-reqs-09

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

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
 

  The Responsible Area Director is Eric Vyncke

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

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:

  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
2021-05-24
12 Amy Vezza IANA Review state changed to IANA - Review Needed
2021-05-24
12 Amy Vezza
The following Last Call announcement was sent out (ends 2021-06-07):

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

From: The IESG
To: IETF-Announce
CC: draft-ietf-drip-reqs@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:  (Drone Remote Identification Protocol (DRIP) Requirements) to Informational RFC


The IESG has received a request from the Drone Remote ID Protocol WG (drip)
to consider the following document: - 'Drone Remote Identification Protocol
(DRIP) Requirements'
  as Informational RFC

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 2021-06-07. 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


  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 (e.g., initiation of
  identity based network sessions supporting UAS applications).
  Complementing external technical standards as regulator-accepted
  means of compliance with UAS RID regulations, DRIP will facilitate
  use of existing Internet resources to support RID and to enable
  enhanced related services, and will enable online and offline
  verification that RID information is trustworthy.




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



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




2021-05-24
12 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-05-24
12 Amy Vezza Last call announcement was changed
2021-05-23
12 Éric Vyncke Last call was requested
2021-05-23
12 (System) Changed action holders to Éric Vyncke (IESG state changed)
2021-05-23
12 Éric Vyncke IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-05-23
12 Éric Vyncke Last call announcement was generated
2021-05-23
12 Éric Vyncke Ballot writeup was changed
2021-05-23
12 Éric Vyncke Ballot approval text was generated
2021-05-23
12 Stuart Card New version available: draft-ietf-drip-reqs-12.txt
2021-05-23
12 (System) New version accepted (logged-in submitter: Stuart Card)
2021-05-23
12 Stuart Card Uploaded new revision
2021-05-11
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-05-11
11 Stuart Card New version available: draft-ietf-drip-reqs-11.txt
2021-05-11
11 (System) New version approved
2021-05-11
11 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card
2021-05-11
11 Stuart Card Uploaded new revision
2021-05-03
10 Éric Vyncke A reply to the AD review of the numbered requirements (and possibly a revised I-D) is still required.

-éric
2021-05-03
10 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2021-04-27
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-04-27
10 Stuart Card New version available: draft-ietf-drip-reqs-10.txt
2021-04-27
10 (System) New version approved
2021-04-27
10 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card
2021-04-27
10 Stuart Card Uploaded new revision
2021-03-08
09 Éric Vyncke After the responsible AD review: https://mailarchive.ietf.org/arch/msg/tm-rid/7Q6H_UAG1fbjMViuZwT9LpOoXBA/
2021-03-08
09 (System) Changed action holders to Andrei Gurtov, Robert Moskowitz, Stuart Card, Adam Wiethuechter (IESG state changed)
2021-03-08
09 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-02-18
09 Éric Vyncke Changed consensus to Yes from Unknown
2021-02-18
09 Éric Vyncke Shepherd write up is correct. Let's move to the next step: AD review
2021-02-18
09 Éric Vyncke IESG state changed to AD Evaluation from Publication Requested
2021-02-18
09 Mohamed Boucadair
Shepherd write-up for draft-ietf-drip-reqs-09

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
  …
Shepherd write-up for draft-ietf-drip-reqs-09

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

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

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
 

  The Responsible Area Director is Eric Vyncke

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

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:

  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
2021-02-17
09 Mohamed Boucadair
Shepherd write-up for draft-ietf-drip-reqs-09

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
  …
Shepherd write-up for draft-ietf-drip-reqs-09

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

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

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
 

  The Responsible Area Director is Eric Vyncke

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

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:

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

(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
2021-02-17
09 Mohamed Boucadair IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-02-17
09 Mohamed Boucadair IESG state changed to Publication Requested from I-D Exists
2021-02-17
09 Mohamed Boucadair IESG process started in state Publication Requested
2021-02-17
09 Mohamed Boucadair Tag Doc Shepherd Follow-up Underway cleared.
2021-02-17
09 Mohamed Boucadair
Shepherd write-up for draft-ietf-drip-reqs-09

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
  …
Shepherd write-up for draft-ietf-drip-reqs-09

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

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

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
 

  The Responsible Area Director is Eric Vyncke

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

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:

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

(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
2021-02-17
09 Stuart Card New version available: draft-ietf-drip-reqs-09.txt
2021-02-17
09 (System) New version accepted (logged-in submitter: Stuart Card)
2021-02-17
09 Stuart Card Uploaded new revision
2021-02-17
08 Mohamed Boucadair
Shepherd write-up for draft-ietf-drip-reqs-08

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
  …
Shepherd write-up for draft-ietf-drip-reqs-08

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

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

  The document is largely based on the process in one specific region.
  The WG discussed that issue, but agreed to progress the work based
  on available inputs/volunteers as any outer IETF effort. Also, the
  WG agreed to record this issue in Appendix A "Discussion
  and Limitations". Some pointers to relevant documents in regions
  such as the EU were also added to the document. 

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
 

  The Responsible Area Director is Eric Vyncke

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

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:

  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
2021-02-16
08 Mohamed Boucadair
Shepherd write-up for draft-ietf-drip-reqs-08

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
  …
Shepherd write-up for draft-ietf-drip-reqs-08

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

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

  The document is largely based on the process in one specific region.
  The WG discussed that issue, but agreed to progress the work based
  on available inputs/volunteers as any outer IETF effort. Also, the
  WG agreed to record this issue in Appendix A "Discussion
  and Limitations". Some pointers to relevant documents in regions
  such as the EU were also added to the document. 

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
 

  The Responsible Area Director is Eric Vyncke

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

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:

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

(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
2021-02-16
08 Stuart Card New version available: draft-ietf-drip-reqs-08.txt
2021-02-16
08 (System) New version accepted (logged-in submitter: Stuart Card)
2021-02-16
08 Stuart Card Uploaded new revision
2021-02-16
07 Mohamed Boucadair
Shepherd write-up for draft-ietf-drip-reqs-07

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
  …
Shepherd write-up for draft-ietf-drip-reqs-07

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

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

  Some requirements may be region-specific.  The WG discussed that
  issue, but agreed to progress the work based on available inputs/
  volunteers.  Also, the WG agreed to record this issue in Appendix A
  "Discussion and Limitations".

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
 

  The Responsible Area Director is Eric Vyncke

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

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:

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

(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
2021-02-15
07 Stuart Card New version available: draft-ietf-drip-reqs-07.txt
2021-02-15
07 (System) New version accepted (logged-in submitter: Stuart Card)
2021-02-15
07 Stuart Card Uploaded new revision
2020-11-18
06 Mohamed Boucadair Notification list changed to tm-rid@ietf.org, mohamed.boucadair@orange.com from tm-rid@ietf.org because the document shepherd was set
2020-11-18
06 Mohamed Boucadair Document shepherd changed to Mohamed Boucadair
2020-11-18
06 Mohamed Boucadair Notification list changed to tm-rid@ietf.org
2020-11-17
06 Mohamed Boucadair Tag Doc Shepherd Follow-up Underway set.
2020-11-17
06 Mohamed Boucadair IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2020-11-03
06 Mohamed Boucadair 2nd WGLC, ends 17/11/2020
2020-11-01
06 Stuart Card New version available: draft-ietf-drip-reqs-06.txt
2020-11-01
06 (System) New version accepted (logged-in submitter: Stuart Card)
2020-11-01
06 Stuart Card Uploaded new revision
2020-10-27
05 Mohamed Boucadair Added to session: interim-2020-drip-07
2020-10-16
05 Stuart Card New version available: draft-ietf-drip-reqs-05.txt
2020-10-16
05 (System) New version approved
2020-10-16
05 (System) Request for posting confirmation emailed to previous authors: Adam Wiethuechter , Andrei Gurtov , Robert Moskowitz , Stuart Card
2020-10-16
05 Stuart Card Uploaded new revision
2020-09-09
04 Mohamed Boucadair Intended Status changed to Informational from None
2020-09-08
04 Mohamed Boucadair IETF WG state changed to In WG Last Call from WG Document
2020-08-25
04 Stuart Card New version available: draft-ietf-drip-reqs-04.txt
2020-08-25
04 (System) New version approved
2020-08-25
04 (System) Request for posting confirmation emailed to previous authors: Stuart Card , Robert Moskowitz , Andrei Gurtov , Adam Wiethuechter
2020-08-25
04 Stuart Card Uploaded new revision
2020-08-05
03 Mohamed Boucadair Added to session: interim-2020-drip-05
2020-07-15
03 Mohamed Boucadair Added to session: IETF-108: drip  Thu-1410
2020-07-13
03 Stuart Card New version available: draft-ietf-drip-reqs-03.txt
2020-07-13
03 (System) New version approved
2020-07-13
03 (System) Request for posting confirmation emailed to previous authors: Robert Moskowitz , Stuart Card , Adam Wiethuechter , Andrei Gurtov
2020-07-13
03 Stuart Card Uploaded new revision
2020-07-13
02 Stuart Card New version available: draft-ietf-drip-reqs-02.txt
2020-07-13
02 (System) New version approved
2020-07-13
02 (System) Request for posting confirmation emailed to previous authors: Robert Moskowitz , Adam Wiethuechter , Stuart Card , Andrei Gurtov
2020-07-13
02 Stuart Card Uploaded new revision
2020-06-23
01 Mohamed Boucadair Added to session: interim-2020-drip-03
2020-05-25
01 Mohamed Boucadair Added to session: interim-2020-drip-02
2020-05-25
01 Stuart Card New version available: draft-ietf-drip-reqs-01.txt
2020-05-25
01 (System) New version approved
2020-05-25
01 (System) Request for posting confirmation emailed to previous authors: drip-chairs@ietf.org, Robert Moskowitz , Stuart Card , Adam Wiethuechter
2020-05-25
01 Stuart Card Uploaded new revision
2020-05-22
00 Éric Vyncke Shepherding AD changed to Éric Vyncke
2020-05-18
00 (System) This document now replaces draft-card-drip-reqs instead of None
2020-05-18
00 Stuart Card New version available: draft-ietf-drip-reqs-00.txt
2020-05-18
00 (System) New version approved
2020-05-18
00 Stuart Card Request for posting confirmation emailed  to submitter and authors: Stuart Card , Adam Wiethuechter , Robert Moskowitz
2020-05-18
00 Stuart Card Uploaded new revision