Subject: [nfsv4] SNIA & XAM issues

From: [email-masked]
Date: Wed, 6 Sep 2006 13:44:13 -0400

Peter and everyone.

Wearing my "co-chair of the SNIA FCAS (Fixed Content Aware
Storage) TWG (Technical Working Group)" hat (the FCAS TWG
is the SNIA the body working on the XAM spec - so many
acronyms, so little time ...), let me try to answer a few
questions here, starting with the procedural issues.  I apologize
for the confusion on this - please understand that I chair several
IETF Working Groups, and it is my firm intention to do the "right
thing" by IETF community, and that includes open source implementers
of IETF standards.

> Unfortunately, XAM is being developed inside
> of SNIA, which makes it inaccessible to non-SNIA
> members.

I can run down references to publicly available presentations
that explain what XAM is.  The spec needs a lot more soak time
inside SNIA.  If it's helpful I can pull drafts out of SNIA
for comment when they're in decent shape.  In a perfect world,
SNIA's standards development process would be public, but the
world's not perfect, and I don't make the rules ...

> Is there an intention to publish XAM to make it publicly available,
> beyond just SNIA members?

Yes - it is intended to become an ANSI and ISO standard.

> Perhaps in a different way -- are there
> any ramifications of including this sort of support in NFSv4, legal
> or otherwise?

That's a very broad question.  There should be no copyright issues
with the text - Alan and I (well, mostly Alan) wrote it, and SNIA
has approved its release.  In IETF, patents are subject to the usual
IETF rules, and questions about those rules should be taken to the
IPR WG (keep that <expletive deleted> off this list, please!).  Promises
about whether a particular implementation meets a particular legal
standard (for retention, compliance, etc.) are up to the implementers
and (IMHO) that's a domain that standards should stay out of.

> I am a bit concerned that a SNIA membership might be
> required in order for a NFSv4 server or client implementor
> to be successful.

That will absolutely not be required - if that happens, we (starting
with me) have seriously screwed up, and I agree with Spencer's comments
(NFSv4 RFC has to be self-contained, all normative references have
to be publicly available).  FWIW, I chair several IETF Working Groups,
so I'm familiar with these sorts of issues.

Now for the more interesting technical issues:

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

NFSv4 will need to define this.  The most straightforward implementation
would keep the retained file accessible by its file name, but I think
that's a fair topic for technical discussion - in some ways this
may be similar to the "what is stable storage?" discussion.  The
retained file retains its identity (e.g., writes to it fail), so
a separate copy of the file on a hidden snapshot is not what is
envisioned.

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

The server is expected to retain the file independent of what a
potentially-clueless client tries to do (e.g., attempting to delete
a file that's under litigation hold MUST fail at the server).  The
attributes are used by the client to tell the server what to do; the
server does it, and uses the attributes to report what it has done
back to the client.

I hope this helps,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Peter Staubach <[email-masked]>
Date: Thu, 07 Sep 2006 09:51:11 -0400

> thing" by IETF community, and that includes open source implementers

Good to hear.  I expected this, but it is always good to hear it.

> world's not perfect, and I don't make the rules ...

Yes, that I do understand.  I was a representative to SNIA for a time,
so I do remember how things worked.  :-)

> and (IMHO) that's a domain that standards should stay out of.

Sorry. I didn't realize that my question could be construed to extend
well beyond just the issue of including references to one non public
specification, at this time anyway, into the NFSv4 specification.

That was mostly all that I was concerned about.  Whether or not a
particular implementation meets legal criteria for retaining data
in some form might be interesting for this forum, but only to decide
whether the base architecture is sufficient or not.

> so I'm familiar with these sorts of issues.

Absolutely.

> server does it, and uses the attributes to report what it has done

Good.  Thanx for the clarification!

> I hope this helps.

Definitely so.

---

A comment and a question regarding the I-D --

The table of contents and the actual section headers for sections
1.1 through 1.7 don't match.  Most of the types and some of the names
need to be updated.

What is an example of a "application-specified event", as mentioned
in section 1.3?

    Thanx...

       ps