SACM Virtual Meeting Meeting Wednesday, September 10, 2014, 12-2 PM EDT Agenda 1 logistics, note takers 2 WG Status 3 SACM Information Model 4 SACM Architecture 5 SACM Requirements 6 XMPP Grid Protocol 7 Way Forward Participants: Josh Lubell, Dan Romascanu, Brant Cheikes, Charles Schmidt, Danny Haynes, Gunmar, Cliff Kahn, Brian Ford, Thomas Joy, Lisa Lorenzin, Matt Hansbury, Nancy Cam-Winget, Takeshi Takahashi, Dave Waltermire, Jim Bieda, Ira McDonald, Jarrett Lu, Adam Montville, Kathleen Moriarty, Jessica Fitzgerald-McKay, "Call-in User 6", Henk Birkholz, Dave Misell, Atul 1. Josh Lubell, Brian Ford taking notes (Big Thanks!) 2. WG Status Nancy - didn't have time to update Architecture. Suggest spending more time on Informational Model during this meeting. Question to group: Should we cite XMPP references in the SACM spec or in the XMPP Grid Protocol spec? Dan R - WG status: use case document on way to IESG. Any IPR that needs to be disclosed? If so, please disclose. Protocol and Info Model milestones have slipped. Since Toronto meeting, Architecture and Info Model behind "way forward" schedule. 3. SACM Information Model Lisa L - this doc is a merger of work from TNC and from Waltermire/Watson. Limited scope to info model. Moved out-of-scope items to appendices, which should be moved to other docs as appropriate (e.g., Architecture, terminology, etc.). Dan R - What is the scope of the info model? Nancy - Described in Problem Statement (sec. 2 of document). Info model describes abstractly components and interfaces. We have a problem statement that is a scope of work. We have use cases. The solution we envision in the arch doc is composed of 1 or more protocols and one or more data models. The scope of the information model is to describe the structure of the information carried to realize the assessment. Dan R - Info model should be an abstraction of data model Lisa - sound good. Should be incorporated into document. [walk-through of Fig. 1 from document. Lisa/Nancy discussed extensibility of relationships. Is the model flexible enough?] Gunnar - Is there any mechanism for ‘attribution’. Nancy - There needs to be agility to provide for different relationships Discussion about the ‘agility’ of the information model. Cliff - Required use of ASCII art and need to fit it all on a single page forced me to leave stuff out of the diagram. Dan R - This diagram needs to be consistent with the architecture. Lisa - Good point. Some work needs to be done on Architecture to make consistent. In the mean time, the simple diagram in the Architecture document is consistent. Dan - agree Lisa - looking for feedback on whether new elements or new characteristics for additional elements needed Dan - how does the Graph Model (5) related to the Info model (4) Lisa - sect 4 is about organization. Sec 5 is about enumeration Dan R - We may want to talk about the graph representation as an appendix or separate document that explains the usage of the more complex structures. I don’t think we need to list all the elements, instances and attributes and representing them through the graph model. Maybe we need an example or two. I’m still fighting whether graph model belongs here as an appendix or a separate document. Jim Bieda - Graph model seems like an implementation choice. Is it a should or a must or an option. Lisa - Open question? Jim - there is an opportunity to work this for the next call and meeting. Dave W - if we don't use graph notation in this document, then what should be use instead? Dan R - maybe UML. Also, maybe section 6 should be merged into section 5. Lisa - Looking for helping writing section 6 without graph terminology. (chuckles). Lisa ? Appendix C is material that should be considered for inclusion into the arch and use case docs. Section E discussion ? Where does this belong?? Ira - Section E discussion on endpoint attributes Is this implementation guidance or best practice? Dan - Do we need to spend time on other documents?? Lisa ? We are done with content here. The editors have worked on this combined info model outside of the WG because having more people involved became unwieldy. They are looking for input. Lots of work still to be done. Does anyone want to join the weekly calls? Dan - There are a few key questions, big questions which run through discussions like: what do we do with graph models ? what do we do with work flow ? 4-6 big questions. I propose staring a thread for each big question on the mailing list. 5. SACM Requirements Nancy - made minor fixes to old document. Partitioned "agility" requirement into multiple, more granular requirements (12-16). This was discussed at the face-to-face. Added sec. 2.3 (Requirements for the Info Model) Lisa - I think we have consensus that operations and workflow are not part of the info model. Ira - there should be a "requirements for the architecture" section. Also, don't like "General SACM requrements" as a title. Lisa - Disagree with latter. There are requirements that are part of the SACM problem space but don't apply specifically to use cases, info model, etc. Lisa - how about "SACM Requirements" instead? Ira - that's fine Dave W - some of the "general" requirements look like they belong in more specific sections. Nancy - please send your feedback to the mailing list. Dave W - if requirements to be renumbered, should retain old number until documents that reference the Reqts doc are updated. Protocol issue: Nancy - should XMPP terminology definitions stay in the Grid Protocol draft, or should they go in the Terminology doc? [consensus to keep as is for now] 7. Way forward Dan R - We have opportunity for another interim before the Honolulu meeting. Suggest having one in early-to-mid October. Propose Reqts, Arch and Info Model docs be updated beginning of October prior to the Interim. Dave W - I'm not available week of 10/6 or week of 10/13, but please proceed without me. Dan R - Question to editors: should next versions of the Info Model and Architecture docs be SACM WG items? Means content has to conform to IETF rules and processes. But document doesn't have to be stable to be a WG item. Call for consensus to be issued to mailing list.