rfc-editor | 18 Apr 01:02 2014

RFC 7204 on Requirements for Labeled NFS

A new Request for Comments is now available in online RFC libraries.

        RFC 7204

        Title:      Requirements for Labeled NFS 
        Author:     T. Haynes
        Status:     Informational
        Stream:     IETF
        Date:       April 2014
        Mailbox:    tdh <at> excfb.com
        Pages:      18
        Characters: 39350
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-nfsv4-labreqs-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7204.txt

This memo outlines high-level requirements for the integration of
flexible Mandatory Access Control (MAC) functionality into the
Network File System (NFS) version 4.2 (NFSv4.2).  It describes the
level of protections that should be provided over protocol components
and the basic structure of the proposed system.  The intent here is
not to present the protocol changes but to describe the environment
in which they reside.

This document is a product of the Network File System Version 4 Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
(Continue reading)

Christoph Hellwig | 17 Apr 22:42 2014

add missing data types for SEEK return description

The seek results reference data_info4 and app_data_hole4, so make
sure to include them in the xml file.

diff --git a/nfsv42_middle_op_seek.xml b/nfsv42_middle_op_seek.xml
index 4fccdec..47af9c1 100644
--- a/nfsv42_middle_op_seek.xml
+++ b/nfsv42_middle_op_seek.xml
 <at>  <at>  -14,6 +14,8  <at>  <at> 

   <section toc='exclude' title="RESULT">
+    <?rfc include='autogen/data_info4.xml'?>
+    <?rfc include='autogen/app_data_hole4.xml'?>
     <?rfc include='autogen/seek_res.xml'?>



nfsv4 mailing list
nfsv4 <at> ietf.org

Thomas Haynes | 16 Apr 22:04 2014

Open items in NFSv4.2

I'm in the process of building an open issues list with the 4.2 spec and
one of the things I've come across is the interaction between READ_PLUS
and ADHs.

1) Ignoring the whole issue of whether ADHs should be in the spec
or not, I want to tackle the other issue of what does a client do if it does
not (and never will) support an arm of READ_PLUS?

I.e., the client informs the server it wants to get holes back instead of data.
But now it is exposed to having to also receive ADHs. In the future, it might
get back 64 bit I/O or any new arm.

We can easily mark the request to state which arms the client is able to

struct READ_PLUS4args {
        /* CURRENT_FH: file */
        stateid4        rpa_stateid;
        offset4         rpa_offset;
        count4          rpa_count;
        data_content4   rpa_what;

The server can then determine whether it can return an arm or not.

In the case of ADHs, the intent was that even if the client did not support
ADHs, we could avoid the transmission of the data across the wire
by allowing the client to expand the ADH to an in-memory representation.

If the client never dirties the corresponding blocks, they never get written
(Continue reading)

internet-drafts | 11 Apr 19:51 2014

I-D Action: draft-ietf-nfsv4-rfc3530bis-dot-x-22.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description
        Authors         : Thomas Haynes
                          David Noveck
	Filename        : draft-ietf-nfsv4-rfc3530bis-dot-x-22.txt
	Pages           : 37
	Date            : 2014-04-11

   The Network File System (NFS) version 4 is a distributed filesystem
   protocol which owes its heritage to NFS protocol version 2, RFC 1094,
   and version 3, RFC 1813.  Unlike earlier versions, the NFS version 4
   protocol supports traditional file access, while integrating support
   for file locking and the mount protocol.  In addition, support for
   strong security (and its negotiation), compound operations, client
   caching, and internationalization have been added.  Of course,
   attention has been applied to making NFS version 4 operate well in an
   Internet environment.

   RFC3530bis formally obsoleting RFC 3530.  This document, together
   with RFC3530bis replaces RFC 3530 as the definition of the NFS
   version 4 protocol.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:
(Continue reading)

David Noveck | 8 Apr 02:57 2014


From draft-haynes-nfsv4-layout-types-01: > Some implementers have interpreted the text in Sections 12 ("Parallel > NFS (pNFS)") and 13 ("NFSv4.1 as a Storage Protocol in pNFS: the File > Layout Type") of [RFC5661] as both being strictly for the File Layout > Type. I don't see how one can read section 12 and think that it applies only to the file layout. After all 12.2.5 and 12.2.7 do explicitly mention block and object layouts. It may be that people are interpreting Section 12 as referring only to existing layout types and not to those not yet thought of when RFC 5661 was proposed. I suspect that the root of the problem here is that when RFC5661 was published, people were not inclined to specify the sort of requirements for layout type semantics that Tom puts forward in his draft since it was generally agreed that block and object layout types would be finished soon and would have the appropriate semantics. I think Tom has identified a problem that we must address if we are to be able to consider new layout types. We have to have some well-understood set of semantic requirements in order to make an informed decision as to whether the proposed layout type meets the requirements. I think the requirements that Tom has articulated make sense. If people have issues with them, they need to comment now to start the process of getting to a consensus on this set of issues. I don't see how we can turn any proposal for a new mapping type into a working group document until there is working group agreement on the appropriate semantic requirements
nfsv4 mailing list
nfsv4 <at> ietf.org
Anna Schumaker | 17 Mar 17:17 2014

v4.2 write_response4 wr_count


The wr_count field of a write_response4 is defined as a 32-bit count4, but hole punching allows for a 64-bit
length.  Should wr_count be a length4 instead?


nfsv4 mailing list
nfsv4 <at> ietf.org

Marcel Telka | 17 Mar 08:01 2014

RFC3530bis-32 typo

I found minor typo in RFC3530bis-32 (double "the"):

   The client MUST always accept numeric values if the security
   mechanism is not RPCSEC_GSS.  A client can determine if a server
   supports numeric identifiers by first attempting to provide a numeric
   identifier.  If this attempt rejected with an NFS4ERR_BADOWNER error,
>> the the client should only use named identifiers of the form "user <at> 


| Marcel Telka   e-mail:   marcel <at> telka.sk  |
|                homepage: http://telka.sk/ |
|                jabber:   marcel <at> jabber.sk |

nfsv4 mailing list
nfsv4 <at> ietf.org

Haynes, Tom | 14 Mar 06:14 2014

FW: New Version Notification for draft-haynes-nfsv4-layout-types-00.txt

When we had the slew of new layout type proposals in Atlanta, I said I¹d
draft an informational RFC on what I thought were the differences between
the Layout Type requirements and the File Layout Type in RFC 5661.  This
is that document.

My knowledge of the Blocks and Objects is strictly a reading one, so I¹d
appreciate feedback from the people who actually implemented servers for

On 3/13/14, 10:07 PM, "internet-drafts <at> ietf.org"
<internet-drafts <at> ietf.org> wrote:

>A new version of I-D, draft-haynes-nfsv4-layout-types-00.txt
>has been successfully submitted by Thomas Haynes and posted to the
>IETF repository.
>Name:		draft-haynes-nfsv4-layout-types
>Revision:	00
>Title:		Considerations for a new pNFS Layout Type
>Document date:	2014-03-13
>Group:		Individual Submission
>Pages:		10
>   This document provides guidelines for identifying the fine line
>   between the requirements for Network File System (NFS) version 4.1's
>   Parallel NFS (pNFS) and those for the pNFS File Layout.  Implementors
>   trying to specify new Layout Types are having difficulty in
>   separating the two sets of requirements.
>Please note that it may take a couple of minutes from the time of
>until the htmlized version and diff are available at tools.ietf.org.
>The IETF Secretariat

nfsv4 mailing list
nfsv4 <at> ietf.org

Michael Maymann | 13 Mar 20:02 2014

PNFS questions

Hi list,

I'm setting up a new BIO-HPC facility and are looking for a fault tolerant, scalable, fast and priceeffective storage solution.

I have been looking at Coraid, Panasas and Lustre, but would like to investigate my options also of building my own PNFS solution. Clients are all Debian based.

Can anyone recommend:
1. If PNFS is ready for production or if I should stick with a commercial vendor or build a Lustre solution ?
2. PNFS Metadata server SW prefferably for Debian ?
3. PNFS Diskshelfs to be used ?
4. If AOE (ATA Over Ethernet) would make any sense together with PNFS ?
5. PNFS GUI SW prefferably for Debian ?

Thanks in advance :-) !


nfsv4 mailing list
nfsv4 <at> ietf.org
Mike Kupfer | 7 Mar 23:22 2014

draft-ietf-nfsv4-rfc3530bis-32 editorial comments

* Page 19:

>    | linktext4<>     | typedef opaque linktext4<>;                     |

I don't think the first "<>" should be there.

* Page 50:

>    the value of the acl attribute When a server does accept a user or

There should be a period after "acl attribute".

* Pages 168-169 (Section 12.1):

>    It is common for servers and physical
>    filesystems to be configurable as to the behavior shown once set up
>    and each be configuration showing different behavior is considered
>    separately, for our purposes.

I can't follow this sentence.  I'm guessing it should be something like

   It is common for servers and physical filesystems to be configurable
   as to the behavior shown.  In the discussion below, each
   configuration that shows different behavior is considered separately.

(Overall, the new i18n text is easier to follow than it was in rev 29.)

* Page 174 (Section 12.7):

> does not fit into 16 bits


* Multiple places:

> an U-label

This should actually be "a U-label".  The choice between "a" and "an"
depends on how the word is pronounced, not how it is spelled.  Since
"U-label" is pronounced "you lay bell", which starts with a consonant
sound, it's "a U-label".


nfsv4 mailing list
nfsv4 <at> ietf.org

David Noveck | 6 Mar 16:52 2014

Fwd: New Version Notification for draft-dnoveck-nfs-extension-01.txt

---------- Forwarded message ----------
From: <internet-drafts <at> ietf.org>
Date: Thu, Mar 6, 2014 at 9:41 AM
Subject: New Version Notification for draft-dnoveck-nfs-extension-01.txt
To: David Noveck <davenoveck <at> gmail.com>

A new version of I-D, draft-dnoveck-nfs-extension-01.txt
has been successfully submitted by David Noveck and posted to the
IETF repository.

Name:           draft-dnoveck-nfs-extension
Revision:       01
Title:          NFS Protocol Extension: Retrospect and Prospect
Document date:  2014-03-06
Group:          Individual Submission
Pages:          25
URL:            http://www.ietf.org/internet-drafts/draft-dnoveck-nfs-extension-01.txt
Status:         https://datatracker.ietf.org/doc/draft-dnoveck-nfs-extension/
Htmlized:       http://tools.ietf.org/html/draft-dnoveck-nfs-extension-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-dnoveck-nfs-extension-01

   This document surveys the processes by which the NFS protocol has
   been extended in the past and considers how the mechanisms by which
   the protocol is extended might best be modified in the future.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

nfsv4 mailing list
nfsv4 <at> ietf.org