RE: iSNS: Event registry and notification

[Joshua Tseng <jtseng@NishanSystems.com>]

Raghavendra,

Although the type (initiator or target) of iSNS client is stored
in the iSNS database, note that the iSNS server does not make a
distinction in how it interacts with each type of client--both types 
(initiators and targets) are uniformly treated as iSNS clients.
That means both initiators and targets can register for notification
and are members of Discovery Domains.
 
> In reviewing -02 spec of iSNS,  the event registration and 
> notification
> need
> more work to live up to the promise (and requirement of Naming and
> discovery spec) of being lightweight. Right now, it defines catch-all
> and receive-all events.
> 
> To start with, an iSCSI initiator MUST be able to register
> 
>  a) for state changes of specific/interested iSCSI targets.
> 
>  b) for addition of iSCSI targets that provide Login access control
>     to this iSCSI initiator

Please review the section on Discovery Domains.  DD's are used to
define event registration and notification policy.  If you still think
more clarification is needed, let me know what is not clear.

> 
> Along similar lines, it would also help to provide an iSCSI target the
> ability to register for an event when an iSCSI initiator is
> added/removed
> to the login control list of this iSCSI target. An iSCSI target, upon
> receiving such a notification, can then simply download the updated
> list of allowed iSCSI initiators.

Yes, of course.  This is the expected behavior of a target that
subordinates its login control policy to the iSNS.

> 
> Such types of notifications help reduce notification storms by
>  - Helping a small iSCSI initiator client receive and process
>    absolutely required notification (Note that totally turning
>    off notification is a BAD idea)
> 
>  - Reducing needless traffic.

Discovery Domains are the mechanism used to reduce/eliminate
notification storms.

Regards,
Josh

> 
> -JP
>