Hi, I haven't had time to carefully read sections 1-5, but I think their general message is fine. Here are some first comments on section 6, the proposed GRASP extensions:
> In fragmentary CDDL, a Un-solicited Synchronization message follows > the pattern: > > unsolicited_synch-message = [M_UNSOLDSYNCH, session-id, objective] > > A node MAY actively send a unicast Un-solicited Synchronization > message with the Synchronization data, to another node. This MAY be > sent to port GRASP_LISTEN_PORT at the destination address, which > might be obtained by GRASP Discovery or other possible ways. The > synchronization data are in the form of GRASP Option(s) for specific > synchronization objective(s). Three comments on that: 1. For this to work, the receiving node must always be listening for a new TCP session on that port. So that means a new API function (listen_unsolicited?) and of course either a separate thread or an additional entry in the event loop. Not a problem, just an implementation comment. 2. We need to specify that a new session_id is generated for each new M_UNSOLDSYNCH message. 3. Is this available for any synchronization objective, or do we need to add a new flag bit? > The selective flood option encapsulates a match-condition option > which represents the conditions regarding to continue or discontinue > flood the current message. To be clear, the match is evaluated in every node, and the flooded objective is dropped if there is a match? So we save on storage, not on processing. > 6.5 Publishing Objective Option > > In fragmentary CDDL, a Publish Objective Option follows the pattern: > > publish-objection-option = [PUBLISH, 2, 2, pubobj] objective-name > = PUBLISH > objective-flags = 2 > loop-count = 2 > pubobj = text > > This option MAY be included in GRASP M_Synchronization, when > included, it means this message is for a publish of a specific object > data. Can it also be included in M_UNSOLDSYNCH ? (In other words, the pub/sub bus does not need to send M_REQ_SYN, but always listens for M_UNSOLDSYNCH.) Regards Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima