Skip to main content

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