Poll-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-poll-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-11-30
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-10-12
|
12 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-07-30
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-07-02
|
12 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2020-07-02
|
12 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Melinda Shore was marked no-response |
2020-07-01
|
12 | (System) | IANA Action state changed to No IANA Actions |
2020-06-30
|
12 | (System) | RFC Editor state changed to EDIT |
2020-06-30
|
12 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-06-30
|
12 | (System) | Announcement was received by RFC Editor |
2020-06-29
|
12 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-06-29
|
12 | Cindy Morgan | IESG has approved the document |
2020-06-29
|
12 | Cindy Morgan | Closed "Approve" ballot |
2020-06-29
|
12 | Cindy Morgan | Ballot approval text was generated |
2020-06-25
|
12 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2020-06-25
|
12 | Martin Duke | Ballot comment text updated for Martin Duke |
2020-06-25
|
12 | Michelle Cotton | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2020-06-25
|
12 | Roman Danyliw | [Ballot comment] Thanks for addressing all of my COMMENTs. |
2020-06-25
|
12 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2020-06-24
|
12 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-06-24
|
12 | Michael Jones | New version available: draft-ietf-secevent-http-poll-12.txt |
2020-06-24
|
12 | (System) | New version approved |
2020-06-24
|
12 | (System) | Request for posting confirmation emailed to previous authors: Anthony Nadalin , Marius Scurtescu , Morteza Ansari , Michael Jones , Annabelle Backman |
2020-06-24
|
12 | Michael Jones | Uploaded new revision |
2020-06-24
|
11 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-06-24
|
11 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-06-24
|
11 | Barry Leiba | [Ballot comment] — Section 1 — Section 1 of the push draft explains that push is meant to be used under specific circumstances. Is it … [Ballot comment] — Section 1 — Section 1 of the push draft explains that push is meant to be used under specific circumstances. Is it the intent that push be used for those cases, and pull be used for everything else? It might be good to say that explicitly here, perhaps as, “This is an alternative SET delivery method to the one defined in [I-D.ietf-secevent-http-push], and is used for cases where push-based delivery does not apply.” — Section 2 — The SET Recipient MUST acknowledge receipt to the SET Transmitter, and SHOULD do in a timely fashion Nit: “SHOULD do so” — Section 2.1 — Before acknowledgement, SET Recipients SHOULD ensure that received SETs have been validated Same comment as in -push: validation is a SHALL, and this says SHOULD. But see my comment below for Section 2.4. — Section 2.2 — maxEvents An OPTIONAL JSON integer value indicating the maximum number of unacknowledged SETs that SHOULD be returned. The antecedent to SHOULD is unclear. Are you really saying that the SETs SHOULD be returned? Or do you mean that the SHOULD applies to the maximum number? Assuming the latter, it’s better said this way: NEW maxEvents An OPTIONAL JSON integer value indicating the maximum number of unacknowledged SETs to be returned. The SET Transmitter SHOULD NOT send more SETs than the specified maximum. END Recipients that would like to perform an acknowledge only request. Nit: hyphenate “acknowledge-only” — Section 2.4 — If the SET Recipient has received SETs from the SET Transmitter, the SET Recipient SHOULD parse and validate received SETs Is it intended that validation is a SHALL in push and a SHOULD in pull? If so, why? Is it worth explaining that in the documents? — Section 3 — The TLS server certificate MUST be validated, per [RFC6125]. Same comment as in -push: what about DANE? (Also for Section 4.3) |
2020-06-24
|
11 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-06-24
|
11 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-06-24
|
11 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2020-06-23
|
11 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-06-23
|
11 | Yaron Sheffer | This document now replaces draft-ietf-secevent-delivery instead of None |
2020-06-23
|
11 | Alvaro Retana | [Ballot comment] This document (and draft-ietf-secevent-http-push) should be tagged as replacing draft-ietf-secevent-delivery. |
2020-06-23
|
11 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2020-06-23
|
11 | Roman Danyliw | [Ballot comment] ** Section 2.2. Per the ack array, is it fair to assume that an empty array is ignored? ** Section 2.4. Per “After … [Ballot comment] ** Section 2.2. Per the ack array, is it fair to assume that an empty array is ignored? ** Section 2.4. Per “After a period of time configured between the SET Transmitter and Recipient, …”, is that configuration out of band/scope for this specification? ** Section 2.4.1. Figure 1. All of the other figures seem to explicitly state that this is a non-normative example. s/The following is an example request/The following is a non-normative example of a request/. ** Section 4.3. This section is identical to Section 5.3 of draft-ietf-secevent-http-push. Please review the recommended clarifications mentioned there -- https://mailarchive.ietf.org/arch/msg/id-event/9h4_z8S-JyMMCbrdW6V7b_YmGbI/ |
2020-06-23
|
11 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-06-23
|
11 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. It is easy to read. I have a non-blocking question about section 2.2: for … [Ballot comment] Thank you for the work put into this document. It is easy to read. I have a non-blocking question about section 2.2: for constrained devices, it would probably be useful to also set a maxSize (in bytes) for the returned SET(s). Was this considered ? Regards -éric |
2020-06-23
|
11 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-06-23
|
11 | Erik Kline | [Ballot comment] [[ questions ]] [ section 2.4.2 ] * What should happen with an ACK-only request that has maxEvents: 0 and returnImmediately: false? … [Ballot comment] [[ questions ]] [ section 2.4.2 ] * What should happen with an ACK-only request that has maxEvents: 0 and returnImmediately: false? Should the default value of returnImmediately be !maxEvents? |
2020-06-23
|
11 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2020-06-22
|
11 | Robert Sparks | Request for Telechat review by GENART Completed: Ready. Reviewer: Robert Sparks. Sent review to list. |
2020-06-22
|
11 | Robert Wilton | [Ballot comment] Hi, I found that document easy to read/understand (despite not really knowing what "SET"s are). However, I did have a query about the … [Ballot comment] Hi, I found that document easy to read/understand (despite not really knowing what "SET"s are). However, I did have a query about the algorithm: It seems to me that if a client fails to acknowledge a SET (e.g. due to a bug, or perhaps a message is lost) then it has to wait until the server times out waiting for the SET acknowledgement before the server hopefully resends it. However, I would normally expect that a client should automatically acknowledge all SETs in the order that it receives them because it doesn't seem to have a good reason not to do so. Hence, I was wondering whether it would be useful to have an option to allow clients to request that the next "maxEvents" SETs also include any unacknowledged SETs? This would allow clients to potentially recover lost SETs more quickly and more robustly? I.e. for the case where a client expects to acknowledge all existing received SETs before/when requesting more. Regards, Rob |
2020-06-22
|
11 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-06-19
|
11 | Martin Duke | [Ballot comment] Please add an informative reference to RFC7519 on first use of “jti”. |
2020-06-19
|
11 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-06-18
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
2020-06-18
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
2020-06-18
|
11 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2020-06-17
|
11 | Benjamin Kaduk | IESG state changed to IESG Evaluation from Waiting for Writeup |
2020-06-17
|
11 | Murray Kucherawy | [Ballot comment] A couple of questions arise for me about the use of requirements language: Section 2.1: * Under what circumstances would you not follow … [Ballot comment] A couple of questions arise for me about the use of requirements language: Section 2.1: * Under what circumstances would you not follow the advice of that SHOULD? Section 2.2: * "... the oldest SETs available SHOULD be returned first." -- why is that only a SHOULD? Section 2.4: * "... SHOULD parse and validate received SETs to meet its own requirements ..." -- when would you not do this? And a nit: Section 2.2: * "An OPTIONAL JSON integer value ..." -- JSON defines "number", not "integer"; I understand what you mean, but that distinction has drawn complaints on previous documents. |
2020-06-17
|
11 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-06-17
|
11 | Cindy Morgan | Placed on agenda for telechat - 2020-06-25 |
2020-06-16
|
11 | Benjamin Kaduk | [Ballot comment] Prompted by Mark Notthingham's comments, we should perhaps leave some breadcrumbs that -push has discussion of alternatives considered and rejected, though this is … [Ballot comment] Prompted by Mark Notthingham's comments, we should perhaps leave some breadcrumbs that -push has discussion of alternatives considered and rejected, though this is less important if that section is to be removed prior to publication as an RFC. It may be worth mentioning explicitly in Section 1 that one of the pieces of configuration metadata to be exchanged includes the authentication/authorization information for the Recipient, or to discuss Recipient authentication/authorization in Section 3 where server (i.e., Transmitter) authentication is covered. When we reference RFC 6125, we only mention the DNS-ID name type in Section 4.3 but not in Section 3. As for -push, we don't necessarily need to mention it in both places, but it might be nice to be consistent or to remove some of the redundancy. Section 5 As for -push, I think both SET Issuers and Transmitters (not just one or the other) should consider the ramifications of sharing a particular SET. While it's true that (as the secdir reviewer of -push noted) when JWE is used the Issuer has sole knowledge/control, but in other cases the Issuer may not know the full recipient list. |
2020-06-16
|
11 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2020-06-16
|
11 | Benjamin Kaduk | Ballot has been issued |
2020-06-16
|
11 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2020-06-16
|
11 | Benjamin Kaduk | Created "Approve" ballot |
2020-06-16
|
11 | Benjamin Kaduk | Ballot writeup was changed |
2020-06-15
|
11 | Michael Jones | New version available: draft-ietf-secevent-http-poll-11.txt |
2020-06-15
|
11 | (System) | New version approved |
2020-06-15
|
11 | (System) | Request for posting confirmation emailed to previous authors: Marius Scurtescu , Annabelle Backman , Morteza Ansari , Michael Jones , Anthony Nadalin |
2020-06-15
|
11 | Michael Jones | Uploaded new revision |
2020-06-05
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2020-06-05
|
10 | Michael Jones | New version available: draft-ietf-secevent-http-poll-10.txt |
2020-06-05
|
10 | (System) | New version approved |
2020-06-05
|
10 | (System) | Request for posting confirmation emailed to previous authors: Michael Jones , Marius Scurtescu , Morteza Ansari , Annabelle Backman , Anthony Nadalin |
2020-06-05
|
10 | Michael Jones | Uploaded new revision |
2020-05-13
|
09 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2020-05-13
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-secevent-http-poll-09, 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-secevent-http-poll-09, 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 |
2020-05-13
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-05-08
|
09 | Robert Sparks | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Robert Sparks. Sent review to list. |
2020-05-04
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2020-05-04
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Fred Baker |
2020-04-30
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2020-04-30
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2020-04-30
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2020-04-30
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2020-04-29
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-04-29
|
09 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-05-13): From: The IESG To: IETF-Announce CC: Yaron Sheffer , yaronf.ietf@gmail.com, id-event@ietf.org, kaduk@mit.edu, … The following Last Call announcement was sent out (ends 2020-05-13): From: The IESG To: IETF-Announce CC: Yaron Sheffer , yaronf.ietf@gmail.com, id-event@ietf.org, kaduk@mit.edu, draft-ietf-secevent-http-poll@ietf.org, secevent-chairs@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Poll-Based Security Event Token (SET) Delivery Using HTTP) to Proposed Standard The IESG has received a request from the Security Events WG (secevent) to consider the following document: - 'Poll-Based Security Event Token (SET) Delivery Using HTTP' as Proposed Standard 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 2020-05-13. 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 specification defines how a series of Security Event Tokens (SETs) may be delivered to an intended recipient using HTTP POST over TLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient's need for assurance. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-secevent-http-poll/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-secevent-http-poll/ballot/ No IPR declarations have been submitted directly on this I-D. |
2020-04-29
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-04-29
|
09 | Benjamin Kaduk | Last call was requested |
2020-04-29
|
09 | Benjamin Kaduk | Last call announcement was generated |
2020-04-29
|
09 | Benjamin Kaduk | Ballot approval text was generated |
2020-04-29
|
09 | Benjamin Kaduk | Ballot writeup was generated |
2020-04-29
|
09 | Benjamin Kaduk | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-04-29
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-04-29
|
09 | Annabelle Backman | New version available: draft-ietf-secevent-http-poll-09.txt |
2020-04-29
|
09 | (System) | New version accepted (logged-in submitter: Annabelle Backman) |
2020-04-29
|
09 | Annabelle Backman | Uploaded new revision |
2020-04-24
|
08 | Benjamin Kaduk | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2020-02-07
|
08 | Michael Jones | New version available: draft-ietf-secevent-http-poll-08.txt |
2020-02-07
|
08 | (System) | New version approved |
2020-02-07
|
08 | (System) | Request for posting confirmation emailed to previous authors: Anthony Nadalin , Marius Scurtescu , Morteza Ansari , Michael Jones , Annabelle Backman |
2020-02-07
|
08 | Michael Jones | Uploaded new revision |
2020-02-06
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-02-06
|
07 | Michael Jones | New version available: draft-ietf-secevent-http-poll-07.txt |
2020-02-06
|
07 | (System) | New version approved |
2020-02-06
|
07 | (System) | Request for posting confirmation emailed to previous authors: Anthony Nadalin , Marius Scurtescu , Morteza Ansari , Michael Jones , Annabelle Backman |
2020-02-06
|
07 | Michael Jones | Uploaded new revision |
2019-12-10
|
06 | Benjamin Kaduk | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2019-12-10
|
06 | Benjamin Kaduk | IESG state changed to AD Evaluation from Publication Requested |
2019-11-19
|
06 | Yaron Sheffer | ## What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard. This is a normative WG document, … ## What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard. This is a normative WG document, and this is the proper type. ## The IESG approval announcement includes a Document Announcement Write-Up. ### Technical Summary: This document defines a poll-based HTTP transport for SETs (security events) which are specified in RFC 8417. The document defines transport using HTTP POST and TLS, as well as optional assurance for such delivery. ### Working Group Summary There is WG consensus for publishing this document, and no ocntroversy. ### Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Implementations: Microsoft has the protocol running in production. No noteworthy reviews, and no special expertise required, beyond the working group's core expertise. ## Personnel Yaron Sheffer is the document shepherd. Ben Kaduk is the responsible AD. ## Briefly describe the review of this document that was performed by the Document Shepherd. I reviewed this document again and my comments were fully addressed by a new revision. I believe the document is now ready for publication. ## Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I do not have such concerns. ## Do portions of the document need review from a particular or from broader perspective? No such reviews. ## 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? The document is ready and the protocol addresses a real need expressed by WG constituents. It should be noted that the WG consciously decided to publish two alternative transports for SETs using HTTP Push and Poll, and this is one of them. ## 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. If not, explain why? Yes. ## Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures. ## How solid is the WG consensus behind this document? Full consensus, though this is a relatively small community. ## Has anyone threatened an appeal or otherwise indicated extreme discontent? No. ## Identify any ID nits the Document Shepherd has found in this document. I have checked for I-D nits and no such nits remain, other than a reference to an obsolete RFC (TLS 1.2, RFC 5246) which is appropriate in this context. ## Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A. ## Have all references within this document been identified as either normative or informative? Yes. ## 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? There is a normative reference to a companion "push" document which is being published concurrently. ## Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. As noted above, RFC 5246 (TLS 1.2). ## Will publication of this document change the status of any existing RFCs? No. ## Describe the Document Shepherd's review of the IANA considerations section The document requires no IANA actions. It does depend on an error code registry, defined in the "push" document. ## List any new IANA registries that require Expert Review for future allocations. N/A. ## Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. N/A. ## If the document contains a YANG module... N/A. |
2019-11-19
|
06 | Yaron Sheffer | Responsible AD changed to Benjamin Kaduk |
2019-11-19
|
06 | Yaron Sheffer | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-11-19
|
06 | Yaron Sheffer | IESG state changed to Publication Requested from I-D Exists |
2019-11-19
|
06 | Yaron Sheffer | IESG process started in state Publication Requested |
2019-11-19
|
06 | Yaron Sheffer | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2019-11-19
|
06 | Yaron Sheffer | ## What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard. This is a normative WG document, … ## What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Proposed standard. This is a normative WG document, and this is the proper type. ## The IESG approval announcement includes a Document Announcement Write-Up. ### Technical Summary: This document defines a poll-based HTTP transport for SETs (security events) which are specified in RFC 8417. The document defines transport using HTTP POST and TLS, as well as optional assurance for such delivery. ### Working Group Summary There is WG consensus for publishing this document, and no ocntroversy. ### Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Implementations: Microsoft has the protocol running in production. No noteworthy reviews, and no special expertise required, beyond the working group's core expertise. ## Personnel Yaron Sheffer is the document shepherd. Ben Kaduk is the responsible AD. ## Briefly describe the review of this document that was performed by the Document Shepherd. I reviewed this document again and my comments were fully addressed by a new revision. I believe the document is now ready for publication. ## Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I do not have such concerns. ## Do portions of the document need review from a particular or from broader perspective? No such reviews. ## 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? The document is ready and the protocol addresses a real need expressed by WG constituents. It should be noted that the WG consciously decided to publish two alternative transports for SETs using HTTP Push and Poll, and this is one of them. ## 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. If not, explain why? Yes. ## Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures. ## How solid is the WG consensus behind this document? Full consensus, though this is a relatively small community. ## Has anyone threatened an appeal or otherwise indicated extreme discontent? No. ## Identify any ID nits the Document Shepherd has found in this document. I have checked for I-D nits and no such nits remain, other than a reference to an obsolete RFC (TLS 1.2, RFC 5246) which is appropriate in this context. ## Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A. ## Have all references within this document been identified as either normative or informative? Yes. ## 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? There is a normative reference to a companion "push" document which is being published concurrently. ## Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. As noted above, RFC 5246 (TLS 1.2). ## Will publication of this document change the status of any existing RFCs? No. ## Describe the Document Shepherd's review of the IANA considerations section The document requires no IANA actions. It does depend on an error code registry, defined in the "push" document. ## List any new IANA registries that require Expert Review for future allocations. N/A. ## Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language. N/A. ## If the document contains a YANG module... N/A. |
2019-11-19
|
06 | Yaron Sheffer | Notification list changed to Yaron Sheffer <yaronf.ietf@gmail.com> |
2019-11-19
|
06 | Yaron Sheffer | Document shepherd changed to Yaron Sheffer |
2019-11-19
|
06 | Michael Jones | New version available: draft-ietf-secevent-http-poll-06.txt |
2019-11-19
|
06 | (System) | New version approved |
2019-11-19
|
06 | (System) | Request for posting confirmation emailed to previous authors: Anthony Nadalin , Marius Scurtescu , Morteza Ansari , Michael Jones , Annabelle Backman |
2019-11-19
|
06 | Michael Jones | Uploaded new revision |
2019-11-17
|
05 | Michael Jones | New version available: draft-ietf-secevent-http-poll-05.txt |
2019-11-17
|
05 | (System) | New version approved |
2019-11-17
|
05 | (System) | Request for posting confirmation emailed to previous authors: Anthony Nadalin , Marius Scurtescu , Morteza Ansari , Michael Jones , Annabelle Backman |
2019-11-17
|
05 | Michael Jones | Uploaded new revision |
2019-11-01
|
04 | Michael Jones | New version available: draft-ietf-secevent-http-poll-04.txt |
2019-11-01
|
04 | (System) | New version approved |
2019-11-01
|
04 | (System) | Request for posting confirmation emailed to previous authors: Anthony Nadalin , Marius Scurtescu , Morteza Ansari , Michael Jones , Annabelle Backman |
2019-11-01
|
04 | Michael Jones | Uploaded new revision |
2019-09-06
|
03 | Yaron Sheffer | Tag Revised I-D Needed - Issue raised by WGLC set. |
2019-09-06
|
03 | Yaron Sheffer | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2019-08-07
|
03 | Yaron Sheffer | IETF WG state changed to In WG Last Call from WG Document |
2019-08-07
|
03 | Yaron Sheffer | Changed consensus to Yes from Unknown |
2019-08-07
|
03 | Yaron Sheffer | Intended Status changed to Proposed Standard from None |
2019-07-23
|
03 | Dick Hardt | Added to session: IETF-105: secevent Tue-1330 |
2019-07-08
|
03 | Michael Jones | New version available: draft-ietf-secevent-http-poll-03.txt |
2019-07-08
|
03 | (System) | New version approved |
2019-07-08
|
03 | (System) | Request for posting confirmation emailed to previous authors: Anthony Nadalin , Marius Scurtescu , Morteza Ansari , Michael Jones , Annabelle Backman |
2019-07-08
|
03 | Michael Jones | Uploaded new revision |
2019-03-24
|
02 | Yaron Sheffer | Added to session: IETF-104: secevent Wed-0900 |
2019-03-10
|
02 | Michael Jones | New version available: draft-ietf-secevent-http-poll-02.txt |
2019-03-10
|
02 | (System) | New version approved |
2019-03-10
|
02 | (System) | Request for posting confirmation emailed to previous authors: Anthony Nadalin , Marius Scurtescu , Morteza Ansari , Michael Jones , Annabelle Backman |
2019-03-10
|
02 | Michael Jones | Uploaded new revision |
2018-11-06
|
01 | Yaron Sheffer | Added to session: IETF-103: secevent Wed-0900 |
2018-10-22
|
01 | Michael Jones | New version available: draft-ietf-secevent-http-poll-01.txt |
2018-10-22
|
01 | (System) | New version approved |
2018-10-22
|
01 | (System) | Request for posting confirmation emailed to previous authors: Phil Hunt , Anthony Nadalin , Morteza Ansari , Annabelle Backman , secevent-chairs@ietf.org, Michael Jones , … Request for posting confirmation emailed to previous authors: Phil Hunt , Anthony Nadalin , Morteza Ansari , Annabelle Backman , secevent-chairs@ietf.org, Michael Jones , Marius Scurtescu |
2018-10-22
|
01 | Michael Jones | Uploaded new revision |
2018-10-18
|
00 | (System) | Document has expired |
2018-07-06
|
00 | Yaron Sheffer | Added to session: IETF-102: secevent Fri-0930 |
2018-04-16
|
00 | Annabelle Backman | New version available: draft-ietf-secevent-http-poll-00.txt |
2018-04-16
|
00 | (System) | WG -00 approved |
2018-04-16
|
00 | Annabelle Backman | Set submitter to "Annabelle Backman ", replaces to (none) and sent approval email to group chairs: secevent-chairs@ietf.org |
2018-04-16
|
00 | Annabelle Backman | Uploaded new revision |