Spencer Shepler | 1 Apr 20:16 2015
Picon

Last call for NFSv4.2 (ID version 35)

 

Hi.  We are starting a 2 week last call, ending on April 16th,  for the following documents:

 

NFS Version 4 Minor Version 2 (draft-ietf-nfsv4-minorversion2-35.txt)

 

NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description (draft-ietf-nfsv4-minorversion2-dot-x-35.txt)

 

As usual, comments should be addressed to the WG alias and document editor.

 

The change in this version of the document was the addition of the CLONE operation but all document content is up for review.

 

Spencer

 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
David Noveck | 1 Apr 19:33 2015
Picon

Fwd: NFSv4.2, WG LC, CLONE, and COPY


---------- Forwarded message ----------
From: David Noveck <davenoveck <at> gmail.com>
Date: Wed, Apr 1, 2015 at 1:27 PM
Subject: Re: [nfsv4] NFSv4.2, WG LC, CLONE, and COPY
To: Tom Haynes <thomas.haynes <at> primarydata.com>


I think two weeks is reasonable.

On Wed, Apr 1, 2015 at 1:08 PM, Tom Haynes <thomas.haynes <at> primarydata.com> wrote:
I’m not seeing a huge outcry against this - lets start the counter…


> On Mar 30, 2015, at 1:31 PM, Spencer Shepler <sshepler <at> microsoft.com> wrote:
>
>
> And when can we start a last call for these changes, etc....?
>
>> -----Original Message-----
>> From: nfsv4 [mailto:nfsv4-bounces <at> ietf.org] On Behalf Of Tom Haynes
>> Sent: Monday, March 30, 2015 1:30 PM
>> To: NFSv4
>> Cc: Andy Adamson; Olga Kornievskaia; Christoph Hellwig
>> Subject: [nfsv4] NFSv4.2, WG LC, CLONE, and COPY
>>
>> In Dallas, we decided to take the CLONE operation and to see if we can reach
>> consensus on the inter and intra server COPY approaches.
>>
>> As such, draft-35 has the CLONE operation and the recent changes to the
>> COPY text proposed by Christoph?
>>
>> My take is that everyone is fine with the intra-server copy.
>>
>> Andy and Olga, for the inter-server copy, does the additional stateid solve
>> the issues you were seeing? Is there anything else outstanding on it?
>>
>> Christoph, besides the questions you just asked, are there any issues that
>> stand in the way for you?
>>
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4 <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4


_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
David Noveck | 1 Apr 17:02 2015
Picon

NFSv4 version management.

This is a followup to my talk at IETF 92.  The slides are at http://www.ietf.org/proceedings/92/slides/slides-92-nfsv4-9.pdf.

Work is now proceeding on draft-ietf-nfsv4-versioning-01.  Before that's submitted, I'd like to get people's opinions so that
the draft when produced will not be too far from the general sense of the group on these issues.  I don't expect us to be 
anywhere near consensus for a while but I want the upcoming version to be close enough to where the group as a whole
is that we will mostly be resolving issues of detail.  At least I hope so.

I think there is a genera;l agreement as to two points:
  • We want to do a lot of our future work in terms of the addition of individual features, as specified in draft-ietf-nfsv4-versioning-00.
  • We don't want any more minor versions as big/disruptive as NFSv4.1 was.
This leaves us with a series of issues that relate to the question of what minor versions are for.   Since the versioning RFC is
to define our approach to NFSv4 versioning as a whole, we have to address creation of minor versions as well extensions of
existing minor versions.  An important goal for the NFSv4 versioning RFC is to address both of those in a coherent way. 

One way to look at the issues is to look at each of  the  things that were done  in NFSv4.1 or could be done in minor versions
according to the minor versioning rules in RFC5661 (or draft-ietf-nfsv4--versioning-00) and see whether we want to allow
such things in minor versions, disallow them, or allow them with restrictions
  • Describe the protocol from ground zero, rather than as a series of deltas
I think there is general agreement that we don;t want to do this any more.  In a way, this general agreement is beside 
the point.  There is nobody to do this and the IESG isn't going to let us do it anyway.

One interesting question is whether making this restriction is sufficient to prevent minor versions from becoming too
big/disruptive.  If it is, perhaps we might want to be relatively liberal about other sorts of potential restrictions.
  • Introduce required new features.
Since this was forbidden by the rules in RFC3530, and only changed for v4.1, we might simply go back to the v4.0 version
of this.

On the other hand, it may be that the problem was the size of the feature being introduced, rather than the fact that it
was introduced as required.  The whole issue is complicated by the text of rule #12 in RFC5661, which seems to
suggest that you can only introduce a feature as required if it is big/disruptive.

It may be that the ability to refactor any parts of the protocol  depends on the ability to make a required changed at some
point, and that the ability to do so at introduction is not the essential issue.
  • Change the statuses of existing features, including making features mandatory to not support
If you believe, as I do, that "recommended" feature status should be done away with somehow, then this boils down to 
changes in the sets of required or allowed features.  This inherently raises interversion compatibility issues and we 
need to give some kind of guidance about dealing with this conflict.
  • Making non-XDR-based changes in the protocol
The existing minor versioning rules do not mention this possibility, focusing solely on possible XDR changes.

There were a number of Non-XDR-based protocol changes going from 4.0 to 4.1.  Examples are the creation of a new
a new special stateid to represent the current stateid, the handling of seqid 0 in stateid's and the semantic changes
eliminating the use of owner seqids and clientids in locking requests.

The basic choice we have is whether to forbid things like this going forward.  If they are allowed they should not be allowed 
in features done as separate extensions.  Interestingly, all the ones done in v4.1 were required at introduction but there's no 
good reason not to change that going forward.
  • Adding pNFS-like extension mechanisms to the protocol,
This has happened in going from 4.0 to 4.1 since the pNFS extension mechanism has to be a pNFS-like one :-).  It doesn't seem 
like we want to say this is something that must not be repeated.

Since there are no likely candidates for additional mechanisms of this sort on the horizon, we could defer this.

On the other hand, this is a possible means of protocol extension which has been used and we might as well give some
guidance as far as incorporating such alternate means of protocol extension in our version management framework. Although, we
have the option of updating this document later, it would be better if we could avoid the necessity to do so, if we can.

There are also a number of other questions I'd appreciate hearing people's views about:
  • What to do about recommended/RECOMMENDED as a feature status?
This is tied to he specification of non-REQUIRED attributes as "RECOMMENDED" in RFC's 5661 and 7530.  "recommended" was used in 
RFC3530. It doesn't seem that "RECOMMENDED" is in line with RFC 2119.

As RFC7350 now says that "RECOMMENDED" attributes are not RECOMMENDED according to RFC2119, we might well get rid of the 
current assumption that that most attributes are recommended/RECOMMENDED at introduction.  Unfortunately, RFC5661 still has 
"RECOMMENDED" attributes with the implication that this is in line with RFC2119.  In any case, as far as version management
goes, I don't see how it makes sense to specify features as "RECOMMENDED".  What really makes a difference is whether clients
can  assume support or have to deal with the possibility of non-support.
  • Upper-case vs. lower-case feature status
The -00 now uses upper-case terms for features statuses including "RECOMMENDED".

If we could ditch RECOMMENDED/recommended as a feature status, REQUIRED and OPTIONAL would work.

If we can't do that, then we could make the relevant feature statuses as required and non-required, treating any potential recommendation 
with regard to support as out-of-scope from the viewpoint of version management.
  • How to deal with the current assumption that features will normally/naturally progress to being required.
I think this has to change.  It is quite possible for a feature to be successful/useful without it becoming essential for use in every NFSv4
server.

In any case, I'd appreciate any comments people have on these or other version management issues.  As I indicated, one can't expect anything
like consensus at this point.  I anticipate that this Working Group First Call :-) will be over in about two weeks after which I'd like us to have a
concrete -01 that we can discuss.
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Tom Haynes | 30 Mar 22:29 2015

NFSv4.2, WG LC, CLONE, and COPY

In Dallas, we decided to take the CLONE operation and to see if we can reach consensus on the inter and intra
server COPY approaches.

As such, draft-35 has the CLONE operation and the recent changes to the COPY text proposed by Christoph?

My take is that everyone is fine with the intra-server copy.

Andy and Olga, for the inter-server copy, does the additional stateid solve the issues you were seeing? Is there
anything else outstanding on it?

Christoph, besides the questions you just asked, are there any issues that stand in the way for you?

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

internet-drafts | 30 Mar 22:21 2015
Picon

I-D Action: draft-ietf-nfsv4-minorversion2-dot-x-35.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           : NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description
        Author          : Thomas Haynes
	Filename        : draft-ietf-nfsv4-minorversion2-dot-x-35.txt
	Pages           : 81
	Date            : 2015-03-30

Abstract:
   This Internet-Draft provides the XDR description for NFSv4 minor
   version two.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2-dot-x/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-dot-x-35

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-minorversion2-dot-x-35

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Christoph Hellwig | 30 Mar 20:16 2015
Picon

COPY_NOTIFY review feedback

The cna_src_stateid MUST refer to either open or locking states provided
earlier by the server. If it is invalid, then the operation MUST fail. 

	Why just open or lock stateids?  Why not a delegation or special
	stateid?

For a copy only involving one server (the source and destination are on the
same server), this operation is unnecessary.

	Is it just not nessecary, or do we want to disallow this case
	entirely?

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

Christoph Hellwig | 30 Mar 19:54 2015
Picon

[PATCH] fix attribute values

Fix the attribute values in the spec to follow the ones in the XDR.

Also order the attribute defintions by their numeric value.

Signed-off-by: Christoph Hellwig <hch <at> lst.de>
---
 nfsv42_middle_fileattributes.xml | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/nfsv42_middle_fileattributes.xml b/nfsv42_middle_fileattributes.xml
index 0def75c..200e58c 100644
--- a/nfsv42_middle_fileattributes.xml
+++ b/nfsv42_middle_fileattributes.xml
 <at>  <at>  -53,14 +53,22  <at>  <at> 
       <ttcol align="left">Data Type</ttcol>
       <ttcol align="left">Acc</ttcol>
       <ttcol align="left">Defined in</ttcol>
-      <c>space_freed</c>      <c>77</c> <c>length4</c>            <c>R  </c> <c><xref target="ss:fattr:sf" /></c>
-      <c>change_attr_type</c> <c>78</c> <c>change_attr_type4</c>  <c>R  </c> <c><xref
target="ss:fattr:chattr" /></c>
-      <c>sec_label</c>        <c>79</c> <c>sec_label4</c>         <c>R W</c> <c><xref target="ss:fattr:sec" /></c>
+      <c>space_freed</c>      <c>78</c> <c>length4</c>            <c>R  </c> <c><xref target="ss:fattr:sf" /></c>
+      <c>change_attr_type</c> <c>79</c> <c>change_attr_type4</c>  <c>R  </c> <c><xref
target="ss:fattr:chattr" /></c>
+      <c>sec_label</c>        <c>80</c> <c>sec_label4</c>         <c>R W</c> <c><xref target="ss:fattr:sec" /></c>
     </texttable>
   </section>

   <section anchor="ss:file_attributes:AD" title="Attribute Definitions">
-    <section toc='exclude' anchor="ss:fattr:chattr" title="Attribute 78: change_attr_type">
+    <section toc='exclude' anchor="ss:fattr:sf" title="Attribute 78: space_freed">
+      <t>
+        space_freed gives the number of bytes freed if the file is deleted.
+        This attribute is read only and is of type length4.  It is a per file
+        attribute.
+      </t>
+    </section>
+
+    <section toc='exclude' anchor="ss:fattr:chattr" title="Attribute 79: change_attr_type">

       <t>
         &lt;CODE BEGINS&gt;
 <at>  <at>  -163,7 +171,7  <at>  <at> 
       </t>
     </section>

-    <section toc='exclude' anchor='ss:fattr:sec' title='Attribute 79: sec_label'>
+    <section toc='exclude' anchor='ss:fattr:sec' title='Attribute 80: sec_label'>
       <t>
         &lt;CODE BEGINS&gt;
       </t>
 <at>  <at>  -205,13 +213,5  <at>  <at>  typedef uint32_t  policy4;
       </t>

     </section>
-
-    <section toc='exclude' anchor="ss:fattr:sf" title="Attribute 77: space_freed">
-      <t>
-        space_freed gives the number of bytes freed if the file is deleted.
-        This attribute is read only and is of type length4.  It is a per file
-        attribute.
-      </t>
-    </section>
   </section>
 </section>
--

-- 
1.9.1

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

internet-drafts | 30 Mar 19:34 2015
Picon

I-D Action: draft-ietf-nfsv4-minorversion2-dot-x-34.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           : NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description
        Author          : Thomas Haynes
	Filename        : draft-ietf-nfsv4-minorversion2-dot-x-34.txt
	Pages           : 81
	Date            : 2015-03-30

Abstract:
   This Internet-Draft provides the XDR description for NFSv4 minor
   version two.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2-dot-x/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-dot-x-34

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-minorversion2-dot-x-34

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

internet-drafts | 27 Mar 21:26 2015
Picon

New Version Notification - draft-ietf-nfsv4-lfs-registry-04.txt


A new version (-04) has been submitted for draft-ietf-nfsv4-lfs-registry:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-lfs-registry-04.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-lfs-registry/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-lfs-registry-04

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.

IETF Secretariat.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

The IESG | 27 Mar 00:01 2015
Picon

Last Call: <draft-ietf-nfsv4-layout-types-03.txt> (Requirements for pNFS Layout Types) to Informational RFC


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Requirements for pNFS Layout Types'
  <draft-ietf-nfsv4-layout-types-03.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2015-04-16. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document provides help in distinguishing between the
   requirements for Network File System (NFS) version 4.1's Parallel NFS
   (pNFS) and those those specifically directed to the pNFS File Layout.
   The lack of a clear separation between the two set of requirements
   has been troublesome for those specifying and evaluating new Layout
   Types.  As this document clarifies RFC5661, it effectively updates
   RFC5661.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-layout-types/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4

internet-drafts | 26 Mar 22:55 2015
Picon

New Version Notification - draft-ietf-nfsv4-lfs-registry-03.txt


A new version (-03) has been submitted for draft-ietf-nfsv4-lfs-registry:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-lfs-registry-03.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-lfs-registry/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-lfs-registry-03

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.

IETF Secretariat.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4


Gmane