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

From: "Yoder, Alan" <[email-masked]>
Date: Tue, 5 Sep 2006 15:08:38 -0700

Hi Peter,

You are getting into territory for which
the best answer is, "ask your lawyer."  He or
she is the one who will have to justify your
design decisions to sceptical regulators.  I'd
advise that keeping it simple is a good strategy.

Compliance is a funny area; the Feds don't 
tell you your implementation is compliant, they
just reserve the right to tell you it's _not_
compliant.  And if they don't understand it, 
their motivation to do that may be strong.

The compliance and retention markets are not for 
the faint of heart or shallow of pocket, which is 
why the only required behavior in this I-D is to 
return non-support when there is none.  ;)  

Alan

> -----Original Message-----
> From: Peter Staubach [mailto:[email-masked]] 
> Sent: Tuesday, September 05, 2006 12:56 PM
> To: Yoder, Alan
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nfsv4] NFSv4.1 retention attribute proposal 
> (Yoder / Black)
> 
> Yoder, Alan wrote:
> >
> > 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.
> 
> 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
> 

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