110 likes | 231 Views
(E?)SCCS-SM Concept Green Book Review Items. Global Editorial/Style Issues. Defining acronyms once at their first use and using the acronym thereafter Will be done uniformly Exception for Executive Summary, which is treated as a stand-alone document
E N D
Global Editorial/Style Issues • Defining acronyms once at their first use and using the acronym thereafter • Will be done uniformly • Exception for Executive Summary, which is treated as a stand-alone document • Use of initial capitalization for special terms (e.g., Information Entity, Functional Resource) • Will be done uniformly • Use of italicization • Name of a book or standard • First usage of a term that has a specific technical meaning in the context of SCCS Service Management. This may be redundant with use of initial caps • Capitalization of “figure” and “table” • CCSDS Publications Manual calls for lower case in references, upper case in figure/table captions • MS Word automatic cross-references to figure numbers capitalizes, but Secretriat (Tom Gannett) will fix these • Insertion of “section” before section number references CCSDS Publications Manual calls for “section” to be inserted only for first-level section numbers (e.g., “section 3”)
Is this “Extensible” SCCS-SM or Just SCCS-SM? • “Extensible” was originally included in the title to differentiate this concept from the “version 1” concept, which we used to think would continue to be maintained • Will V-1 SCCS-SM be deprecated? • If we eliminate “extensible” from the title, this will be the SCCS-SM Concept Green Book (CCSDS 902.0-G-1) vs. the CCSDS-SM Operations Concept Green Book (CCSDS 910.14-G-1) • Or does this just become 910.14-G-2?
Comparison to SM Precedents • How much should we explain how this effort compares and contrasts with the concepts for the Cross Support Reference Model (CSRM) and Version 1 SCCS-SM? • CSRM is still a normative source for concepts that control SM (although it’s called “SLE-SM” there) • Even if Version 1 SCCS-SM is deprecated, can we just ignore the differences between it and this new concept?
Role of the Enterprise Model in the SCCS-SM Concept • Is it the SCCS Enterprise SM model or the SCCS SM Enterprise Model? • What’s the difference, if any? • Why do we describe the SSI enterprise model if it’s outside the scope of what we are concerned with for the foreseeable future?
Role of the Functional Resources Tech Note • The FR Tech Note is a referenced document of the Green Book, even though it has no formal standing in CCSDS documentation • Should terms that appear in the Tech Note be cited as the source of the definition of those terms? (I propose yes) • Some suggestions have been made to trim the Green Book and refer more to the Tech Note • I am okay with this for material beyond the SM concept, but I think that material directly relevant to the SM Concept should stay in the Green Book, even if it is a repeat of Tech Note material • Tech Note needs to be updated to reflect changes since last summer
Service Packages, Configuration Profiles, Service Agreements, and Functional Groups • The review has surfaced some disconnects and ambiguities regarding the relationships among Service Packages, Configuration Profiles, and Service Agreements
Service Packages • The Service Package Information Entity calls out two kinds of Service Package • SLS Service Package • Retrieval Service Package • The SLS-Disjoint Functional Group (tentatively to be renamed Offline FG) identifies a third type of Service Package – Store and Forward – for offline forward services • Intended to accommodate the offline aspects of the Forward File service • Tricky to deal with because we don’t have a well-defined Forward File service, so we don’t yet know how it needs to be managed • Note: this Service Package could probably be renamed Forward Offline Service Package • Question: Do we want to include a Forward Offline flavor of Service Package, even if it is just a placeholder?
Service Agreement • Functional Group section introduces the term Service Agreement profile, which is needlessly confusing • What this is intended to mean is an instance of the Service Agreement Information Entity as it applies to a specific Service Agreement between a Provider CSSS and a Mission • The term Service Agreement profile will be removed • The Telecommand Mission Example and AOS Mission Example in the Functional Group section call out parts of the Service Agreement that apply to SLS Service Packages and Retrieval Service Packages, but these parts are not mentioned before this • Recommend mentioning these aspects earlier in the exposition • If we decide to have a Forward Offline Service Package, then there should be a corresponding part of the Service Agreement
Configuration Profiles • The Telecommand Mission Example and AOS Mission Example in the Functional Group section call out parts of the Configuration Profiles that apply to SLS Service Packages and Retrieval Service Packages, but these parts are not mentioned before this • In particular, current description of Configuration Profile Info Entity focuses on SLS Service Package Configuration Profiles • Recommend mentioning these aspects earlier in the exposition • If we decide to have a Forward Offline Service Package, then there should be a corresponding part of the Configuration Profile
Management Services • Currently, these are aligned with the lifecycle stages • Based on Version 1 precedent • It seems premature to make that claim • We don’t know what aggregations make sense • Propose softening the section and just say that management services will be available to support activities across the mission support lifecycle