Table of Contents |
---|
References
<insert Jira Ref, Using confluence menu options +, Jira Issue/Filter>
<optional other relevant references, Jiras, Confluence pages, external links>
Assumptions<optional>
<optional, assumptions are like decision made up front ie. everyone agrees on the answer but they are important to mention>
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Assumptions
# | Assumption | Notes |
---|---|---|
1 |
Issues & Decisions
NCMP receives subscription through topic cm-avc-subscription | |||||||
2 | Message body is consumed as
| ||||||
3 | Message body is forwarded as
|
Open Issues
Issue | Notes | Decision | |
---|---|---|---|
1 |
<Note. use green for closed issues, yellow for important ones if needed>
Any Other Header
< we do not want to dictate the remainder of an analysis it will depend on the type of user story at hand>
Any Other Header
...
What topic do we forward event to | DMI-DATA what names are allowed and do they conflict with allowed topic names | Event will be forwarded under topic ncmp-dmi-cm-avc-subscription-{DMI-DATA-SERVICE-NAME} | |
2 | Question: Assumption is all DMIs read message and determine whether it is applicable to them based on the cmhandles included in the targets. DMIs cannot be targeted specifically as it is an async kafka message Answer: Sounds like a security related bug that is being worked around. Can this be fixed so that each DMI provides the topic it uses for subscriptions? Follow up Question: Target cmhandles are optional? In this case NCMP cannot determine which DMIs to send to and all DMIs will have to read it. | DMI Specific Topic (registration update) Convention approach dmi-data or dmi service name "For dmi to be able to forward subscriptions to you setup on this topic and give dmi rw access" | DMIs are responsible for setting up the topic Convention is set by topic above - Document : "DMI gives itself read access and gives NCMP write access" |
---|---|---|---|
3 | Is the datastore going to be a mandatory field in the predicate body for datastore validation purposes (ONLY Passthrough supported) Answer: On the device, we need to be prepared for NMDA. I.e. the subscription will be targeted to either operational or running, or both. As long as the schema introduced now (for passthrough only) supports extensibility without backward incompatibility, I’m good. | Datastore will be validated | |
4 | In the forwarded message, cm-handle properties are added by NCMP. Is this just public properties or public and private properties | Only private properties are appended |