# SCIM IG Meeting Notes 20 October 2021

# Attendees
* Danny Mayer
* Matt Peterson
* Janelle Allen
* Phil Hunt
* Nancy Cam-Winget

# Notes
Agenda:
* WG Status
* Planning for IETF 112 session
* Initial conversation: RFC 7242

# Dates
* cutoff date for draft submissions is Monday - Nov 1

# Scribed Chat
nancy: we are currently listed as a BOF, we are on the WG forming path.
* Comments are still trickling in, not sure when final vote is but this seems like a good sign
* Choosing a co-chair is up to Roman, Nancy needs to check with him

phil: if you want to have a draft to discuss at the meeting and you want the IPR to be clear, the deadline is Monday at Nov 1

nancy: where it becomes important is if the WG wants to adopt the draft. Typically it is good to have 3-4 people review the draft prior to any adoption call.

phil: of the drafts that could be upreved, one of the drafts has to be significantly changed (secevent) so there is a lot of work there. Can talk about the history and could make recommendations in the BOF but it depends on whether we are BOFing or not

pam: do we have to submit RFC 7242? (nancy says no)

nancy: typically in the 1st couple of meetings it is work on how to shape documents and asking for authorship. In TLS 1.3, ecr had already started so things like that would accelerate the process

nancy; there were comments that our milestones are "aggressive"

everyone: nods

phil: 3 years is a very fast turnaround, it is more likely 3-5. When Phil & Mike did the authentication request draft it was a year

nancy: sitting in the IANA queue can take months so we should plan for that

phil: the SCIM specs were 8 months in that queue

nancy: not too surprising

nancy: other comments: ben k questioned the scope of the charter, this was the most in-depth comment but even then there were no objections

phil: for the IANA queue, that was 8 months with no real roadblocks

pam: this objection process is something that we can see but don't need to act around, correct?

nancy: correct

nancy: some feedback here, including we need to expand HR and not use semicolons instead of colons, as well as some words in the charter "currently" and "planned" are superfluous

janelle: is there a suggested style guide for charters?

nancy: no. Charter needs to include scope and milestone

pam: will there be an official notification to the mailing list?

nancy: typically this will be the AD (Roman) who does this

nancy: the agenda is set - Thursday Nov 11, noon to 2pm. We are chartered now as SCIM not SINS

nancy: important dates to note: final agenda is published, Nancy will put the call for agenda out this week, we can all respond back with topic and timeslot. It might be worth doing a refresher, if somebody can do that. Cutoff date is Monday Oct 25,

phil: in my experience, if there is a whole new idea, it is frustrating if there is no concrete artifact to discuss. No matter how bad the idea is, an I-D is a good discussion point. If you don't, you often get no questions or hostile questions

matt: just wanted to know if there are new drafts we expect to come out

nancy: convention is to post to the mailing list if you do post a draft

phil: if you go to the drafts page & click on related documents, it will show you the expired stuff - https://tools.ietf.org/wg/scim/

- there is a section called "Related Active Documents, you can see all the expired stuff there"

matt: concerned that just talking about multi-based pagination, there is a lot of confusion there, so worried that this I-D needs heavy revisions

phil: will likely rename that draft, this is about controlling what data appears in the output. Will put together a slide deck on synchronization, on SET and what to do to move forward. Suggest also talking about synchronization and then stateful paging. This would be a general conversation, that is a focusing tactic, then more proposals could come forward

matt: the reason for asking is that Matt was going to propose a collaboration to get a draft in right away, but if that isn't needed, then it is better to discuss first

phil: my personal view is that stateful paging is a bad idea. He has a lot

matt: if someone has a real use case, then that is one thing.

phil: need to disucss why brute force reconciliation is such a problem. Also need to write out the use case for how to spin up your original data import/export

matt: agree that things like how to ask for members of a group can be handled with best practices

phil: one other thing about mult-value paging is there is a 1000 entry limit. But the spec says that there could be a limit that might be specific to type of query agent etc. It needed to be in the spec so clients could handle limits if they occur, but there is confusion. This might come up as a best practice rather than an amendment.

matt: seems like needing a draft to discuss is no

janelle: was thinking about use cases today, it sounds like bulk data load could be the answer here, but event based handling vs. queue-based handling could be an option

phil: one of the systems I liked that is better than how SET went - SET is a hub/spoke, but if you're trying to configure a series of replica servers, if you have a message bus, then there is a changelog inherent in the bus. So you could go back and say "give me all changes since date X" in theory you could read the entire bus to get an entire picture. The SET event transfer model works cross-domain, that really works but in case of 100 SCIM servers, the decision authority becomes the bus as th source of agreement. This is one way to solve it. It is almost like the LDAP changelog

danny : I implemented it as a message queue, clients subscribe and can pull what they want

phil: I say I'm changing this resource, I can check the hashtag. If 2 servers both run a change agains the same hashtag, what should happen?

pam: I'm a little concerned that we have the pagination discussion in the first meeting before we gain momentum

phil: suggest it would be really good to have a conversation about best practices I could at least give an overview of the past so folks can decide whether to chat more

pam: suggest we should do use cases even before best practices - seems the scim use cases was finished early, but wasn't updated at the same time the spec did

phil: what was actually driving the spec was scim 1, everyone was focused on that

phil: gave an example of places where the spec was vague about what to do - we should talk about papercuts

pam: we need a bugtracker to capture these papercuts

phil: the spec is "robust" which means that if you understand the intent, you are able to process anyway. Group was worried about being too strict

pam: but wait doesn't this mean that anyone writing to the spec has to learn and understand the intent?

phil: consensus has changed around completions and failures. Everybody is running the same recipe, but they are all a little bit different.

janelle: maybe this is just a clarification that could go into a best practices doc?

phil: this has worked well in the OAuth WG. Eg: audience in a JWT token

janelle: do we have enough papercuts collected?

phil: we don't have anything collected, that's the problem

nancy: that is what I would suggest somebody do in preparation for the meeting

pam: let's put it to the list and see if we can get a volunteer