Subject: [nfsv4] Last call for NFSv4.2 - start now - end on Dec 1st

From: Spencer Shepler <[email-masked]>
Date: Tue, 4 Nov 2014 00:51:18 +0000

This is a notice for the start of last call for NFSv4.2.

This includes the following two I-Ds:

NFS Version 4 Minor Version 2
http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-27.txt

NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description
http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-dot-x-27.txt

I am setting a longer timeline for this last call given this week's IETF meeting and the US - Thanksgiving holiday week.
If we need more time, please let me know.

Comments back to the WG alias and nits directly to Tom.

Thanks,
Spencer

---

From: "Adamson, Andy" <[email-masked]>
Date: Wed, 19 Nov 2014 18:11:21 +0000

Hi Tom

I’ve posted draft-ietf-nfsv4-rpcsec-gssv3-09, responding to comments by Nico Williams, Bruce Fields, and Ben Kaduk.

Attached are the changes to the NFSv4.2 draft that reflect the changes to GSSv3.  The main change is the that multi-principal assertion currently used in the Secure Inter SSC portion of NFSv4.2 can no longer be used due to the change in the MIC data.

—>Andy

---

From: David Noveck <[email-masked]>
Date: Fri, 21 Nov 2014 18:25:34 -0500

I've already sent a bunch of review comments to Tom (and the working group)
on Sept.28.  While I did touch on the issue that I'm going to raise now, I
think that issue is of sufficient importance that we need to get a greater
focus on it before WGLC is over.

I'll summarize my concern by saying that in the current draft there is
insufficient attention to the intra-server copy feature.   Instead, the
draft starts talking about the server-side copy feature (by which it means
the inter-server copy feature).  While the inter-server copy feature has
had a lot of good work go into it, we need to be realistic. Widespread
deployment of the inter-server copy feature is far away and that makes it
necessary for us to to be clear that intra-server copy can be implemented
and may be very useful, even when inter-server copy is not supported at all.

So to give some specifics on what I think needs to be done:

I would rewrite section 1.4.1. as follows:

*1.4.1 Server-side Copy Features*

A traditional file copy of a remotely accessed, whether from one server

to another or between location in the same server, results in the
data being put on the network twice - source to client and then
client to destination.  New operations are introduced to allow

unnecessary traffic to be eliminated:

o The intra-server copy feature allows the client to request the

  server to perform the copy internally, avoiding unnecessary network

  traffic.

o The inter-server copy feature allows the client to authorize the

  source and destination servers to interact directly.

As such copies can be lengthy, asynchronous support is also provided.

Section 14 needs to be updated as well:

   - Delete the line "COPY Server Side Copy" and replace it by the
   following two lines:

COPY1s   Intra-server Copy

COPY2s   Inter-server Copy

   - Change the feature field of COPY to read:

Copy1s(REQ),COPY2s(REQ)

   - Change the feature field of COPY_NOTIFY to read:

COPY2s(REQ)

   - Change the feature field of OFFLOAD_STATUS, OFFLOAD_CANCEL, and
   CB_OFFLOAD
   to read:

Copy1s(OPT),COPY2s(OPT)

On Mon, Nov 3, 2014 at 7:51 PM, Spencer Shepler <[email-masked]>
wrote:

> I am setting a longer timeline for this last call given this week’s IETF
> meeting and the US – Thanksgiving holiday week.
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>

---

From: Thomas Haynes <[email-masked]>
Date: Sun, 23 Nov 2014 21:52:08 -0800

> On Nov 21, 2014, at 3:25 PM, David Noveck <[email-masked]> wrote:
> 
> I've already sent a bunch of review comments to Tom (and the working group) on Sept.28.

And I’m working through that list.

>   While I did touch on the issue that I'm going to raise now, I think that issue is of sufficient importance that we need to get a greater focus on it before WGLC is over.
> 
> 
> I'll summarize my concern by saying that in the current draft there is insufficient attention to the intra-server copy feature.   Instead, the draft starts talking about the server-side copy feature (by which it means the inter-server copy feature).  While the inter-server copy feature has had a lot of good work go into it, we need to be realistic. Widespread deployment of the inter-server copy feature is far away and that makes it necessary for us to to be clear that intra-server copy can be implemented and may be very useful, even when inter-server copy is not supported at all.

I don’t understand where this comment about inter-server copy being far away is coming from?

Is it a concern about RPCSEC_GSSv3?

In any event, I’m aware of the following 

                NFSv4.2      Propritary
Secret Sauce    Linux        NetApp
(or none)

RPCSEC_GSSv3    Linux        ???

I.e., we have some implementation experience with inter-server copy.

FWIW - I think the above both support intra-server copy as well.

> So to give some specifics on what I think needs to be done:

I’ll comment on the proposed changes later...

---

From: Christoph Hellwig <[email-masked]>
Date: Mon, 24 Nov 2014 09:44:33 +0100

> I.e., we have some implementation experience with inter-server copy.

Maybe I've missed it, but I've not seen any Linux inter-server copy support, I
only remember the intra-server support from Anna.  I've also not seen
any client either even if NetApp has a server implementation.

And even if those implementations exists, does any of them reflect the
current version in the spec?  Both the copy operations and the GSS support
changed significantly this year.

---

From: David Noveck <[email-masked]>
Date: Mon, 24 Nov 2014 06:52:29 -0500

> Is it a concern about RPCSEC_GSSv3?

Yes.

It still has to go  through WGLC  and the hard-to-bound IESG approval
process.

Actually, my comment was about "widespread deployment" of inter-server
copy.   Even if all the specs in question stabilize and are quickly
approved, in the nature of things the process of incorporating the support
(including RPCSEC_GSSV3) in widely deployed implementations is going to be
prolonged.  My guess is that no matter how  things play out on the
RPCSEC_GSSV3 standards front, there will be a considerable time in which
intra-server copy is widely deployed and useful while inter server copy is
not.

In any case, these are two separate features and it is possible
to implement and use intra-server copy without implementing inter-server
copy and the spec needs to make that clear.

On Mon, Nov 24, 2014 at 12:52 AM, Thomas Haynes <
[email-masked]> wrote:

> >   While I did touch on the issue that I'm going to raise now, I think
> that issue is of sufficient importance that we need to get a greater focus
> on it before WGLC is over.
> >
> >

---

From: David Noveck <[email-masked]>
Date: Mon, 24 Nov 2014 07:41:53 -0500

I think we need to adjust the text of section 2 of this document in light
of recent developments:

   - We are working on a new working group standard-track document to
   specify NFSv4-wide rules regarding versioning in NFSv4, including minor
   versions.  We need to adapt to that fact without making a normative
   reference in the v4.2 spec to that work-in-progress document.
   - In line with that effort we are trying to reduce the number of
   distinct presentations of minor version rules.  This has started with the
   deletion of specific minor versioning rules from
   draft-ietf-nfsv4-rfc3530bis-34.  According the Barry Leiba, the treatment
   of minor versioning (every version can make its own rules) in
   draft-ietf-rfc3530bis-33 was "at best unwise".  I responded that it was at
   worst a minefield, that we had so far traversed the minefield successfully,
   and were taking steps to rectify the problem.  I think the IESG as a whole
   will be OK with the new approach.
   - We;d like the minor versioning RFC to not to have to update multiple
   existing RFC's, so it makes sense not to have another listing of minor
   versioning rules in the v4.2 RFC.  This is the case regardless of whether
   the v4.2 RFC or the minor versioning RFC is approved first.

As a result, if we need to simply state any v4.2-related modifications as
allowed by the current RFC5661 text, and not state
yet-another-list-of-minor-versioning-rules  in the v4.2 spec.  I think we
can do this without requiring any minor-versioning-related errata to
RFC5661 and having the minor versioning RFC marked as updating RFC5661 only.

So here are my proposals for changes for the next draft of
draft-ietf-nfsv4-minorversion2:

   - Rewrite section 2 as indicated below an delete the existing section 2.
   - In section 14, delete the line "OBS Also OBSOLESCENT for future
   versions."

*2.  Minor Versioning Considerations*

NFSv4.2 follows the minor versioning approach laid out in
[RFC3530bis].  Specific rules are set forth in [RFC5661]
or in a subsequent standards-track document putting forth
details of an NFSv4-wide versioning framework.

The following versioning-related considerations should be noted.

o When a new case is added to an existing switch, servers need to
  report non-support of that new case by returning
  NFS4ERR_UNION_NOTSUPP.

o As regards the potential cross-minor-version transfer of stateids,
  pNFS implementations of the file mapping type may support of use
  of an NFSv4.2 metadata sever with NFSv4.1 data servers.  In this
  context, a stateid returned by an NFSv4.2 COMPOUND will be used
  in an NFSv4.1 COMPOUND directed to the data server. See sections
  3.2 and 3.3.

---

From: Tom Haynes <[email-masked]>
Date: Mon, 24 Nov 2014 10:57:33 -0800

> On Nov 24, 2014, at 12:44 AM, Christoph Hellwig <[email-masked]> wrote:
> 

I was thinking specifically of the work Andy has done to get RPCSEC_GSSv3 working.

> changed significantly this year.

The one Andy is working on certainly does.

Andy can comment better on the status of the work.

---

From: Tom Haynes <[email-masked]>
Date: Mon, 24 Nov 2014 11:11:44 -0800

> I've already sent a bunch of review comments to Tom (and the working group) on Sept.28.  While I did touch on the issue that I'm going to raise now, I think that issue is of sufficient importance that we need to get a greater focus on it before WGLC is over.
> 
> 
> 1.4.1 Server-side Copy Features
> 

I’m okay with the above.

> Delete the line "COPY Server Side Copy" and replace it by the following two lines:
> COPY1s   Intra-server Copy
> 
> COPY2s   Inter-server Copy
> 
> Change the feature field of COPY to read:
> Copy1s(REQ),COPY2s(REQ)
> 
> Change the feature field of COPY_NOTIFY to read:
> COPY2s(REQ)
> 
> 
> Change the feature field of OFFLOAD_STATUS, OFFLOAD_CANCEL, and CB_OFFLOAD
> to read:
> Copy1s(OPT),COPY2s(OPT)
> 

OK, this solves the open issue from the other review.

> 
> 
> On Mon, Nov 3, 2014 at 7:51 PM, Spencer Shepler <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
> http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-27.txt <http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-27.txt>
>  
> 
> http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-dot-x-27.txt <http://www.ietf.org/id/draft-ietf-nfsv4-minorversion2-dot-x-27.txt>
>  
> 
> I am setting a longer timeline for this last call given this week’s IETF meeting and the US – Thanksgiving holiday week.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
> 
>

---

From: Tom Haynes <[email-masked]>
Date: Mon, 24 Nov 2014 11:25:51 -0800

> On Nov 24, 2014, at 4:41 AM, David Noveck <[email-masked]> wrote:
> 
> I think we need to adjust the text of section 2 of this document in light of recent developments:
> We are working on a new working group standard-track document to specify NFSv4-wide rules regarding versioning in NFSv4, including minor versions.  We need to adapt to that fact without making a normative reference in the v4.2 spec to that work-in-progress document.
> In line with that effort we are trying to reduce the number of distinct presentations of minor version rules.  This has started with the deletion of specific minor versioning rules from draft-ietf-nfsv4-rfc3530bis-34.  According the Barry Leiba, the treatment of minor versioning (every version can make its own rules) in draft-ietf-rfc3530bis-33 was "at best unwise".  I responded that it was at worst a minefield, that we had so far traversed the minefield successfully, and were taking steps to rectify the problem.  I think the IESG as a whole will be OK with the new approach.
> We;d like the minor versioning RFC to not to have to update multiple existing RFC's, so it makes sense not to have another listing of minor versioning rules in the v4.2 RFC.  This is the case regardless of whether the v4.2 RFC or the minor versioning RFC is approved first.  
> As a result, if we need to simply state any v4.2-related modifications as allowed by the current RFC5661 text, and not state yet-another-list-of-minor-versioning-rules  in the v4.2 spec.  I think we can do this without requiring any minor-versioning-related errata to RFC5661 and having the minor versioning RFC marked as updating RFC5661 only.
> 
> So here are my proposals for changes for the next draft of draft-ietf-nfsv4-minorversion2:
> Rewrite section 2 as indicated below an delete the existing section 2.
> In section 14, delete the line "OBS Also OBSOLESCENT for future versions.”

OK, we’ve kept OBSOLESCENT in draft-ietf-nfsv4-versioning-00.txt, so I’m okay with nuking it here as we do not use it.

I’ve also removed the corresponding text in the first paragraph of that section.

> 2.  Minor Versioning Considerations
> 

I like the current (not in draft 27) version instead of the above.

>   in an NFSv4.1 COMPOUND directed to the data server. See sections

I’m okay with these changes.