UC 17d is ambiguous about what object needs to be in the request body and what all objects get created on the server

[roshan-joyce-fujitsu]

Title of the UC 17d says:
Use case 17d: Provisioning of an OAM Job Service

The description says:

So, many things are not clear:

• Should the request body contain an oam-job or an oam-job-service?
• Should the server controller create an oam-job instance or an oam-job-service instance or both?
• Should the response header indicate the location of the created oam-job or oam-job-service?
• Can the client specify the type of the oam-job (or oam-job-service) as the base identity OAM_JOB_TYPE? (Considering for example, that it is a job asking for PM data for multiple technology CEPs and wants to get all available PM data for these CEPs). All defined job types are listed at the end of this ticket.
  • Or, can we add a new sub-identity like OAM_JOB_TYPE_DEFAULT or OAM_JOB_TYPE_ALL_PM?
  • This will be useful if the controller models a default oam-job-service that collects available PM across technology types.
• After the job is created and has started/finished execution, where will the client expect the collected data to be?
  • Will it be under oam-job/current-data and oam-job/current-data/history-data?
  • Or under oam-job-descriptor/cep-pm-data? If so, it has only history-data and no current-data. Why?
• What is the association between oam-job-service, oam-job-descriptor, and oam-job.

Base OAM Job Types (tapi-oam.yang)
OAM_JOB_TYPE - Base identity for all OAM job types
OAM_JOB_TYPE_LOOPBACK_FACILITY - External / Line Loopback
OAM_JOB_TYPE_LOOPBACK_TERMINAL - Internal / Device Loopback
Photonic OAM Job Types (tapi-photonic-media.yang)
PHOTONIC_OAM_JOB_TYPE - Base for photonic OAM jobs
PHOTONIC_OAM_JOB_TYPE_OPTICAL_POWER - Optical power monitoring
Digital OTN OAM Job Types (tapi-digital-otn.yang)
ODU_OAM_JOB_TYPE - Base for ODU OAM jobs
ODU_OAM_JOB_TYPE_NCM - ODU Non-intrusive Connection Monitoring
ODU_OAM_JOB_TYPE_TCM - ODU Tandem Connection Monitoring
Ethernet OAM Job Types (tapi-eth.yang)
ETH_OAM_JOB_TYPE - Base for Ethernet OAM jobs
ETH_OAM_JOB_TYPE_ETH_1DM - Ethernet One-way Delay Measurement
ETH_OAM_JOB_TYPE_ETH_1SLM - Ethernet One-way Synthetic Loss Measurement
ETH_OAM_JOB_TYPE_ETH_LM_CCM - Ethernet Loss Measurement using CCM
ETH_OAM_JOB_TYPE_ETH_LM_LMM - Ethernet Loss Measurement using LMM
ETH_OAM_JOB_TYPE_ETH_SLM - Ethernet Synthetic Loss Measurement
ETH_OAM_JOB_TYPE_ETH_DM - Ethernet Delay Measurement
ETH_OAM_JOB_TYPE_ETH_LTC - Ethernet Link Trace
ETH_OAM_JOB_TYPE_ETH_LBK - Ethernet Loopback
ETH_OAM_JOB_TYPE_ETH_TEST - Ethernet Test

CC: @kgkishore @nigel-r-davis @bcjohnso99 @arthurMll

[roshan-joyce-fujitsu]

IMO, we should add an OAM_JOB_TYPE identity such as:

    identity OAM_JOB_TYPE_MONITOR_ALL {
        base tapi-oam:OAM_JOB_TYPE;
        description "Cross-technology monitoring job type. This job type allows a client to collect 
            PM data across multiple technology types (e.g., photonic, OTN, Ethernet) within a single 
            OAM job service request. The server will collect all applicable/specified PM parameters for each 
            monitored resource based on its technology layer and the pm-parameter-names provided.";
    }