#ident "@(#)issues	1.4 09/01/14 SAC"

PSARC 2008/693:	VRRP
Submitter:	Huafeng Lv
Owner:		James Carlson
Intern:		Sebastien Roy

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?

gcs-2	Perhaps the configuration file syntax is complex enough to
	justify expressing it with XML.

gcs-3	Security discussion in zection 9.2:  I don't understand the
	comment about VRRP manipulating other programs.  Please
	elaborate.

Issues for commitment (01/14/2009):

jdc-1	vrrpadm.man.txt: if "-j primary_ipaddr" is optional, then how
	is v4 versus v6 settled?  Is it based on "-A" or does it just
	default to IPv4?

jdc-2	Are there any restrictions on instance names?  (Should there
	be?)

jdc-3	Suggest "non-preempt" instead of "un_preempt."

jdc-4	Path for UNIX domain socket is an interface.

jdc-5	Your case owner will help with interface table details --
	package names shouldn't be Committed (they'll be different in
	OpenSolaris anyway), output for "vrrpadm show" with -p option
	should not be Volatile, and should have stability for sysevent
	and FMRI.

jdc-97	nit (only because library is private): should probably have a
	library handle (like the recent libdladm fix), and a function
	to associate an instance by name rather than passing instance
	name into every function.

jdc-98	nit: should probably include more information in the man
	pages; users shouldn't be forced to read the RFCs for details
	(such as allowed "priority" range and meaning of values).

jdc-99	nit: vrrpd(1M) likely shouldn't document what the service
	depends on; that's not a stable interface.

gcs-4	Near the end of section 3.3's description of the configuration
	file, it's stated that some of the service state is stored
	there (in the "active" field).  This seems like a poor design
	choice.  Configuration information should be separated from
	state information.  Why can't the state information be kept in
	the SMF VRRP service state?