Ack with the following review comments:
For error codes ERR_NO_RESOURCES, ERR_NO_MEMORY, ERR_BUSY,
the application has to try again because ...
The statement is too strong and actually wrong.
The application does not *have* to try again and ven if it does and gets
repeated
returns of the same return code, paractically no application should
retry forever.
The message that needs to get documented is that these three error codes
(BUSY, NO_MEMORY and
NO_RESOURCES) are *logically* equivalent to the return code TRY_AGAIN,
but not equivalent in terms
of *real-time-behavior*. The application *may* choose to have a retry
loop, but does not necessarily
*have* to have a retry loop.
The return code TRY_AGAIN is quite common, each retry on the order of
single miliseconds in turn-around.
The blocking situation under control of the immsv and should never last
more than 60 seconds.
The other three error codes have unknown retry-times and may block
indefinitely. The blocking situation
is outside of the control of the immsv.
----------------------
Page 34 3.2.4 immcfg
The old first pre-existing sentence of the second paragraph is not well
formed grammatically:
immcfg without arguments, immcfg starts .....where is possible to
perform more...
-----------------------------
Page 41 section 7 Clarifications on SAI-AIS-IMM-A02.01 specification
There is a very strange/inconsistent enumeration starting with an
indented dot point and then followed
by a non-indented point enumeration using a) b) etc.
Furthermore, point a) starts with "If the timeout is...."
But it is totally unclear here which timeout "the timeout" is referring to!
We have several kinds of timeout in the immsv.
And point b) page 42 starts with "When the implementer ..."
Again unclear what the specific referral to "the implementer" is
referring to.
I would suggest "an implementer" since the intent is to describe
something generic and not some specific
implementer.
-------------------------------
Page 42 chapter header:
3.5 IMMSv Features
I think should be:
3.5 OpenSAF IMMSv Features.
since the chapter describes non standard SAF features.
---------------------------
Page 44 first paragraph at top
The sentence:
" The Applier CCB completedCallback will be received only when the
Primary implementer and PBE (If '
present) will give SA_AIS_OK to their respective completedcallback
in a CCB operation"
has a problem: There may be more than one regular OI involved in a CCB
besides the PBE.
Better:
The applier CCB completedCallback will be received only if/after
all regular OIs and the PBE (if present)
have replied OK on completed. The term "after" may mean after the
CCB has comitted.
But I also think this sentence could be pushed down or dropped because
two paragraphs down is explained
why the completed callback is useless for appliers and thus should not
really be used for anything by
appliers, i.e. left empty.
------------------------------------
Page 96 section 3.5.8.4 An admin-operation for aborting non-critical CCBs
Says: ....directed at the IMM SF service object.
Should be. .... directed at the IMM SAF service object.
/AndersBj
On 10/16/2015 11:56 AM, Neelakanta Reddy wrote:
> Hi,
>
> Attaching the IMMSV PR document for 4.7 release for review:
>
> The following has been added:
>
> 1. 4.7 enhancements
> 2. The points mentioned in the tickets #1371.
>
> Thanks & Regards,
> Neel.
>
>
>
------------------------------------------------------------------------------
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
