New requirements will be considered for future CGL documentation and they will come from these sources:
As an alliance of Carriers, NEPs, and equipment providers, the SCOPE Alliance is a primary source of requirements for the CGL workgroup.
The SCOPE Alliance develops gaps/requirements documents that spell out the need for capabilities and APIs relating to the gaps/requirements. These gaps will given to the CGL workgroup and it will be a joint effort between the SCOPE and CGL workgroups to filter the gap descriptions into requirement descriptions (testable assertions). If there are broad gaps around interoperability, availability, etc., these will be need to be distilled into something that can be verified. For instance, 5 nines or 6 nines availability would possibly need use case descriptions and measurement criteria. It may break down to something like failover times under defined loads or TCP reconnection times with controlled connection failures.
Part of the exercise will to be determine priority of the requirements and this will be derived from criteria such as the criticality of the capability in a use case and the availability of an implementation (like a PoC) that would address the capability.
The LF is the standardization and certification authority for Linux. SCOPE "is an industry alliance committed to accelerating the deployment of carrier grade base platforms for service provider applications." It is the intent that satisfied requirements and community-accepted APIs would be candidates for inclusion into the LSB. SCOPE should be able to reliably profile deployment stacks for network equipment around the CGL requirements and the LSB certified capabilities.
SCOPE members participating in CGL will be assumed to be representing their own company's interests unless they explicitly state that they are speaking for SCOPE. That enables SCOPE members to engage in early participation while reserving official acceptance of a standard to the SCOPE board.
The Linux Standard Base supports the implementation of optional modules specifying certain functionality. In most cases, that functionality would need to have an associated test suite. If the CGL workgroup decides it would be useful, construction of a CGL LSB module could enable a more rigorous certification process. However, any LSB work is initially out of scope of the workgroup, and will require an update of this charter to initiate.