gw-10	How does this project support MAC for human readable labels
	(label_to_str() M_LABEL not M_INTERNAL)?
	At what label does ipseckey run?  Where is the global IKE
	configuration wire-label <label> stored (/etc/inet/ike/config)?
	What is its label?  What form do the in.iked debug message
	labels take?  How are they protected?

answer: all this code is global zone only; ipseckey and in.iked only
run in the global zone; the config file and debug logs live there as well.

gw-11	Bob Hagmann memorial question:
	What is the administrator experience?  How does administration of
	IPsec/IKE change with this project?

answer: will discuss in meeting

gw-12	5.2: "Precisely how the label is carried in this case is TBD, but ..."
	What's been determined?

answer: system will behave as it does in nevada today: there will be a
CIPSO label in the ip header which may (AH) or may not (ESP) be
integrity protected and which isn't confidentiality protected.
I'll fix the design doc.

gw-13	Release binding, 20Q1 says Patch, yet 20Q11 says SunOS 5.11

answer: this project is intended to be eligible for backport but the
project team has no plans at present to backport.  

gw-14	Is the interface table complete?
	Are the ike config file and PF_KEY extensions Committed?
	Are there other exported interfaces?

answer: Both interfaces were originally ARC'ed at Evolving and are in
the ON consolidation so as I understand it they were bumped to
Committed.

there is one more interface change: ipseckey has been extended to
allow labels to be associated with manually created security
associations.  this capability is mostly useful for testing/debug
purposes but for consistency with the rest of ipseckey would likely
best be considered Committed as well.

gw-99	If you care:
Mandatory Access Control (MAC)
    gww: A non-bypassable policy imposed by the TCB of access to objects
	by subjects based object and subject attributes whose values are
	not under the user's discretionary control.
	Resource limits are an example of non-sensitivity based MAC.
	In sensitivity (labeled) based systems the Bell-LaPadula
	model (simple security property and *-property), sensitivity labels
	and clearances are examples of object and subject attributes.

    ML-MRPP: A means of restricting access to objects based on subject
	and object sensitivity labels. The Bell LaPadula model is an example of
	Mandatory Access Control.

    TCSEC: A means of restricting access to objects based on the sensitivity
	(as represented by a label) of the information contained in the
	objects and the formal association (i.e., clearance) of subjects to
	access information of such sensitivity.

answer: thanks; will add this to the design review doc.

jdc-1	Should single-label really be the default on a TX system?  The
	default elsewhere in TX is label-aware, and you have to drive
	well out of your way to get unlabeled (single-label) behavior.

	I realize that this choice is consistent with existing IPsec
	behavior, but my understanding (from working on Rampart) was
	that unlabeled nodes were weird and special in a TX network.

answer: my understanding is that in practice TX systems often serve as
gateways between multiple single-label networks of label-unaware
systems, and that single-label systems in such networks vastly
outnumber multi-label systems.

that said, the single-label default was something of a design artifact
from the time when I thought I could get away without making tn*db
queries in in.iked.  Now that it is making those queries, it might
make sense to revisit this decision - defaulting to multi-label for
label-aware peers and single-label for label-unaware peers.

I'm open to a TCR here.

	If this hasn't yet been run by Jarrett Lu and Glenn Faden, it
	should be.

answer: both of them participated in the design review.

jdc-2	Some use-cases for the "wire-label" values would be helpful.

	It's not clear to me why labelling for IKE traffic and ESP/AH
	traffic are tied together.  (Are only a few combinations
	useful?)

answer: Unfortunately I don't have customer data on what combinations
will likely be useful in practice.

jdc-99	5.5.1 (nit): I think "unlabeled" versus "labeled" might be
	more familiar for TX users than "single-label" versus
	"multi-label."  Maybe more importantly, a host that handles
	labels explicitly needn't necessarily handle more than one.

answer: I'm torn.  I see your point about consistency but I find the
term "unlabeled" as inherently confusing and misleading.  Let's
discuss in the meeting.

ram-3: in 20Q, q17, you reference a open spec which to your knowledge no other
       implementation exists. Do you expect others to eventually participate?
      Do you know of any implementations contrary to the specification?

answer: that's unclear.  I think it's unlikely but it's hard to
predict the future.  I see a lot of energy around the type-enforcement
model in Flask (which is used by SELinux and which is being ported to
OpenSolaris as part of the FMAC project).

ram-4: In phase1-0.6.pdf, section 5.7 (packaging) you suggest a useful split of
       packages. Do you intend to do this?

answer: yes

ram-96: in phase1-0.6.pdf, page 2, section 2 (Use Cases), third paragraph,
    is "systemadministration" correct?

answer: typo; should be: "Note: two multi-label systems may be
configured to treat each other as single-label"

ram-97 in phase1-0.6.pdf, page 7, section  5.7 (Packaging), first paragraph,
       "Solaris" instead of "solaris".

answer: thanks

ram-98 Glossary was great help...thanks