(please feel free to correct, update your names Thank you very much!!!)
Time | Item | Who | Notes |
---|---|---|---|
0min | chair topic | no update | |
30min | HTTP response code | Thorsten Heinze | Update by Lumina:
https://tools.ietf.org/html/rfc7951 → chapter 6.1 [...] The reason comes from the JavaScript specification: https://developers.google.com/discovery/v1/type-format [...] For example, a 64-bit integer cannot be represented in JSON (since JavaScript and JSON support integers up to 2^53). Therefore, a 64-bit integer must be represented as a string in JSON requests/responses. So the type property will be set to "string", but the format property will be set to "int64" to indicate that it is a 64-bit integer. [...]
Proposal: Models will not change - int64 is required. Decision: Models will not change - int64 is required. |
00:26 | @Pawel Krecicki | ODU presentation
No decisions and discussions were made for connector in the past. How should be ODU models - options ODU is a separated box → top level equipment . independent equipment with no dependency to IDU ODU is managed by IDU → actual equipment Proposal (under development): ODU presentation as SFP → actual equipment ("virtual" slot → holder with ODU as equipment) IF port → holder vs connector RF port is sitting on ODU AI: Questions to the vendors What are the advantages and drawbacks of the ODU presentation in a SFP like way? Instantiation procedure like wire-equipment? | |
01:05 | Admin | Decision: summer: 2am ONF time → 11:00 CEST → 12:00 Israel summer time → 17:00 China winter: 2am ONF time → 11:00 CET → 12:00 Israel standard time → 18:00 China Next Meeting: 2020-04-08: 2am ONF time → 11:00 CEST → 12:00 Israel summer time → 17:00 China AI Martin: update meeting invitation | |
0min | Admin | Next meetings 2020-03-25: Martin Skorupski 2020-04-01: Martin Skorupski 2020-04-08: Martin Skorupski 2020-04-15: Martin Skorupski | |
0min | UUID | core-model allows definition of both Logical Termination Points (interfaces), but also connections
core-model is also suitable for representing entire Networks, not only a Device this means that Universally Unique IDs are required Devices cannot get the UUIDs from outside, they need to be generated by the device, and cannot be overwritten from outside Devices are unaware by their surroundings (the network), so it cannot know if a UUID is already used by some other interface in other devices IETF defines how to create UUIDs, and the core-model references this RFC
Possible solutions:
Suggestions:
Out of time, we need to follow up: proposal, next week Tuesday 09:00 CET |