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 |