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

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

> Yoder, Alan wrote:
> > Unfortunately, XAM is being developed inside
> > of SNIA, which makes it inaccessible to non-SNIA
> > members.  
> >
> >   
> 
> Unfortunate.  This will slow down the development of an open source
> implementation.  :-)

   Personal memberships in SNIA are available for $300
a year.  If anyone wants to develop an open-source
implementation, and membership is all that's standing
in the way, I'll write a personal check if that's what
it takes.

> Just for grins, what do XAM and FCAS stand for?

  I don't think XAM is an acronym.  The A might mean
"API" though.  FCAS means Fixed Content A-something
Storage.  In the interests of moving forward, we skipped
the develop-a-great-name-for-our-stuff-and-our-group step.  ;)

> 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.

> I also found the references to "TWG" slightly confusing as it took a
> little work to figure out that they referred to the SNIA technical
> working group instead of the IETF NFSv4 working group.  (Or The
> Wollongong Group.)

   Sorry, I didn't realize IETF used "TWG" as well.

> ---
> 
> Although this sort of thing sounds like it could be useful, adding
> support to the protocol for proprietary support seems less than
> optimal to me.  Are there other data retention architectures being
> proposed in the industry and will this support work for all of them
> as well?
> 

   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. 

Cheers,

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:15:25 -0400

> the link between the two working groups so both can understand

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.

> retention data--which may have been set via XAM--via a standard

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.

    Thanx...

       ps

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 5 Sep 2006 14:31:55 -0500

> required in order for a NFSv4 server or client implementor to be

If the NFSv4.1 RFC is insufficient for implementation then it is flawed.
Just as it would be for any other feature that is incomplete in
its definition (regardless of its origins).

In general, if there are normative references added to the NFSv4.1 I-D that 
unacceptable to the working group or the IETF, then I expect an alternative
solution to be provided.

Spencer