#ident "@(#)issues	1.3 09/08/04 SAC"

Issues for inception review on 2009-08-05

dwc-1	reparse_umbrella_spec.txt, section 3, 3rd paragraph:

	Are referrals intended to be a useable as a replacement for
	/net/"host"?

    Response:
	It may be possible to do so but that's not the primary intent for
	referrals.  Referrals are simply a means to tell a client that it
	should continue processing a path at an alternate location.

dwc-2	RP.pdf, page 11, 2nd & 3rd bullets:

	In the POSIX and SUS standards, the "@", "{", ":", and "}" are
	all legal (although not portable) characters in a filename.  The
	standards explicitly state that the contents of a symlink are
	used to replace the name of the symlink during pathname
	resolution.  If you change the meaning of symlink contents
	starting with "@{" without adding an option to enable this new
	behavior, you are violating the POSIX and UNIX branding
	requirements.  (This could easily be why AIX chose to use a new
	file type.)

	You could use a new system call (e.g., reflink(2) to create a
	symlink and set the XAT_REPARSE attribute on it as an atomic
	operation), but having symlink(2) change the meaning of a
	symlink if it contains some magic characters violates the
	standards.

    Response:
	The project team considered the effect on standards conformance and
	feels that there will be no impact.  We are convinced that existing
	services and applications will not be affected by this change and that
	standards conformance tests will not detect a non-conformance due to
	these changes,

	Should an application unintentionally create a symlink with the
	reparse point format, it will be stored faithfully by symlink(2) and
	retrieved by readlink(2), and local system and library calls that
	accept filenames will behave as they do today on encountering it.
	Since XAT_REPARSE is not visible to POSIX applications, there is no
	mechanism by which such an application running locally will detect a
	deviation from normal POSIX behaviour.

	The NFS and SMB follow-on projects will change remote file access
	semantics but they are already non-POSIX environments, and none of the
	projects envisioned under this umbrella interpose on local access.

	As described in the case materials, file systems must announce support
	for this feature (as described in PSARC/2007/227) in order for it to
	be activated, which, for the current roadmap, will only affect ZFS.
	The project team is not considering adding reparse point support to
	any other file systems.

	On the basis that this case will not affect, and cannot be detected
	by, any existing local behavior, and that only file systems announcing
	reparse point feature support will trigger XAT_REPARSE behaviour, the
	project team feels that it is unnecessary to provide an enable/disable
	option.

dwc-98  Nit: reparse_umbrella_spec.txt, section 3, item 3 under heading
	"The follow-on projects are:", 2nd paragraph:

	Am I correct in assuming that "hosed and stored" was intended to
	be "housed and stored"?

    Response:
	Yes, typo.

dwc-99	Nit: RP.pdf, page 12, 3rd bullet:

	Shouldn't "Userpace" be "Userspace"?

    Response:
	Yes, typo.