Subject: RE: [nfsv4] NFSv4.1 retention attribute proposal (Yoder / Black)

From: "Yoder, Alan" <[email-masked]>
Date: Tue, 5 Sep 2006 12:34:20 -0700

> -----Original Message-----
> From: Peter Staubach [mailto:[email-masked]] 
> Sent: Tuesday, September 05, 2006 12:15 PM
> To: Yoder, Alan
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nfsv4] NFSv4.1 retention attribute proposal 
> (Yoder / Black)
> 
> Yoder, Alan wrote:
> >> Perhaps it would be sufficient to remove paragraphs like: 
> "Setting the
> >> ebtime is the equivalent to an event notification 
> operation in XAM.".
> >>     
> >
> >    In actual RFC text, sure.  For now, I'm trying to preserve
> > the link between the two working groups so both can understand
> > what's being proposed.
> >
> >   
> 
> Which is good, but does not benefit folks like myself (your offer not
> withstanding... :-)) who are just trying to measure the 
> proposal against
> the requirements.  I feel like I do better when I can understand the
> requirements that some piece of protocol is attempting to address.
> 

The XAM group specifically tried to address the issue this way--
the consensus was that these are the core requirements known to
the group that need to be addressed by any protocol:

	* A time-based retention model
	* An event-based retention model
	* A mechanism for administrative hold
	* A mechanism for infinite hold

The I-D is an expression of those requirements that was satisfactory
to the group.

> >
> >    I don't know of others.  XAM is intended to be a standard.
> > There are probably a dozen vendors on board.  There will of 
> > course be proprietary implementations, just as there are 
> > for NFS.
> >
> >    A bit of background: the FCAS group is also interested in
> > developing a FileSystem Interface (FSI) to XAM-compliant devices.
> > This proposal is intended to provide a standard way of accessing
> > retention data--which may have been set via XAM--via a standard
> > filesystem protocol.
> 
> Is there an intention to publish XAM to make it publicly available,
> beyond just SNIA members?  Perhaps in a different way -- are there
> any ramifications of including this sort of support in NFSv4, legal
> or otherwise?  I am a bit concerned that a SNIA membership might be
> required in order for a NFSv4 server or client implementor to be
> successful.

   Once SNIA standards make it out of SNIA, they are made public,
and unless there are intellectual property issues, they go onto 
an ANSI/ISO track, at which point SNIA no longer actually owns 
them anymore. 

Hope that helps,

Alan

>     Thanx...
>        ps

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Peter Staubach <[email-masked]>
Date: Tue, 05 Sep 2006 15:56:27 -0400

> The I-D is an expression of those requirements that was satisfactory

Okie doke.

I am a bit unsure of the actual semantics which are required here.
The I-D describes some in fair detail, but I am wondering about
other aspects.

For example, how is "retention" defined?  Does this include the
file contents and the file name?  Would capturing a copy of the
file in something like a snapshot with appropriate retention
parameters suffice?  Or does the original file with its original
name have to continue to exist?  I could envision keeping the
file on secondary storage in some sort of filing system, separate
from the active file system.  Or is this something different than
the retention which is being pursued here?

The proposed support seems like a way for the client to participate
in a retention architecture, but I am unsure as to how much the
client is expected to do and how much the server is expected to do.
Does the client treat the attributes as mostly informational or does
it actually use the information to help to implement the policies?

    Thanx...

       ps