| 3am PDT | 6am EDT | 10:00 UTC | 10:00 GMT | 11:00 CET | 12:00 EET | 15:30 IST | 18:00 CST | 19:00 JST |
(please feel free to correct and update your names Thank you very much!!!)
|00:00||chair topic||no update|
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 |
2020-03-31: Martin Skorupski
2020-04-07: Martin Skorupski
2020-04-14: Martin Skorupski
2020-04-21: Martin Skorupski
UML and YANG are out for review
Last minute questions:
[sko] same as on the upper - no updates needed.
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.
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.
Which is the expected value for the "package"?
Answer: Value should be "true"
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.
>> Accepted - The FirmwareModel should be integrated into TR532. Thanks a lot!
|00:40||AirInterface Issue #36|
Different multiplicity at problemKindSeverityList and supportedAlarmList
|00:35||AirInterface Issue #37||Thorsten Heinze|
Scope of transmission-mode-list/xpic-is-available?
Proposal made - review starts - approval for 2021-04-07 expected.
End of the meeting
|00:xx||AirInterface Issue #41|
XltsThresholdCrossAlarmType::xltsLevel should have a default value
xlts-threshold-cross-alarm-list: Threshold cannot be identified if being changed
|End of the meeting|