1. Introduction
   1.1. Project/Component Working Name:

	New NFS share properties for compatibility with 5x20 NAS server
	functionality

   1.2. Name of Document Author/Supplier:

	Doug McCallum

   1.3. Date of This Document:

	05/02/2007

   1.4. Name of Major Document Customer(s)/Consumer(s):
	1.4.1. The PAC or CPT you expect to review your project:

	       Solaris

	1.4.2. The ARC(s) you expect to review your project:

	       PSARC

	1.4.3. The Director/VP who is "Sponsoring" this project:

		Fred Zlotnick

	1.4.4. The name of your business unit:

		Software

   1.5. Email Aliases:
    	1.5.1. Responsible Manager:	Don Traub
    	1.5.2. Responsible Engineer:	Doug McCallum
    	1.5.3. Marketing Manager:	Margaret Hamburger
	1.5.4. Interest List:		nfs-eng@sun.com, snas-tech-team@sun.com

2. Project Summary
   2.1. Project Description:

	Add several new properties to NFS shares that provide
	compatibility with the existing NAS server (5x20 NAS).

   2.2. Risks and Assumptions:

	Low risk. The changes are incremental, only add new
	functionality and don't modify any existing functionality.

3. Business Summary
   3.1. Problem Area:

	The problem is to provide equivalent functionality to our
	existing NAS product. The existing NFS implementation is
	missing several share properties that our current customer
	base uses. This corresponds to RFE 6475452. These properties
	are only implemented on the NFS server.

	There are three types of properties to be added:

	none		The none property takes an access list the
			same way that the rw/ro properties do. It
			provides a mechanism to exclude clients from
			any access to the server. This property is
			declared within a security flavor just as
			rw/ro are.

			Example: "none=host1:host2" would prevent any
			access by host1 or host2.

	root_mapping	Is similar to the "anon" property except that
			it changes the UID associated with a root
			client that is allowed root access via the
			"root=access-list" property.
			
			Example: "root=host1:host2,root_mapping=321" would
			set the UID of the root user on host1 or host2 to
			321 instead of 0.

	<charset>	This is a set of properties that specify a
			supported character set and an access-list. If
			a client appears in one of the <charset>
			properies access-list, a conversion between
			the client's character set and UTF-8 will be
			performed in order to ensure that the server
			file system only sees UTF-8 file names.

			Example: "euc-kr=host1:host2" specifies that
			host1 and host2 use the euc-kr character set
			and that path and file name components must be
			converted between euc-kr and UTF-8.

			An initial set of translations will be
			available with possible future additions being
			delivered through the facilities provided via
			PSARC/2007/173.

   3.2. Market/Requester:

	NAS server team

   3.3. Business Justification:

	Needed to maintain compatibility with our existing product
	line when it migrates to a Solaris base.

   3.4. Competitive Analysis:

	Current Procom based product uses this functionality.

   3.5. Opportunity Window/Exposure:

	Needs to be available in first release of the Solaris based
	NAS server.

   3.6. How will you know when you are done?:

	When the properties are implemented and tested. This is not a
	large effort.


4. Technical Description:
    4.1. Details:

	 The properties need to be added to the sharemgr NFS plugin to
	 enable the correct property parsing and fill-in of the export
	 structures.

	 Mountd needs to be taught about the "none" and charset
	 properties in order to search the access-list associated with
	 it.

	 The kernel nfs modules need to know that the root_mapping
	 value needs to be used appropriately.

	 An upcall to mountd to check the access list needs to be done
	 at client session establishment.

	 The kernel nfs modules will need to know that a client
	 session needs a character conversion and convert the paths
	 and file name components appropriately. This includes all
	 lookup cases and dirent calls, among others.


    4.2. Bug/RFE Number(s):

	 6475452 Need Solaris support for 5x20 NAS server approve file
	 functionality in NFS

    4.3. In Scope:


    4.4. Out of Scope:

    
    4.5. Interfaces:

	 New options on exported NFS shares. These will be committed
	 interfaces.
    
    4.6. Doc Impact:

	 Man pages and the adminstration guide will need to be updated
	 to reflect the new functionality.  In particular,
	 sharemgr(1m) and share_nfs(1m) need updating.
    
    4.7. Admin/Config Impact:
	// How will this change impact the administration of the product?
	// Identify changes to GUIs, CLI, agents, plugins...
    
    4.8. HA Impact:

	 N/A
    
    4.9. I18N/L10N Impact:

	N/A
    
    4.10. Packaging & Delivery:

	  No new packages and no install time dependencies. 
    
    4.11. Security Impact:

	  Doesn't affect existing security interfaces. Provides a way
	  to limit root clients or to exclude some clients from
	  accessing NFS.
    
    4.12. Dependencies:

	  N/A

5. Reference Documents:
	  6475452 Need Solaris support for Montana approve file functionality in NFS
	  

6. Resources and Schedule:
   6.1. Projected Availability:

	Q2 - 2007

   6.2. Cost of Effort:

	Couple of weeks
	

   6.3. Cost of Capital Resources:

	Using existing equipment

   6.4. Product Approval Committee requested information:
   	6.4.1. Consolidation or Component Name:
	       ON

	6.4.3. Type of CPT Review and Approval expected:
	       RFE

        6.4.4. Project Boundary Conditions:
	       N/A

	6.4.5. Is this a necessary project for OEM agreements:
	       N/A

	6.4.6. Notes:
	6.4.7. Target RTI Date/Release:
	       onnv_67

	6.4.8. Target Code Design Review Date:
	6.4.9. Update approval addition:
	       N/A

   6.5. ARC review type:
	       FastTrack

7. Prototype Availability:
   7.1. Prototype Availability:

	before end of May

   7.2. Prototype Cost: