#ident "@(#)issues	1.4 05/06/21 SAC"

gw-0	Scope of the case.

gw-1	Is this case complete?  Does it rely on other cases for the
	actual messages, message types, message subtypes?

gw-2	Proposed contracted interfaces without a prototype contract.

gw-3	Chksum algorithm?

gw-4	What does "assumed to be already in some known byte order"
	imply to this case?

gw-5	Return value (-ve)? Typo?

gw-6	uint32_t	status; PCP_TO_NO_RESPONSE -1?
	or is it uint32_t timeout; that gets -1.  I can't tell from the
	spec.

gw-7	pcp_init:  The actual device names are TBD.  The path names will be
	defined in the host library header file.
	How does that effect this case?  Does this case deliver the library
	header file?

gw-8	pcp_send_recv(,, timeout)
	Seems like req_msg needs to be had populated, why is there a timeout
	value being passed here?

wes-1	the clarifications in section 3 seem to imply but do not 
	explicitly state that the msg_type requests are specific to the 
	particular virtual channel that has been opened.  is that
	the case?  

wes-2	"The actual device path names for each platform channel to be
	defined. (TBD)."
	is that part of this case, or some other case?

wes-3 	applicability of libpcp on other sun4v platforms besides ontario/erie?
	this seems extraordinarily generic, and the glvc interface defined 
	in 2005/173 is claimed to be platform-independant as well.
	so it seems like the way the list of channels is passed to glvc could
	be generic across all sun4v even if the specific list of channels 
	are platform-specific.
	
wes-4	how is the glvc-to-hypervisor interface secured?
	(traps only work from kernel->hypervisor, right?)

wes-5	interface table: all interfaces are listed as "project private".
	who uses pcp_{req,resp}_msg_hdr_t ?
	don't you need a contract private interface with the hypervisor?