[scim] Ben Campbell's No Objection on draft-ietf-scim-api-18: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-scim-api-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-scim-api/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Update: I've released my DISCUSS on this. All my DISCUSS items have been
resolved save the last one that I am moving to a comment. My point was to
make sure the concern was discussed--if the authors answer that the
working group thought about this want to keep it as is, that's okay with
me.

Former Discuss Point:

It's optional (MAY) to include the API version. If the version is
missing, the service provider SHOULD perform the operation using the most
recent supported version. This seems to allow the client and service
provider to disagree on the version being used. Does this cause an
interop problem if the later version is not backwards compatible? (Are
all new versions expected to be backwards compatible with old versions?)

[ I've removed comments that I think have been addressed.]

[...]

-- 2.1, last paragraph:

Just SHOULD? Do you invision situations where it might be reasonable
_not_ to take the threats into account?

Also, the reference to oath-assertions needs to be normative

-- 2.2, "... it MAY be acceptable"

[...]

-- 3.3, 3rd bullet:

How does a service provider know which attributes a client understands?

[...]


As worded, that sounds like a statement of fact.

-- 7.3:

That needs to be a normative reference. Also, why is this a SHOULD? Can
you envision scenarios where it might be reasonable for implementors NOT
to take the countermeasures into account?

-- 7.4:

Reference to oauth-assertions needs to be normative.

-- 7.6, 2nd bullet

[...]