Clarification required on Event Notification Rules

[kgkishore]

Scope: Need Clarification on the below Event Notification Behavior

Notification Rule:

G1: The creation of a global object (A) that includes additional global or local objects (B) MUST trigger a CREATION notification for (A) and another CREATION notification for (B), respectively

Sample Example:

CS creation should trigger CSEP creation events alongwith CS creation event. Similarly, connection creation should trigger connection and route creation events

Query:

Global objects would already be having references for local objects in the Create events. What additional purpose does it solve to have additional create notifications for local objects

Concern:
Publishing create events for every local object would be redundant and performance-impacting. It would be too many notifications published for a single operation, e.g. connection creation

Notification Rule 2:

G3: The creation (or deletion) of an object which is included in one or more list(s) MUST trigger: 1) a CREATION (or DELETION) notification for such object followed by 2) an ATTRIBUTE_CHANGE notification for the referencing object(s)

Example from RIA:
A creation (or a deletion) of a NEP MUST trigger a notification of the NEP (CREATION / DELETION) as well as an ATTRIBUTE_CHANGE notification of the Node (the list of NEPs has changed in number of elements).

Sample Example:

A creation(or a deletion) of a CEP MUST trigger a notification of CEP CREATION/DELETION as well as an ATTRIBUTE_CHANGE notification of NEP(the list of CEPs has changed in number-of-elements)

Query:
What is the value addition of sending AVC of referencing object if the object of interest already has reference of the referencing object. E.g. CEP has parent-node-edge-point

Concern:
Redundant notification as child(e.g. CEP) is already publishing details of parent(NEP) and hence separate AVC is not needed.

[rcasellas]

Hi It's been a while since we wrote this and I don't have a strong opinion... IIRC there was done discussion about a client potentially registering for notifications only of local objects, having some kind of unified processing or some similar constraint that I cannot remember right now... Worth thinking over. Scalability issues may be addressed by making the local objects birthstone notifications optional? Thanks Ramon El mar, 4 feb 2025, 8:27, kgkishore ***@***.***> escribió:

…

*Scope:* Need Clarification on the below Event Notification Behavior *Notification Rule:* G1: The creation of a global object (A) that includes additional global or local objects (B) MUST trigger a CREATION notification for (A) and another CREATION notification for (B), respectively *Sample Example:* CS creation should trigger CSEP creation events alongwith CS creation event. Similarly, connection creation should trigger connection and route creation events *Query:* Global objects would already be having references for local objects in the Create events. What additional purpose does it solve to have additional create notifications for local objects *Concern:* Publishing create events for every local object would be redundant and performance-impacting. It would be too many notifications published for a single operation, e.g. connection creation — Reply to this email directly, view it on GitHub <#607>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQOMXMR24KZCQGNCRFBVED2OBTVHAVCNFSM6AAAAABWN3S7IOVHI2DSMVQWIX3LMV43ASLTON2WKOZSHAZDSMZUHAZTSNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[roshan-joyce-fujitsu]

Hi @kgkishore, @rcasellas

I agree with these concerns. I had raised similar concerns in my review comments earlier - please see section 3.2.9.2 in https://github.com/user-attachments/files/16277962/TR-547-TAPI.RIA_v3.2-RJcomments_AM_updated.docx in the issue #593.

These were discussed in one of the calls and there was agreement. As a result, the text that "As mentioned in the final notes (see page 55), implementations MAY reduce this redundancy." was added in G2 and reference to the final notes in page 55 was added in G1.

If this is not sufficient, we can consider revising the guidelines and make them more in line with the semantics of streaming of context data in TR548 - with each object referring to its parent hierarchy. For reference, this is the related text from TR548:

As parent address is provided, it is not necessary for the provider to update the list reference attribute in the parent (in the example above, the connection-end-point list attribute in the node-edge-point e35a31b2-1096-38f9-8e3e-dca010e2f191). Indeed, it is recommended that the provider does not update this attribute with the changes to the containment list property corresponding to the streamed entity. It is expected that the provider does NOT provide any containment list property that reference entities identified by a uuid48

CC: @nigel-r-davis @bcjohnso99