Thanks Ben for updating the PNF requirements. Please see my comments inline below.
Have a nice day Zu Qiang PNP-1330 [PNF] - The PNF Vendor MUST provide software Version(s) to be supported by PNF for SDC Design Studio PNF Model. This is set in the PNF Model property software_versions. [Zu Qiang] In 5G PnP wiki page the sw-version is an optional parameter. It cannot be a must requirement. “PNP-1100[SDC]: The user can (optional) provide the following to define the resource definition…” PNP-1340 [PNF] - The PNF MUST onboard the pnfRegistration VES Event, HVol VES Event, and Fault VES Event.to be supported by the PNF into the SDC Design Studio. [Zu Qiang] How a PNF onboard a VES event using SDC design studio? What is onboard means? Support? [Zu Qiang] “to be supported by the PNF into the SDC Design Studio.” Is this an incomplete statement? [Zu Qiang] Proposed rewording: “The following VES events MUST be supported by the PNF for ONAP PNF plug and play registration procedure: …” PNP-3010 [PNF] - The PNF MUST support & accept the provisioning of an ONAP contact IP address (in IPv4 or IPv6 format). It is expected that an external EMS would configure & provision the ONAP contact IP address to the PNF (in either IPv4 or IPv6 format). For PNF Plug and Play Use Case, this IP address is the service provider's "point of entry" to the DCAE VES Listener. Note: different service provider's network architecture may also require special setup to allow an external PNF to contact the ONAP installation. For example, in the AT&T network a maintenance tunnel is used. [Zu Qiang] Can you keep the explanation text in a new line as you did in PNP4410? [Zu Qiang] Is it out of scope for ONAP to specify how the contact address is provisioned. Please remove: “It is expected that an external EMS would configure & provision the ONAP contact IP address to the PNF (in either IPv4 or IPv6 format).” And the example. PNP-3020 [PNF] - The PNF MUST have "ONAP Aware" software either installed, or loaded that is capable of performing PNF PnP registration with ONAP. It is up to the specific vendor to design the software management functions. The "ONAP Aware" software that is capable of performing the PNF PnP Registration with ONAP shall either be loaded separately or integrated into the PNF software upon physical delivery and installation of the PNF. [Zu Qiang] Does it make any difference to ONAP if the software is “installed” or ‘loaded’? proposed rewording: “the PNF MUST have ONAP aware software to perform ONAP PNF plug and play registration procedure.” [Zu Qiang] Besides, the ONAP aware software capability has been explained twice. PNF-3030 [PNF] - The PNF MUST support the provisioning of security and authentication parameters in order to be able to authenticate with DCAE (in ONAP). In R3, a username and password are used with the DCAE VES Event Listener which are used to authenticate a PNF. The configuration management and provisioning software are specific to a vendor architecture, but the PNF shall have the software to support configuration of identification information so that a proper authentication exchange can happen with ONAP. [Zu Qiang] “In R3 ..” is duplicated with PNP4120. Please remove it. Rewording proposal: “the PNF MUST support the provisioning of security parameters for ONAP authentication” PNP-4120 [PNF] - The PNF MUST authenticate with the DCAE VES Event Listener using a X.509v3 Certificate (issued by the Service Provider CA) also a username and password (that had been previously provisioned and configured). [Zu Qiang] This is what is specified in VES 7.0.1 “In the future, support for 2-way SSL certificate authentication (aka mutual SSL) will be provided but for now, event source credentials are passed using HTTP Basic Authentication<http://tools.ietf.org/html/rfc2617>.” Propose using the same language. “PNF must support HTTP Basic Authentication<http://tools.ietf.org/html/rfc2617> as specified in VES 7.0.1…” PNP-4200 [PNF] – The PNF MUST use a previously provisioned IP address to contact ONAP. The PNF shall open a HTTPS connection to the DCAE VES Event Listener. Note: it is expected that an ONAP operator can ascertain the ONAP IP address or the security gateway to reach ONAP on the VID or ONAP portal GUI. Note: The ONAP contact IP address has been previously configured and provisioned prior to this step. [Zu Qiang] In VES 7.0.1, “HTTPS (rather than HTTP) should be used.” So HTTPS is a SHOULD requirement. HTTP is allowed but not recommended. [Zu Qiang] Please remove “previously” PNP-4210 [PNF] – The PNF MUST send the pnfRegistration VES event. [Zu Qiang] I guess you want to say “PNF must support sending ….” PNP-4410 [PNF] The PNF MUST continue to periodically send the pnfRegistration VES event. The pnfRegistration VES event shall be sent with a configurable periodicity. [Zu Qiang] Proposed rewording: “the pnfRegistration VES event SHOULD be sent by PNF with a configurable periodicity” Note: The PNF uses the service configuration request as a semaphore to stop sending the pnfRegistration sent. See the requirement PNP-5360 requirement. Note: It is expected that each vendor will enforce some sort of PNF timeout period, the PNF cannot wait indefinitely as there may also be a technician on-site trying to complete installation & commissioning. The management of the VES event exchange is also a requirement on the PNF to be developed by the PNF vendor. PNP-4420 [PNF] - If the PNF encounters an error authenticating, reaching the ONAP DCAE VES Event listener or receives an error response from sending the pnfRegistration VES Event, it MUST log the error, and notify the operator. Note: the design of how errors are logged, retrieved and reported will be a vendor-specific architecture. Reporting faults and errors is also a vendor specific design. It is expected that the PNF shall have a means to log an error and notify a user when a fault condition occurs in trying to contact ONAP, authenticate or send a pnfRegistration event. [Zu Qiang] “log” and “notify” is an implementation choice. It cannot be a “MUST” requirement. Please make it a “MAY” PNP-5350 [PNF] - The PNF MUST support a Service Configuration message exchange from the PNF Controller (in ONAP). Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the PNF and PNF domain. Note: for R3 (Casablanca) only Ansible is supported. [Zu Qiang] Supporting the message exchange does not mean anything. For instance, an implementation can receive the message and do nothing. The requirement should say when receiving the message, what action should be taken by the implementation. Or what protocol should be enabled in order to receive that message. Propose rewording: “the PNF MUST support Ansible protocol for service configuration from ONAP” PNP-5360 [PNF] - When the PNF receives a Service configuration from ONAP, the PNF MUST cease sending the pnfRegistration VES Event. PNP-5370 [PNF] - The PNF may support the optional parameters for the Service Configuration Parameters for Stage 5 PnP Note: These parameters are optional, and not all PNFs will support any or all of these parameters, it is up to the vendor and service provider to ascertain which ones are supported up to an including all of the ones that have been defined. Note: It is expected that there will be a growing list of supported configuration parameters in future releases of ONAP. [Zu Qiang] please remove “Stage 5” or move it into a note. PNP-5380 [PNF] (Error Case) - If an error is encountered by the PNF during a Service Configuration exchange with ONAP, the PNF MUST log the error and notify an operator. [Zu Qiang] “log” and “notify” is an implementation choice. It cannot be a “MUST” requirement. Please make it “MAY” PNP-5390 [PNF] (Error Case) - If the PNF never receives a Service Configuration message from ONAP, it MUST time-out, log an error and notify an operator (if possible). Note: It is expected that each vendor will enforce a PNF timeout period, the PNF cannot wait indefinitely as there may also be a technician on-site trying to complete installation & commissioning. The management of the VES event exchange is also a requirement on the PNF to be developed by the PNF vendor. [Zu Qiang] Proposed rewording: “The PNF must support a configurable timer to stop the periodicity sending of the pnfRegistration VES event” [Zu Qiang] it is hard to determine what is ‘never’ for an implementation. A configurable timer is more precise. [Zu Qiang] “log” and “notify” is an implementation choice. It cannot be a “MUST” requirement. Please make it “MAY” [Zu Qiang] the Note is repeated with 4410. Please either remove it or move it into a generic place. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#12437): https://lists.onap.org/g/onap-discuss/message/12437 Mute This Topic: https://lists.onap.org/mt/25675418/21656 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
