gw-1	Why do we need another /etc file?  (/etc/nfs/nfschksum.conf)
  	Can't we either include the information in the existing one(s),
	or as smf properties?

	Answer:
	I don't see an existing place where the algorithm name to number
	mapping can be added without breaking the semantics of the existing
	file - really our choices have to be one of /etc/nfs/nfslog.conf,
	/etc/nfssec.conf or /etc/default/nfs - none of these can be
	extended to encompass this information. It's not clear to me how
	this mapping can be stored as smf properties.

	In implementing checksums for NFSv4, we need for a way to maintain
	a mapping between checksum algorithm names and algorithm numbers -
	algorithm numbers is what's sent over the wire. So, this issue

gw-2	20Q #17, How will this mechanism be flexible with a possible
	change in the industry?  What if alignment doesn't occur?

	Answer:
	This mechanism uses a sideband protocol to carry the checksum
	information.

	If checksums get adopted by the NFSv4 community, we'll replace
	this mechanism with whatever the industry consensus is.

	If alignment doesn't occur and the community doesn't see the
	value in implmenting this, Solaris clients will continue to
	use this capability when communicating with Solaris servers.

gw-3	Why not checksum at the RPC layer?  This sounds a lot like
	GSSAPI/SPNEGO.  Why can't that be used?

	Answer: 

	I've added some of the details as to why an RPC level checksum
	won't be sufficient to the design doc titled "Checksum.Design";
	specifically, sections 0 - 2.1 cover the motivation behind not
	chosing an RPC level protection.

gw-4	Design #1, Please say more about interaction with ZFS, I'm
	not sure I understand the comment.

	Answer:

	I've explained a little more about the future interaction
	with ZFS in the design doc, please read section 1 of
	Checksum.Design to see if this answers your question.

gw-5	I believe the data management folk are addressing similar issues,
	please touch base with them.

	Answer:

	I am in touch with the DMG folks about their efforts in this
	area.

wes-1	How do you know the design & protocol is actually
	algorithm-agile unless you have more than one algorithm
	supported?  I strongly recommend implementing multiple checksum
	algorithms -- sha256 is likely to have a short shelf life.

	Answer:

	I've now removed support for sha256 entirely, the project now
	support crc32 and fletcher4 checksum algorithms.

wes-2 	what's the documented threat model?  if it's to protect against random/
	non-malicious corruption, should clarify this in the man pages
	since admins who know just enough about crypto to be dangerous
	may see "sha256" and assume it's good against malicious
	corruption..

	Answer:

	I've completely removed support for sha256 to address some of
	these concerns.

wes-3   opinion fodder/advisory fodder: followon project to generate fma
	error reports from points in the networking stack (nfs,
	ip/tcp/udp/sctp/ah/esp/...) where bad checksums are detected.
	(diagnosis engine may be a research exercise but the in-stack
	instrumentation should be straightforward).

	Answer:

	Such a project would go a long way in improving diagnosability
	of errors when they arise, such a project definitely needs to
	be investigated at the very least.