=========================================
What's changed since the inception review
=========================================

The design doc has been updated significantly since the inception review.
Especially:

  - The concept of groups is removed. (In the inception review, people
    asked why it was necessary.)

  - Use the sysevent mechanism to notify interested parties about the
    VRRP instance state transition. (Previoulsy external executables
    were used.) Refer to the answer to gcs-3 below.

  - SMF interaction was redesigned. Refer to the answer to gcs-1 below.

  - In the libvrrp APIs, the type of vrrp_name_t is removed. Its original
    goal was for type safety, but we found it cumbersome and no other
    libraries are using it this way. 

  - Two sub-state are introduced for INITIALIZE state. The "shutdown" sub-state
    indicates that an administrative SHUTDOWN event has been received. The
    "pending" sub-state indicates that the instance failed to start up because
    some of its protected SMF services/instances are not online.

One pending issue is the security check between vrrpd and vrrpadm.
In the current design, when vrrpadm sends a request to vrrpd, vrrpd checks
if the requesting process has enough privileges before it actually does
the work. Some commented that (1) privileges are used by the kernel
and are not intended to be used by user space applications; (2) there
should be one or more ahthorizations associated with such operations.
We've contacted Gary Winiger for advices and will continue later.
 
=========================================
issues for inception review on 2008-11-19
=========================================
 
 gcs-1	The interaction with SMF seems unpolished.  Could the desire to
 	have a given network service use VRRP be expressed as a service
 	dependency rather than by running vrrpize?
 
A: after consulting with SMF experts, we reach this new solution:

   - When a vrrp is created using either "vrrpadm create" or vrrp_create(),
     the user can specify the SMF services or instances to be protected
     by this VRRP instance.

   - To monitor the state changes of the SMF services or instances protected
     by VRRP, vrrpd uses an SMF interface _scf_pg_wait() to get notification
     when the group property "restarter/state" of the SMF service/instance
     is changed.

   - When any of the SMF service/instances is brought offline, the VRRP
     instance will enter the INIT state; When all the SMF service/instances
     are brought online, the VRRP instance will leave the INIT state to
     resume operation.

   These are discussed in Section 3.3 and 5.7 of the updated design doc.
  
 gcs-2	Perhaps the configuration file syntax is complex enough to
 	justify expressing it with XML.

A: In the new design, the concept of groups is removed, so the configuration
   is not so complex. So a plain text file is still used, instead of an XML
   file.
 
 gcs-3	Security discussion in zection 9.2:  I don't understand the
 	comment about VRRP manipulating other programs.  Please
 	elaborate.
 
A: In the new design, VRRP no longer manipulates other programs. Instead,
   vrrpd sends sysevent when a VRRP instance change its state. Interested
   programs can subscribe to such sysevents. For details, refer to Section
   4.2 of the updated design doc.