draft-ietf-secevent-delivery-00.txt   draft-ietf-secevent-delivery-01.txt 
Network Working Group P. Hunt, Ed. Network Working Group P. Hunt, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track M. Scurtescu Intended status: Standards Track M. Scurtescu
Expires: January 29, 2018 Google Expires: May 1, 2018 Google
M. Ansari M. Ansari
Cisco Cisco
A. Nadalin A. Nadalin
Microsoft Microsoft
A. Backman A. Backman
Amazon Amazon
July 28, 2017 October 28, 2017
SET Token Delivery Using HTTP SET Token Delivery Using HTTP
draft-ietf-secevent-delivery-00 draft-ietf-secevent-delivery-01
Abstract Abstract
This specification defines how a series of security event tokens This specification defines how a series of security event tokens
(SETs) may be delivered to a previously registered receiver using (SETs) may be delivered to a previously registered receiver using
HTTP POST over TLS initiated as a push to the receiver, or as a poll HTTP POST over TLS initiated as a push to the receiver, or as a poll
by the receiver. The specification also defines how delivery can be by the receiver. The specification also defines how delivery can be
assured subject to the SET Token Receiver's need for assurance. assured subject to the SET Token Receiver's need for assurance.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 29, 2018. This Internet-Draft will expire on May 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 26 skipping to change at page 2, line 26
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. SET Event Stream Protocol . . . . . . . . . . . . . . . . . . 5 2. SET Event Stream Protocol . . . . . . . . . . . . . . . . . . 5
2.1. Event Delivery Process . . . . . . . . . . . . . . . . . 5 2.1. Event Delivery Process . . . . . . . . . . . . . . . . . 5
2.2. Push Delivery using HTTP . . . . . . . . . . . . . . . . 6 2.2. Push Delivery using HTTP . . . . . . . . . . . . . . . . 6
2.3. Polling Delivery using HTTP . . . . . . . . . . . . . . . 8 2.3. Polling Delivery using HTTP . . . . . . . . . . . . . . . 8
2.3.1. Polling HTTP Request Attributes . . . . . . . . . . . 9 2.3.1. Polling HTTP Request Attributes . . . . . . . . . . . 9
2.3.2. Polling HTTP Response Attributes . . . . . . . . . . 10 2.3.2. Polling HTTP Response Attributes . . . . . . . . . . 10
2.3.3. Poll Request . . . . . . . . . . . . . . . . . . . . 10 2.3.3. Poll Request . . . . . . . . . . . . . . . . . . . . 10
2.3.4. Poll Response . . . . . . . . . . . . . . . . . . . . 14 2.3.4. Poll Response . . . . . . . . . . . . . . . . . . . . 14
2.4. Error Response Handling . . . . . . . . . . . . . . . . . 16 2.4. Error Response Handling . . . . . . . . . . . . . . . . . 16
2.5. Event Stream Verification . . . . . . . . . . . . . . . . 17 3. Authentication and Authorization . . . . . . . . . . . . . . 17
3. Authentication and Authorization . . . . . . . . . . . . . . 19 3.1. Use of Tokens as Authorizations . . . . . . . . . . . . . 18
3.1. Use of Tokens as Authorizations . . . . . . . . . . . . . 20 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 4.1. Authentication Using Signed SETs . . . . . . . . . . . . 18
4.1. Authentication Using Signed SETs . . . . . . . . . . . . 20 4.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 19
4.2. HTTP Considerations . . . . . . . . . . . . . . . . . . . 20 4.3. TLS Support Considerations . . . . . . . . . . . . . . . 19
4.3. TLS Support Considerations . . . . . . . . . . . . . . . 21 4.4. Authorization Token Considerations . . . . . . . . . . . 19
4.4. Authorization Token Considerations . . . . . . . . . . . 21 4.4.1. Bearer Token Considerations . . . . . . . . . . . . . 19
4.4.1. Bearer Token Considerations . . . . . . . . . . . . . 21 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. Other Streaming Specifications . . . . . . . . . . . 23
Appendix A. Other Streaming Specifications . . . . . . . . . . . 25 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 24
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 24
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction and Overview 1. Introduction and Overview
This specification defines how a stream of SETs (see This specification defines how a stream of SETs (see
[I-D.ietf-secevent-token]) can be transmitted to a previously [I-D.ietf-secevent-token]) can be transmitted to a previously
registered Event Receiver using HTTP [RFC7231] over TLS. The registered Event Receiver using HTTP [RFC7231] over TLS. The
specification defines a method to push SETs via HTTP POST and to poll specification defines a method to push SETs via HTTP POST and to poll
for SETs using HTTP POST. for SETs using HTTP POST.
This specification defines to methods of SET delivery in what is This specification defines to methods of SET delivery in what is
skipping to change at page 17, line 15 skipping to change at page 17, line 15
description description
A human-readable text that provides additional diagnostic A human-readable text that provides additional diagnostic
information. information.
When included as part of an HTTP Status 400 response, the above JSON When included as part of an HTTP Status 400 response, the above JSON
is the HTTP response body (see Figure 3). When included as part of a is the HTTP response body (see Figure 3). When included as part of a
batch of SETs, the above JSON is included as part of the "setErrs" batch of SETs, the above JSON is included as part of the "setErrs"
attribute as defined in Section 2.3.2 and Section 2.3.3.4 attribute as defined in Section 2.3.2 and Section 2.3.3.4
2.5. Event Stream Verification
In the verify process, the Event Receiver organization initiates a
request to the Event Transmitter to verify the Stream. The Event
Receiver provides a "confirm" value and a "nonce" value that the
Event Transmitter is expected to return in the body of a Verify Event
so that the Event Receiver can confirm end-to-end configuration of
SET delivery including proper signing and encryption depending on the
configuration of the Stream. For example, can the Event Transmitter
send a encrypted SET that the Receiver can decode? The method by
which this is initiated is out-of-scope of this specification and MAY
be provided by a profiling specification, or by administrative
interfaces offered by the Event Transmitter.
To confirm an Event Stream configuration, the Event Transmitter SHALL
send a Verify SET to the Event Receiver using the registered
"methodUri" mechanism.
The Verify SET contains the following attributes:
events
Set with a value of "[[this RFC URL]]#verify".
iss
Set to the URI defined in the Event Stream configuration.
aud
MUST be set to a value that matches the EventStream "aud" value
agreed to.
exp
A value that indicates the time the verification request will
expire. Once expired, the server will set the Event Stream state
to "fail".
confirm
The value given by the Event Receiver to the Event Transmitter to
return in the Verify Event.
nonce
A value given by the Event Receiver or otherwise agreed up to
return which SHOULD be unique to the Stream and SHOULD change with
each test in order to distinguish tests uniquely.
If the Event Stream is configured to encrypt SETs for the Event
Receiver, then the SET SHOULD be encrypted with the provided key.
Successful parsing of the message confirms that provides confirmation
of correct configuration and possession of keys.
A non-normative JSON representation of an Event to be sent to a Event
Receiver as a Event Stream confirmation. Note the Event is not yet
encoded as a JWT token:
{
"jti": "4d3559ec67504aaba65d40b0363faad8",
"events":["[[this RFC URL]]#verify"],
"iat": 1458496404,
"iss": "https://scim.example.com",
"exp": 1458497000,
"aud":[
"https://event.example.com/Feeds/98d52461fa5bbc879593b7754"
],
"[[this RFC URL]]#verify":{
"confirm":"ca2179f4-8936-479a-a76d-5486e2baacd7",
"nonce":"1668c993e95849869e4b3506cccdf9bf"
}
}
Figure 11: Example Verification SET with Challenge
The above SET is encoded as a JWT and transmitted to the Event
Receiver using the configured delivery method.
Upon receiving a verify SET, the Event Receiver SHALL parse the SET
and verify its claims. In particular, the Event Receiver SHALL
confirm that the values for "confirm" and "nonce" are as expected.
If they do not match, an error response of "setData" SHOULD be
returned (see Section 2.4).
In many cases, Event Transmitters MAY disable or suspend an Event
Stream that fails to successfully verify based on the acknowledgement
or lack of acknowledgement by the Event Receiver.
3. Authentication and Authorization 3. Authentication and Authorization
The SET delivery methods described in this specification are based The SET delivery methods described in this specification are based
upon HTTP and depend on the use of TLS and/or standard HTTP upon HTTP and depend on the use of TLS and/or standard HTTP
authentication and authorization schemes as per [RFC7235]. For authentication and authorization schemes as per [RFC7235]. For
example, the following methodologies could be used among others: example, the following methodologies could be used among others:
TLS Client Authentication TLS Client Authentication
Event delivery endpoints MAY request TLS mutual client Event delivery endpoints MAY request TLS mutual client
authentication. See Section 7.3 [RFC5246]. authentication. See Section 7.3 [RFC5246].
skipping to change at page 22, line 41 skipping to change at page 20, line 51
7.1. Normative References 7.1. Normative References
[I-D.ietf-secevent-token] [I-D.ietf-secevent-token]
Hunt, P., Denniss, W., Ansari, M., and M. Jones, "Security Hunt, P., Denniss, W., Ansari, M., and M. Jones, "Security
Event Token (SET)", draft-ietf-secevent-token-00 (work in Event Token (SET)", draft-ietf-secevent-token-00 (work in
progress), January 2017. progress), January 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010, DOI 10.17487/RFC5988, October 2010,
<http://www.rfc-editor.org/info/rfc5988>. <https://www.rfc-editor.org/info/rfc5988>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, DOI 10.17487/RFC7517, May 2015,
<http://www.rfc-editor.org/info/rfc7517>. <https://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
7.2. Informative References 7.2. Informative References
[openid-connect-core] [openid-connect-core]
NRI, "OpenID Connect Core 1.0", Nov 2014. NRI, "OpenID Connect Core 1.0", Nov 2014.
[POSIX.1] Institute of Electrical and Electronics Engineers, "The [POSIX.1] Institute of Electrical and Electronics Engineers, "The
Open Group Base Specifications Issue 7", IEEE Std 1003.1, Open Group Base Specifications Issue 7", IEEE Std 1003.1,
2013 Edition, 2013. 2013 Edition, 2013.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long "Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202, Polling and Streaming in Bidirectional HTTP", RFC 6202,
DOI 10.17487/RFC6202, April 2011, DOI 10.17487/RFC6202, April 2011,
<http://www.rfc-editor.org/info/rfc6202>. <https://www.rfc-editor.org/info/rfc6202>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012, DOI 10.17487/RFC6750, October 2012,
<http://www.rfc-editor.org/info/rfc6750>. <https://www.rfc-editor.org/info/rfc6750>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <http://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015, RFC 7516, DOI 10.17487/RFC7516, May 2015,
<http://www.rfc-editor.org/info/rfc7516>. <https://www.rfc-editor.org/info/rfc7516>.
[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, [RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0 Client Authentication "Assertion Framework for OAuth 2.0 Client Authentication
and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
May 2015, <http://www.rfc-editor.org/info/rfc7521>. May 2015, <https://www.rfc-editor.org/info/rfc7521>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<http://www.rfc-editor.org/info/rfc7617>. <https://www.rfc-editor.org/info/rfc7617>.
[saml-core-2.0] [saml-core-2.0]
Internet2, "Assertions and Protocols for the OASIS Internet2, "Assertions and Protocols for the OASIS
Security Assertion Markup Language (SAML) V2.0", March Security Assertion Markup Language (SAML) V2.0", March
2005. 2005.
Appendix A. Other Streaming Specifications Appendix A. Other Streaming Specifications
[[EDITORS NOTE: This section to be removed prior to publication]] [[EDITORS NOTE: This section to be removed prior to publication]]
skipping to change at page 26, line 48 skipping to change at page 25, line 15
o Removed Control Plane from specification o Removed Control Plane from specification
o Added new HTTP Polling delivery method o Added new HTTP Polling delivery method
o Added general HTTP security considerations o Added general HTTP security considerations
o Added authentication and authorization o Added authentication and authorization
o Revised Verify Event to work with both types of delivery o Revised Verify Event to work with both types of delivery
draft-hunt-secevent.distribution revision history: Draft 01 - PH - Removed Verification section per feedback from
IETF99.
This draft was based on draft-hunt-secevent.distribution revision
history:
o Draft 00 - PH - First Draft based on reduced version of draft- o Draft 00 - PH - First Draft based on reduced version of draft-
hunt-idevent-distribution hunt-idevent-distribution
o Draft 01 - PH - o Draft 01 - PH -
* Reworked terminology to match new WG Transmitter/Receiver terms * Reworked terminology to match new WG Transmitter/Receiver terms
* Reworked sections into Data Plane vs. Control Plane * Reworked sections into Data Plane vs. Control Plane
 End of changes. 29 change blocks. 
128 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/