2021-03-24 5G-xHaul Meeting notes

Daylight savings start in most parts of Europe 2021-03-28 

proposed times for next week onwards

| 2am PDT | 5am EDT | 09:00 UTC | 10:00 BST | 11:00 CEST | 12:00 EEST | 14:30 IST | 17:00 CST | 18:00 JST |

00:05

00:10

Last minute questions:

• about  ‘firmware-component-activation-date’: if the ‘firmware-component-list’ instance has been activated using the upper ‘firmware-component-list’ (with ‘firmware-component-class = Package), what has to be the content of this attribute? The same as reported on upper ‘firmware-component-list’ or a default one?

[sko] same as on the upper - no updates needed. 

• About ‘related-kinds-of-equipment-list’ (in capability container):  perhaps I missed something in our last meeting.

The Description reports   "... Values should be identical with entries in Equipment::ManufacturedThing::EquipmentType::modelIdentifier attribute. Might be empty, if firmwareComponentClass==PACKAGE.";

Does ‘EquipmentType’ mean something already present on an instance of Equipment ? And if not yet configured ? Do you mean that when the associated Equipment instance is created the capability container has to be updated?

[sko] no - values was known in advance

And what about to have an EMPTY list?[sko]  nothing special  No problem on RESTCONF?

[sko] no - the attribute is not showing up in NETCONF.

• For each  ‘firmware-component-list’ instance the ‘subordinate-firmware-component-list’ reports all the ‘firmware-component-list’ instances associated to.

And for the contrary?

To understand if a ‘firmware-component-list’ instance is part of an upper  ‘firmware-component-list’ instance’ it is needed to pass all the ‘firmware-component-list’ instances to find it on a ‘subordinate-firmware-component-list’. Is it fine for an application layer?

[sko] yes – it is fine – we discussed and wanted to avoid references in two direction.

• activation-available

Which is the expected value for the "package"? 

Answer: Value should be "true"

• firmware-component-status

What is the expected value for the "boot-component"?

Answer: in the discussed use case it should be "active", because it was active in the last boot process. 

• no objection, but one abstain

>> Accepted - The FirmwareModel should be integrated into TR532. Thanks a lot!

Next steps?

• combination with other Interface update - compilation of a new document later. 

Different multiplicity at problemKindSeverityList and supportedAlarmList

• Request for approval to as proposed.

Any objections?

• no objections → accepted

Next steps?

• UML and YANG to be updated

Scope of transmission-mode-list/xpic-is-available?

• Continue the discussion about the proposed solution

Proposal made - review starts - approval for 2021-04-07 expected. 

End of the meeting

XltsThresholdCrossAlarmType::xltsLevel should have a default value

• Request to agree on meeting at 31-03-2021
• Any objections so far about the proposed solution?

AirInterface Issues 

22, 23, 24, 25, 26, 27, 28, 30 and 32

xlts-threshold-cross-alarm-list: Threshold cannot be identified if being changed

• intent to close issues are they are for all the listed issues.