Cardinality of distributionConfigurations.canonicalDomainName does not match described usage in Create Content Hosting Configuration requests

[davidjwbbc]

Problem description

• TS 26.512 table 7.6.3.1-1 states that the distributionConfigurations.canonicalDomainName has a cardinality of 1..1 and is set by the 5GMSd AF.
• TS 26.512 clause 4.3.3.2 states that the canonicalDomainName is read-only to the Application Provider in the push case, but the pull case is not defined.
• TS 26.512 tables B.1.3-1 and B.2.2-1 both state that the 5GMSd AF populates the canonicalDomainName field for both the push and pull cases.
• The Open API definition in clause C.3.5 specifies that canonicalDomainName is a required property.

The first message containing a ContentHostingConfiguration will be the creation of a Content Hosting Configuration, sent from the Application Provider to the 5GMSd AF. At this stage the AP does not know the canonicalDomainName, and does not set the canonicalDomainName itself, but the field is mandatory.

This ambiguity should be removed from the specification at the earliest opportunity.

Discussion

Should this property be optional or mandatory?

If mandatory, in a Content Hosting Configuration creation request, what value should the Application Provider populate the field with?

Suggested solution

Submit a Change Request to SA4 removing the ambiguity. Either:

• Keep it mandatory:
  1. Describe, in clause 4.3.3.2, the contents of the canonicalDomainName as provided by the Application Provider for both push and pull cases.
  2. Adjust the description in table 7.6.3.1-1 to state the initial value as set by the Application Provider in the Create Content Hosting Configuration POST request.
• Make it optional:
  1. State in clause 4.3.3.2 that the Application Provider will not include the canonicalDomainName property in both push and pull cases.
  2. Fix the cardinality column in table 7.6.3.1-1.
  3. Remove the DistributionConfiguration.canonicalDomainName property from the required list in the OpenAPI schema in clause C.3.5.

[rjb1000]

I believe the design intent to be that canonicalDomainName is set by the 5GMSd AF. This informs the 5GMS Application Provider of the canonical domain name of the 5GMSd AS at reference point M4d.

Given this, I think we should go with your second option of making it optional in table 7.6.3.1-1 and clause C.3.5, and of making your suggested clarification in clause 4.3.3.2.

All resources of the current distribution shall be accessible at reference point M4d through this default FQDN assigned by the 5GMSd AF.
It is an error for a 5GMSd Application Provider to set this property in a request to the 5GMSd AF.

[davidjwbbc]

We believe this should be an optional parameter to allow the AP to omit it in the original request, but will be mandatory for the AF to populate.

@rjb1000 to raise a CR.

[rjb1000]

3GPP draft Change Request to TS 26.512 Rel-16 S4aI221386 opened for initial discussion at today's 3GPP SA4 MBS subworking group ad hoc call. Discussion will continue on 20th October.

(Plan is to create a Rel-17 counterpart later that makes equivalent changes there.)

[rjb1000]

Latest draft CRs available to 5G-MAG members on Causeway as CDT0107.3GPP SA4#121 TS26.512 API corrections

[rjb1000]

Formal CRs submitted to SA4#121:

• Rel-16 CR0027 in S4-221250.
• Rel-17 CR0028 in S4-221251.

[rjb1000]

The following Change Requests were agreed at SA4#121 Closing Plenary yesterday afternoon:

• TS 26.512:
  • Rel-16: CR0027r2 S4-221605.
  • Rel-17: CR0028r2 S4-221606.

[rjb1000]

Change Requests approved at SA#98-e:

• Rel-16: CR0027r2 in SP-221042.
• Rel-17: CR0028r2 in SP-221043.

[rjb1000]

New specifications published:

• TS 26.512 V16.8.0.
• TS 26.512 V17.3.0.