Features validated Clause Samples
The 'Features validated' clause serves to confirm that specific features or functionalities of a product or service have been tested and meet agreed-upon standards or requirements. In practice, this clause typically outlines which features have undergone validation, the criteria used for validation, and may specify the methods or tests performed. Its core function is to provide assurance to the parties involved that the product or service delivers the promised capabilities, thereby reducing the risk of disputes over performance or quality.
Features validated. The northbound API of the TNRM, which offers experimenters the ability to request resources, makes it the main objective of the work carried out within the RMs for ▇▇▇▇▇. The development of the TNRM module focused on its correct interoperability with other components, via the TNRM's northbound API and the target transit network service API for underlying infrastructure. As in the case of other RMs, we divided the validation and testing phases as follows in order to ensure proper functioning: • Compliance of TNRM northbound API with the GENIv3 standard • Correct internal behaviour for each method exposed by the northbound API • Availability of the TNRM module and its underlying infrastructure
Features validated. We broadly categorise those features of Public Monitoring that are of interest to the ▇▇▇▇▇ infrastructure as fol- lows: • Correct behaviour of monitoring soGware modules. • Correct behaviour of monitoring hardware connectivity. • Availability of the Public Monitoring modules.
4.7.1.1 Correct behaviour of monitoring so†ware modules
4.7.1.2 Correct behaviour of monitoring hardware connectivity Endoint Method Arguments Returns
Features validated. The main extensions and improvements performed on CRM deal with the proper interoperability of this module and others via the northbound API of the CRM. To validate its correct functioning, we divided the validation and testing phases as follows: • Compliance of CRM's northbound API with the GENIv3 standard • Correct internal behaviour for each method exposed by the northbound API • Availability of the CRM module and its underlying infrastructure
Features validated. The features of SERM that are in scope of validation are: • Compliance of the SERM's northbound APIs with the GENIv3 standard • Correct internal behaviour for each method exposed by the northbound API • Correct behaviour for the resource management • Availability of the SERM module
Features validated. We broadly categorise those features of (M)RO that are of interest to the ▇▇▇▇▇ infrastructure as follows: • Compliance of the (M)RO's northbound APIs with the GENIv3 standard • Correct internal behaviour for each method exposed by the northbound API • Correct behaviour for the resource management • Availability of the (M)RO module and the underlying RMs
Features validated. We broadly categorise those features of MS and MMS that are of interest to the ▇▇▇▇▇ infrastructure as follows: • Correct behaviour of the MS API defined in ▇▇▇▇▇ project • Correct internal behaviour for each endpoint exposed by the MS API • Availability of the MMS and MS modules and the underlying components
4.6.1.1 Correct behaviour of the MS API defined in ▇▇▇▇▇ project Endpoint Method Contents Returns
4.6.1.2 Correct internal behaviour per endpoint
4.6.1.3 Correct internal behaviour with other components
4.6.1.4 Availability of MMS and MS modules and underlying components