SCIM Profile for Security Event Tokens
draft-ietf-scim-events-16

Thank you for the work to develop this document. 

I did not note any transport-related concerns. I saw some issues around the use of normative language, but I see Med discovered more. I therefore support his recommendations to review the use of RFC 2119 keywords.

Gorry

Thanks to the authors and the WG for their work on this document.

I have some minor comments/suggestions to improve the document.

Abstract:
The use of RFC references isn't necessary and is affecting readability. How about?

This specification defines a set of System for Cross-domain Identity Management (SCIM) Security Events using the Security Event Token Specification to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. 

The following sentence with the section reference is better placed in the Introduction and instead suggest using the following in its place in the Abstract:

This draft updates RFC7643 by defining additional attributes for urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig schema and it updates RFC7644 with the optional new Asynchronous SCIM Request capability.

Section 1.2:

s/percent encode/percent-encode

Section 1.3, paragraph 6
>    Attributes and Claims
>       The JWT specification [RFC7519] upon which SET is based uses the
>       term "claims" to refer to attributes in a JSON token.  SCIM in
>       contrast uses the term "attributes" to refer to JSON attributes.
>       For the purposes of this draft, the terms "attributes" and
>       "claims" are equivalent.

Is this not a duplicate of what is mentioned above?

Section 1.3, paragraph 7
>    DBR
>       Abbreviation for "Domain Based Replication" as defined in
>       Appendix A.1.  In this mode because there is an administrative
>       relationship spanning multiple operational domains, data shared in
>       Events typically uses the full mode variation of change events
>       including the data payload attribute (see Section 2.4).  This
>       eliminates the need for a callback to retrieve additional data.

What is "full mode variation of change events"? Can this be described or defined?

Section 5, paragraph 0
> 5.  Security Considerations

This document covers Security Considerations, Privacy Considerations, and IANA Considerations, but not Operational or Management Considerations as Med has pointed out. I would imagine that there are considerations in how SCIM events are logged or errors reported that might be useful for an operator.

"A.1.", paragraph 3
>                      +----------------+
>                      |  SCIM Client A |
>                      +----------------+
>                               |
>                     [1] SCIM Operation
>                               |
>                               v
>                      +----------------+
>                      | Service        |
>                      | Provider       |
>                      +----------------+
>                               ^
>                     [2] SCIM Response
>                               |
>                               |
>                               v
>                      +------------------------+
>                      | Service Provider       |
>                      | Replica                |
>                      +------------------------+
>                               |
>               [3] Event SCIM:prov:<op> id=xyz
>                               |
>                               v
>                      +----------------+
>                      | Update local   |
>                      | node [4]       |
>                      +----------------+
> 
>                 Figure 20: Domain Based Replication Sequence

This figure and the next does not render itself in the html version of the document.

No reference entries found for these items, which were mentioned in the text:
[draft-hunt-idevent-scim-00].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 1 and every other place in the document.
> RFC7644] that cause a state change to a SCIM Resource. When multiple indepen
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 8.1, paragraph 5
> de, the receiver of an event must callback to the originating SCIM Service P
>                                   ^^^^^^^^
The word "callback" is a noun. The verb is spelled with a space.

Thanks for addressing my previous DISCUSS and COMMENTs.

Hi Phil, all, 

Thanks for the follow-up and changes made since last time I reviewed the doc [1]. The changes at [2] are real improvements. 

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/scim/U-g98Db0uGT-7FdIjx5raWLg2u0/

[2] https://author-tools.ietf.org/iddiff?url1=draft-ietf-scim-events-10&url2=draft-ietf-scim-events-12&difftype=--html

Thank you to Elwyn Davies for the GENART review.

Thank you for addressing my DISCUSS and COMMENT feedback.

I support Roman's and Mike'a DISCUSSes.